portasynthinca3 wrote:
I'm writing a small hobby OS with a GUI in C. My GUI system uses double buffering. I render everything on the second buffer, which is located in RAM, and the transfer it to the graphics card's framebuffer.
Do you have your code in a
hosted public repository, and if you do, could you please provide a link so we can look over your existing code?
portasynthinca3 wrote:
My PC has two graphics cards, the first one is integrated (Intel HD 4000) and the second one is discrete (nVidia GeForce GT 650M) and I'm not really sure to which one my OS is "talking".
On a desktop system, this usually would be easy to determine: is the monitor attached to the port on the motherboard, or the port on the adapter? AFAIK, the hardware cannot route output signals to a port other than the one it is directly connected to, and even if it could, it would require you to set it up deliberately. Can anyone confirm this?
However, given that the GT 650M is a mobile ('M') GPU, I assume that this is a laptop/notebook, and that you are using the built-in display rather than an external monitor. In that case, I would expect that it defaults to the dedicated GPU (probably with dedicated video memory, but that depends on the computer), though it may be selectable in the firmware.
What sort of GPU drivers have you written, and for which of those two? What virtualization setup did you use on the emulators, and which hardware did it emulate? Does your video driver system assume 'standard' SVGA (which never really was all that standard), or does it try to apply any of the of the functions and features of some specific hardware (whether virtual or real)?
I am not sure what other common denominator there would be which both Bochs and Virtualbox supports, if any (apparently there was some discussion about adding Cirrus support to VB as a user-implemented feature several years ago, but AFAICT nothing came of it). Even if there were any, you would have needed to implement a driver for that specific emulated hardware, which certainly wouldn't run on bare metal for either Intel's or nVidia's GPUs. Either way, I assume that your OS defaults to plain-vanilla VGA if it doesn't have a specific hardware driver for a given video system.
With regards to video pass-through allowing you to virtualize the hardware directly,
this previous discussion may be relevant, though that was regarding QEMU rather than either Bochs or Virtualbox. Using VFIO would require you to connect a second monitor, and configure it to use a different GPU from the one used by the host system, with the guest getting dedicated access to the GPU it uses. I have no idea if this would even be possible on your particular notebook.
Now, the HD 4000 predates the introduction of
Intel Graphics Virtualization Technology , so whichever emulated hardware you are using in Virtualbox is not going to match the physical hardware. Even if you were running on newer hardware, I don't know if Virtualbox supports GVT (Bochs presumably doesn't, being strictly a software emulator rather than a virtualizer). Either way, my understanding is that it could only be applied to the iGPU (since the Wikipedia article describes GVT as a feature of the Iris series of iGPUs specifically). Also, I'm pretty sure that GVT-d would require you to use a separate physical monitor and dedicate a GPU specifically for driving it, which for a laptop or notebook presents the same issues as with VFIO. I don't know enough about GVT-g or GVT-s to say of they will allow a virtualized GPU to be shared between the host and guest systems (my impression is that they are intended to, but that GVT-g would take a performance hit as the GPU is timesliced between the host and the guest, while GVT-s involves hardware-level emulation rather than hardware sharing).
The point being that unless you are sticking to SVGA and VBE, then you would need to write a driver for the specific GPU (most likely the GeForce). This is no small task, especially regarding the GeForce hardware, as unlike Intel, nVidia have always been tight-lipped about the internals of their hardware; while there will be a lot more information available on the older Kepler GPUs like the GT 650M than for more recent ones, it will still require a bit of digging and maybe going through the source code of some open-source drivers (e.g.,
Nouveau) for some of the details.
However, jumping right into driver development may be premature, until you know what the cause of the problem is.
Depending on how your GUI works, the video hardware may not be the only relevant factor. If you are booting and running off of a USB drive of some sort (especially USB 2.0 or older), then anything that requires fetching data from the drive is likely to be very, very slow, including any page faults that trigger swapping (OK, the latter isn't likely given the size of modern memories vs. the likely memory footprint of a new OS with no significant legacy cruft, but it's worth noting). There are a number of other possible issues too, I suppose, but I'd need to know more about the OS, the dev host, and the testing host (including if they are the same system or two different ones) to say.