[Qemu-devel] OpenGL in qemu

[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

Re: [Qemu-devel] OpenGL in qemu

[Paul Brook]

> 3. Have qemu dynamically locate and link to the host's opengl system.

This is fairly trivial, and what most applications do.

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

It should work on windows with very little modification. The problem is that 
very few windows applications use OpenGL.

Getiing basic OpenGL working is fairly easy. The tricky bits are:

- Multiple contexts.
- Window manager integration, and cliprects.
- OpenGL extensions, particularly if you're going to be migrating between 
different hosts..

You may want to take a look at gallium[1].  I expect that will provide a 
better medium term solution than opengl, especially if you care about 
windows/Direct3D.

[1] http://www.tungstengraphics.com/wiki/index.php/Gallium3D

Paul

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

Re: [Qemu-devel] OpenGL in qemu

[Dmitriy Kazimirov]

[-- Attachment #1: Type: text/plain, Size: 731 bytes --]

>
> 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.


Regarding D3D, if OpenGL drivers are working, it should be not too difficult
to do like Parallels Workstation for Mac does. Just get D3D->OpenGL
translator from Wine and use it as basis for D3D driver. And such translator
could be used by all 'virtual OpenGL' implementations

-- 
> --
> Best Regards,
> Dmitriy Kazimirov,
> Senior C#/C++ Developer
> of ISS Art, Ltd., Omsk, Russia
> Web: http://www.issart.com
> E-mail: dkazimirov@issart.com

[-- Attachment #2: Type: text/html, Size: 1118 bytes --]

Re: [Qemu-devel] OpenGL in qemu

[Gervase Lam]

> Date: Wed, 30 Apr 2008 11:07:36 +1000
> From: Nik <qemu@babel.homelinux.net>
> Subject: Re: [Qemu-devel] OpenGL in qemu

> 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)

Fabrice made the following suggestion, which I am only just(!) beginning
to understand:

<http://lists.gnu.org/archive/html/qemu-devel/2006-11/msg00149.html>

Essentially, I think he would like to see something like the following:

(Guest driver) -> (pseudo PCI adapter emulated by QEMU)-> (Host gfx lib)

This would allow any host to benefit without having to write host
specific code to handle this.  I think that was the point Fabrice was
making.

Thanks,
Gervase.

Re: [Qemu-devel] OpenGL in qemu

[Nik]

Gervase wrote:
> >/ Date: Wed, 30 Apr 2008 11:07:36 +1000/
> >/ From: Nik <address@hidden>/
> >/ Subject: Re: [Qemu-devel] OpenGL in qemu/
>
> Fabrice made the following suggestion, which I am only just(!) beginning
> to understand:
>
> <http://lists.gnu.org/archive/html/qemu-devel/2006-11/msg00149.html>
>
> Essentially, I think he would like to see something like the following:
>
> (Guest driver) -> (pseudo PCI adapter emulated by QEMU)-> (Host gfx lib)
>
> This would allow any host to benefit without having to write host
> specific code to handle this.  I think that was the point Fabrice was
> making.
>   
I had already seen references to this post, and had some questions on 
that as well.
Your diagram makes the structure clearer, thank you.

Although I suspect that the diagram is actually mroe like the following:

(Guest driver) -> (opengl library) -> (pseudo PCI adaptor) -> (Host 
opengl lib)

In this arrangement, the job of the (pseudo PCI adaptor) is to pass 
through the opengl calls and results as quickly and efficiently as 
possible, with the possibility of managing some of the memory structures 
(such as opengl contexts).

So the questions I would like to ask of Fabrice is:
Q1: Would it be preferable to modify the existing Bochs VGA adaptor, or 
would it be better to write a new pci device using the Bochs VGA driver 
as a basis?

Q2: Would there be any benefit in giving the (pseudo PCI adaptor) a 
Gallium interface? Either as well as, or instead of, the proposed DMA 
interface?

Cheers!
Nik