Open Source 3D stacks and WINE

[dungeon]

@bridgman

No one mention occlude queries on #radeon, so it's probably that. I think osiris was just fixed this:

http://www.nabble.com/R300-regression-td23108996.html

[chelobaka]

The FGLRX driver does export the GLX_SGIX_PBUFFER extension in Linux, and the Windows driver exports the WGL_ARB_PBUFFER extension. However, I am fairly certain that the implementation is bugged in both operating systems. As I posted on a previous thread:

Here is an example of pbuffer rendering in Windows, notice the transparent mini-map?


Here is the way it looks when rendered in Wine.


And finally, the way it should look, when rendered with d3d.


Note, that Nvidia drivers work just fine in Windows and Linux.

Intel drivers suffer the same problem with white minimap indoors in WoW AFAIK. Nvidia driver (which works fine here) installs its own OpenGL library instead of Mesa one. I'm not sure about fglrx, but if it uses Mesa library, should we look into Mesa stack for this bug?

[Kano]

fglrx does not replace so many files as nvidia but there are of course no mesa libs used when fglrx is installed.

[osiris]

occlusion queries support

Pretty much everything with "buffer" in the name is
On the other hand, it appears that osiris got Occlusion Queries working today. I think it was OQ anyways

I've done the OQ more than 3 weeks ago, but the patches were tested only on rs690 and rv530 (thanks to fpoibaf). I cannot find people willing to test it, and without proper testing on different cards I am not going to push it upstream.

[nanonyme]

Has anyone found a pbuffers bug that shows up in a simple test app ?

I always overrided pbuffers with fbo's in Wine anyway with an nVidia card, they were *much* more stable and faster for me. (There's a registry key for it) That is, OffscreenRenderingMode where the options are backbuffer (slowest, quite stable and default according to the manual), pbuffer (unstable for me) and fbo (works for me).
Edit: Also I wouldn't disregard the possibility of there being bugs with pbuffers and fbo's with Wine itself although I've gotten the impression they should be mostly fine.

[Alex W. Jackson]

I recall reading (possibly in the comments under a Wine bugzilla entry) that the reason Wine typically requires a more advanced GPU to run the same application than Windows (e.g. even with a driver that does everything the way Wine likes, you need a D3D10-level card to fully emulate D3D9) is because Wine has to do things like add additional instructions to shaders to translate differences between OpenGL and D3D in, for example, how texture coordinates are interpreted.

Now I've looked at the register documents AMD has released, and also at some Intel GPU register documents, and I've noticed that there are register bits all over the place specifying "D3D mode" or "OpenGL mode" for things like texture coordinates and whatever else differs between the two APIs. My question is, instead of WINE doing the "translating" from D3D to OpenGL, would it not make more sense to define some OpenGL extensions like "MESA_texcoords_like_that_other_api", and have the driver simply set the appropriate register to switch the card into "D3D mode" when an application uses those extensions.

I imagine such extensions wouldn't be useful for anything other than WINE, and so it wouldn't be worth the engineering effort for the proprietary driver developers to specify and implement them (plus it might antagonize Microsoft) but that should be a golden opportunity to showcase the strength of open source development. Has anyone from Mesa (figuratively) sat down with the Wine D3D developers and asked "if you could ask for any completely new OpenGL extensions you wanted, specifically for the purpose of translating from D3D to OpenGL, what would you ask for?"

I just discovered that there are (at least) three OpenGL extensions for exactly this purpose: GL_ARB_provoking_vertex, GL_ARB_fragment_coord_conventions, and GL_ARB_vertex_array_bgra. The contributor lists for these extensions are full of TransGaming and CodeWeavers guys, so I assume Wine and Cedega are using these extensions.

So, who's working on getting these extensions into the free Mesa drivers?

[agd5f]

I just discovered that there are (at least) three OpenGL extensions for exactly this purpose: GL_ARB_provoking_vertex, GL_ARB_fragment_coord_conventions, and GL_ARB_vertex_array_bgra. The contributor lists for these extensions are full of TransGaming and CodeWeavers guys, so I assume Wine and Cedega are using these extensions.

So, who's working on getting these extensions into the free Mesa drivers?

The r300, r600, and intel mesa drivers support GL_ARB_provoking_vertex and GL_ARB_vertex_array_bgra already.