Re: [Qemu-devel] OpenGL in qemu

[Nik]

Hi Paul,

Thanks for your concise and helpful comments.

Thank you also for your link to Gallium. That is a very interesting 
development, which I think is long overdue.

Regarding the importance of Direct3D, it is of little importance to me 
personally and what I am trying to achieve. I need to get CAD packages 
like Archicad and Autocad running well in a Windows guest on a linux 
host, and so OpenGL support in the guest is all I actually need.

However, if I can find a solution which has a good longer-term future 
and supports the greatest range of applications and users, then I am 
very interested, so long as it doesn't make the implementation overly 
complex. :o)

Regarding Gallium, I understand you are saying that a generic gallium 
driver in the guest OS could forward to a gallium system on the host?

Do you think that a gallium -> opengl adaptor could be readily written?

... Actually, given that gallium models graphics hardware, perhaps a 
gallium driver in the guest could talk almost directly to a gallium 
driver on the host?

Looking at the work involved, I think it best to get an opengl -> opengl 
connection working in the short-term.

This is because that (should) represent a mostly 1-1 mapping which can 
hopefully be auto-generated to a large degree. And the result can talk 
to a range of current graphics hardware using existing drivers.

In  addition, it seems to me that a gallium -> opengl connection could 
be complex to write, as it is converting from hardware abstraction 
(gallium) to software abstraction (opengl).

And finally, there are not likely to be gallium drivers for the current 
nVidia or ATI graphics cards in the immediate future.

At the same time or immediately after the opengl -> opengl connection is 
being written, a gallium -> gallium connection could be built along the 
same lines. (The standard gallium softpipe implementation would also be 
a good place to start.) Then all that is needed is to wait for the rest 
of the gallium support for existing hardware to fill in.

Then for non-opengl Windows support, a gallium state tracker for 
Direct3D would allow Windows guest OSes to forward through a gallium 
driver to a host gallium system.

Paul Brook wrote:
> Getiing basic OpenGL working is fairly easy. The tricky bits are:
>
> - Multiple contexts.
>   
I presume you are referring to the question of whether to represent 
multiple contexts in the guest OS as one or multiple contexts in the host?
> - Window manager integration, and cliprects.
> - OpenGL extensions, particularly if you're going to be migrating between 
> different hosts..
>   
I presume we need a way for the opengl driver in the guest to correctly 
report the abilities of the host opengl (and video card)?


Thanks again for all your advice.

Cheers!
Nik