[Qemu-devel] OpenGL in qemu

[Nik]

Hi,

I've just found the qemu opengl patch, and will try them shortly.

I have only just started considering how this would be made to work.
However, I don't really understand the reasons behind the choice of 
structure for the code.

My intentions had been to write a generic opengl video driver and have 
that forward all opengl calls to the host's opengl libraries. It seemed 
to me that this would work on linux without modifications of OS or 
applications.

On Windows, I'm less clear. If I've understood the opengl.org Wiki, then 
Windows doesn't really provide a real opengl implementation. and 
therefore each Video card provides its own drivers with (presumably) an 
opengl implementation inside. So the forwarding opengl driver would 
still work once we've got Windows to install the driver (with whatever 
that entails).

I must confess that I'm not really sure whether I would be providing 
this code as a driver to be called by the graphics library, or whether I 
would be providing an opengl library replacement (or whether those are 
actually much the same thing).

It seems that I could base any opengl driver or library on Mesa, and 
then take whatever pieces from the qemu vga drivers to support the 
non-opengl video calls.

I can see a number of ways to actually implement the forwarding to the 
host's opengl system:

1. link the qemu executable with the host's opengl libs. This seems to 
be the least flexible, but probably the fastest. Distros which supply 
qemu might prefer this.

2. use a network connection to an external daemon which is linked to the 
host's graphics system. Either X-forwarding (to X) or a specific 
protocol (to opengl) could be used.

3. Have qemu dynamically locate and link to the host's opengl system. I 
have very little idea how best to accomplish this nor how fast it might 
be, but it seems that using qemu's dynamic translationtechnology would 
be a reasonable approach.

Finally, I also found the vmgl project which is only linux<->linux, but 
seems interesting.

Can anyone comment on the relative merits of the approach I've just 
outlined compared to others, including the existing qemu opengl patch?

Cheers!
Nik