Compositing GL

[Roderick Colenbrander]

On Wednesday 22 August 2007 03:36, Chris Robinson wrote:
> Over the past several days, I've been working with some people in
> #winehackers on a way to help solve the problems Wine faces with OpenGL..
> namely the lack of useable onscreen pixel formats and broken child windown
> rendering. Here's a patch for your perusal in hopes to generate feedback.
>
> What this does is, it renders GL to an offscreen buffer the size of the
> window it's rendering to, first trying a redirected window (if you have the
> Xcomposite extension), then falling back to GLXPixmaps (which may be
> slower, especially if you don't have AIGLX). The offscreen buffer is then
> copied to the window it should be displaying on using X, acting in a manner
> nearly identical to how Vista composites OpenGL (as described here:
> http://www.opengl.org/pipeline/article/vol003_7/ ).

I'll add some more info here as for sure people will ask about it. In short 
during the Winex11.drv window management rewrite Wine lost dedicated X11 
windows for Direct3D/OpenGL (before everything had an X11 child window). This 
has broken windowed OpenGL for years.

Suggested solutions at the time were to use glxpixmap rendering. At the time 
that was only accelerated on Nvidia hardware. More about this below.

The other solution was the use of glScissor/glViewport to limit GL rendering 
to the place on the gui were GL was needed. This worked a bit on some drivers 
but there were SwapBuffers related issues, second it would also have clipping 
issues and the scissors/viewport override caused issues for pbuffers/fbos.

At the beginning of this year we looked at several methods of 'X11 child 
window injection' for GL. A few methods were tried. They had the same 
clipping issues as the scissors path but for the rest it worked. While it 
fixed most drawing issues, it got X event issues back. The win32 parent 
window would receive X expose events and in the end those would confuse 
programs.

The Xorg guys suggested that those events would get away when we would use 
automatic redirection using Composite. Even then the events are there though 
they are harmless but they still cause the same troubles.

The current solution takes advantage of (upcoming) changes in Xorg drivers. 
Thanks to Compiz and friends, developers are adding AIGLX, hw accelerated 
glxpixmap rendering and redirected gl rendering support to their display 
drivers. Right now all this stuff is still limited to Nvidia but other 
drivers are getting support. At least the intel driver and r300 will support 
it in Xorg 7.4 (you can get a preview of it in the TTM branches of both 
drivers, in case of Intel that's i915tex).

This solution is the best way to go. Luckily Microsoft made similar changes in 
Vista.

> There is a speed hit, however. The DX9 swap chains demo, which gets about
> 280 FPS for me normally, gets about 80 to 90 FPS with the compositing
> method. It seems to be a ceiling though, as other more GPU intense apps
> have no extra noticeable slow down. Still, as an optimization, it can
> render directly to the window when it's being used on the whole window and
> the selected pixel format matches the current visual (this bit is disabled
> in the patch since it's for testing offscreen rendering, but it's simple to
> re-enable).
Demos like DX9 swap chains / 3DMark are heavily GPU limited e.g. they push the 
card to its limits. Normal programs are most of the time cpu limited. They 
are GPU limited ofcourse if you run the program on a system which the program 
considers lowend.

Regards
Roderick Colenbrander