[Mesa-dev] [PATCH v3 0/9] Gallium Nine

[Stefan Dösinger]

Am 18.11.2014 um 23:31 schrieb Emil Velikov <emil.l.velikov at gmail.com>:
> Hmm the binaries do not seem to match the source. Am I missing something ?
Not sure. As you can see I've last touched them in January. It is possible that I have changed some things in the code and not updated the binaries on the server. I recommend to rebuild them yourself anyway, just for the sake of paranoia. I use Visual Studio on Windows, and you need the last DirectX SDK for the d3dx9 headers and libs, but I guess you can also use mingw with the right include and lib paths.

> On of the points in my earlier "rant" was - if wine is interested solely
> on improvements of the current code, and there is no interest/intensive
> to include an alternative solution it makes no sense to keep on
> pestering you guys.
We're solely interested on the current code until there's conclusive proof that running a performant d3d implementation on top of OpenGL is not possible by design. So far I have not seen any hard facts to support this claim. Yes, nine/st is faster on some drivers/games, but wined3d is faster on others. Wined3d with my (not yet upstreamed) CSMT patches beats Windows in a big number of games, although it still has performance problems in other games. On the Nvidia blob most performance problems with CSMT are not 3D-related any more, but are caused by expensive IPC that runs through wineserver.

The factoids so far suggest that the major problems with OpenGL is the on-demand shader compilation. That's something we can fix in Wine for the average case, although there will still be some corner cases where we have to generate a new shader on the fly (e.g. a texture type mismatch, or a flag change in Pixel Shader 1.x). Some games don't create the D3D shaders until they actually use them. Nvidia has an on-disk shader cache to improve the situation, but that's an ugly hack.

The other known problem is uniform updating in GLSL. UBOs may help here. The ARB-style environment constants work better for d3d's purposes than GLSL's per-shader uniforms.

I expect that there are more problems, most of them limited in nature and affecting only some games. That could be things like "D3D shader instruction X is handled inefficiently by GLSL", or "IDirect3DDevice9::ColorFill is slow because we have to build a full FBO in GL." Those are just guesses - hard facts are needed. nine/st is a good tool to extract such small performance problems from real-world games.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20141119/3d4a6c91/attachment.sig>