Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
Am 18.11.2014 um 23:31 schrieb Emil Velikov emil.l.veli...@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. signature.asc Description: Message signed with OpenPGP using GPGMail ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 19 November 2014 00:26, Emil Velikov emil.l.veli...@gmail.com wrote: From a quick look at MSDN it seems to me that going the DDI (like) route would require substantial rework on the wine side. How much contribution from wine can we expect ? Would you have the chance to help with design/coding, or would you be (no disrespect here) limited to answering questions ? Yeah, it would require a significant amount of work on the wined3d side as well, which is part of the reason we'd like to make sure that work can't be avoided. I'm sure that not everything in mesa is perfect yet I've not seen (m)any bug reports from you guys. If/when you guys spot something broken/extremely slow please bugzilla it or send an email to the ML. I think for a part that's because I prefer sending patches when time allows. E.g. around 2010-2011 I sent a couple of patches, mostly for making the Wine tests pass on r600c and later r600g. These days the amount of time I can spend on Mesa is more limited, but at least r600g generally works pretty well for me. I know Stefan regularly runs tests on r300g and r600g and sends bug reports when something breaks. Speaking of feedback, please consider using GLX_MESA_query_renderer. It should help you (at least a bit) with the massive vendor/device/video_memory tables that you currently have. It's already on our (unfortunately fairly large) todo-list. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 19 November 2014 01:55, Marek Olšák mar...@gmail.com wrote: Before we start discussing what we can do about the OpenGL API overhead, we must get rid of the on-demand shader compilation. It's unacceptable to compile shaders when we should be rendering. This is one of the things that Nine fixes. I assume Wine does that because there can be several slightly-different variants of the same shader for various reasons. Well then we'll have to figure out how to reduce that number to 1. Pretty much. Although as Stefan mentioned there are likely going to be cases where it can't be avoided. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 17 November 2014 21:05, Emil Velikov emil.l.veli...@gmail.com wrote: - GL extensions I feel that it's a bit too much to shoot the project down, because it does not introduce GL extensions that will be useful. To clarify, that's not what I said. It's mostly just that I'd like to see some actual evidence for the (implicit) claim that the performance difference is largely due to inherent OpenGL API overhead. Considering the interface note able, would you say that any new implementation towards handling D3D9 in wine is acceptable ? If anything, it would have to be an interface approximately on the level of the DDI, like Jose mentioned. Can we work together so that both project benefit from this effort ? I like to think we've always had good relations with Mesa, even if we don't always agree on everything. In this specific case, I'm afraid we just have a pretty fundamental difference of opinion with the st/nine developers on what the right approach is. Feel free to send me an e-mail if you have Wine related questions / requests in any case though. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2014-11-18 19:36, schrieb Henri Verbeet: To clarify, that's not what I said. It's mostly just that I'd like to see some actual evidence for the (implicit) claim that the performance difference is largely due to inherent OpenGL API overhead. I have some microbenchmarks to measure API overhead of d3d and GL here: https://stefandoesinger.ddns.net/~git/perftest/ (self-signed cert) Binaries are here: https://stefandoesinger.ddns.net/~stefan/pts/ I had a chat with mannerov (I guess he's Axel Davy, according to /whois) on IRC, and he ran the drawprim and clear tests with gallium nine, wined3d and GL. His results show pretty much the same result in gallium nine and wined3d, and the GL result handily beats both of them. Mannerov says his system doesn't show a big difference in real games between wined3d and nine, so it would be nice to have more test results from other people who see a big difference in real-world games. Those benchmarks would be a first step in pointing out overhead differences between nine and wined3d and give some hints where they are. The GL result should show if the difference is due to overhead inside wined3d or the Mesa GL frontend. Obviously more tests are needed. The tests so far just cover plain draws, stream source changes, clears and vertex buffer uploads. I suspect that a major source of overhead are shader changes and / or shader constant / uniform changes. And so far all of those tests only cover CPU-side performance problems. -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUa7hjAAoJEN0/YqbEcdMwdoAP/1F9PL1VFbQcRnhBcv6sb1tp 6+R0Yx63U1f3OVfDmQ2qtgIq0Tj27G4KyfDRrNeHYygYxMGiWJm4ksHmb1E25WND 7TXLvcOdb5ZyFX9I1JPLR/fmA112DB/OzxYdvfCeLn2dS7zk7pvZ73Bz/NfugI6/ +k4GpP3/X9oGvcdy6JAMZ5SX7/7i3aFom0Ak2C+4vhKtdN/gslxitweH6DbkIT6g ogKTakj+sHV+dYHXwzpCMa3w1ZRK3A4VDRrVbJ/dXUOr+li774dlQaMQE3t7tjDK 3ax2sH7VcF4kCQnc3eocHDKAH8tjAffRWxLxW5F94AlPb14p9BAUCkvYGkb+KEfR DH4JIX5aJXSvNPLHLjQwDhvhbC2cEr8iMTCerHJllVJjROeXEbvsukj0rkMPAgjP aicp0fMQyS84GTKj0mwJ2fWZ/ja/UeZwOQv+4rj5adpv7X+pDm9C89dL0mOPWRn/ o73ObJkiAVR0XMqnUfAK5CEziLA985Hg8Fen1hGC221GVpwj+QMQp4dMRJkrLR17 BZgjv18TR40yQLPKGeNv+JbJVdbvZ4XzE0tAWuFpaefBOp2txt26P0KCz2iS58+H zOa6FxYDC5nMRIWqI4zCF4sKDz5JD0ymn8aYIgWubFEevwyzt7Ql2EACq62S4aYD N4Xb+Rjk0fu3ihPJiTuz =qxzo -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
Hi Stefan, On 18/11/14 21:21, Stefan Dösinger wrote: Am 2014-11-18 19:36, schrieb Henri Verbeet: To clarify, that's not what I said. It's mostly just that I'd like to see some actual evidence for the (implicit) claim that the performance difference is largely due to inherent OpenGL API overhead. I have some microbenchmarks to measure API overhead of d3d and GL here: https://stefandoesinger.ddns.net/~git/perftest/ (self-signed cert) Binaries are here: https://stefandoesinger.ddns.net/~stefan/pts/ Hmm the binaries do not seem to match the source. Am I missing something ? I had a chat with mannerov (I guess he's Axel Davy, according to /whois) on IRC, and he ran the drawprim and clear tests with gallium nine, wined3d and GL. His results show pretty much the same result in gallium nine and wined3d, and the GL result handily beats both of them. Mannerov says his system doesn't show a big difference in real games between wined3d and nine, so it would be nice to have more test results from other people who see a big difference in real-world games. Thanks for listing these test publicly. Now more people can give them a spin thus find some correlation. Or perhaps it's a case that the tests do not affect code paths that are faster with nine :\ Those benchmarks would be a first step in pointing out overhead differences between nine and wined3d and give some hints where they are. The GL result should show if the difference is due to overhead inside wined3d or the Mesa GL frontend. Obviously more tests are needed. The tests so far just cover plain draws, stream source changes, clears and vertex buffer uploads. I suspect that a major source of overhead are shader changes and / or shader constant / uniform changes. And so far all of those tests only cover CPU-side performance problems. 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. Thank you for the input. Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 18/11/14 18:36, Henri Verbeet wrote: On 17 November 2014 21:05, Emil Velikov emil.l.veli...@gmail.com wrote: - GL extensions I feel that it's a bit too much to shoot the project down, because it does not introduce GL extensions that will be useful. To clarify, that's not what I said. It's mostly just that I'd like to see some actual evidence for the (implicit) claim that the performance difference is largely due to inherent OpenGL API overhead. An earlier link shows quite a few games that have noticeable perf impact. Feel free to grab anyone and do some analysis that you'd consider most appropriate. I fear I won't be able to help you out there :( Considering the interface note able, would you say that any new implementation towards handling D3D9 in wine is acceptable ? If anything, it would have to be an interface approximately on the level of the DDI, like Jose mentioned. This is a very nice first step. Thank you. From a quick look at MSDN it seems to me that going the DDI (like) route would require substantial rework on the wine side. How much contribution from wine can we expect ? Would you have the chance to help with design/coding, or would you be (no disrespect here) limited to answering questions ? Can we work together so that both project benefit from this effort ? I like to think we've always had good relations with Mesa, even if we don't always agree on everything. I'm sure that not everything in mesa is perfect yet I've not seen (m)any bug reports from you guys. If/when you guys spot something broken/extremely slow please bugzilla it or send an email to the ML. Good relations are based on mutual feedback :) Speaking of feedback, please consider using GLX_MESA_query_renderer. It should help you (at least a bit) with the massive vendor/device/video_memory tables that you currently have. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
Before we start discussing what we can do about the OpenGL API overhead, we must get rid of the on-demand shader compilation. It's unacceptable to compile shaders when we should be rendering. This is one of the things that Nine fixes. I assume Wine does that because there can be several slightly-different variants of the same shader for various reasons. Well then we'll have to figure out how to reduce that number to 1. This is probably related: We now have native support for D3DFVF_XYZRHW as a vertex shader flag in Gallium. r600g, radeonsi, llvmpipe, and softpipe support is done. I'm sure a few other drivers will follow, because it's a hard requirement for Nine - and that's how it should be. Marek On Tue, Nov 18, 2014 at 7:36 PM, Henri Verbeet hverb...@gmail.com wrote: On 17 November 2014 21:05, Emil Velikov emil.l.veli...@gmail.com wrote: - GL extensions I feel that it's a bit too much to shoot the project down, because it does not introduce GL extensions that will be useful. To clarify, that's not what I said. It's mostly just that I'd like to see some actual evidence for the (implicit) claim that the performance difference is largely due to inherent OpenGL API overhead. Considering the interface note able, would you say that any new implementation towards handling D3D9 in wine is acceptable ? If anything, it would have to be an interface approximately on the level of the DDI, like Jose mentioned. Can we work together so that both project benefit from this effort ? I like to think we've always had good relations with Mesa, even if we don't always agree on everything. In this specific case, I'm afraid we just have a pretty fundamental difference of opinion with the st/nine developers on what the right approach is. Feel free to send me an e-mail if you have Wine related questions / requests in any case though. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 14/11/14 14:14, Emil Velikov wrote: On 02/11/14 18:27, David Heidelberg wrote: Hello everyone! First I'd like thank you for great feedback. Sending third Gallium Nine merge request. We reduced number of commits to necessary minimum. I hope all proposed changes are incorporated in v3. Thank you To summarise: - Interface Afaict reusing gallium or wined3d internal interface is not an option for either project. - Two implementations On 14/11/14 16:15, Henri Verbeet wrote: The main issue is probably that we'd really like to avoid having two parallel implementations of the high-level d3d9 stuff. Indeed yet I don't think that anyone will be too happy to remove the existing one, and with nine using a completely different approach it only makes sense to have it alongside the more mature wine d3d. - Performance While I'm not an OpenGL/Direct3D expert, the idea of jumping over one hurdle (d3d hardware) as opposed to two (D3D OpenGL hardware) is always a win. I believe Marek nicely pointed the technical reasons. - GL extensions I feel that it's a bit too much to shoot the project down, because it does not introduce GL extensions that will be useful. After all the it aims to tackle the whole topic from a completely different angle. If you would like to propose new extensions, I don't think mesa devs will object. - Nine vs wine's d3d While not explicitly stated, there is a concern about using nine over wine's d3d library. Note that one has to _explicitly_ opt-in to use nine, with a fall-back to wine and also it does not hinder wine's d3d9,10,11... in any way. Henri, Considering the interface note able, would you say that any new implementation towards handling D3D9 in wine is acceptable ? Please note that I'm not talking about improving the existing one be that via GL extensions or otherwise. How about if such an implementation is disabled by default in the build, and people have to explicitly opt to (via regedit) use it ? A one that falls back to wine, when it does not work (missing driver or otherwise) and does not hinder your d3d10/d3d11 efforts ? If you're concerned about it's maintenance, I'm pretty sure that one of the guys can step in. If it's about wine mesa(nine) interface I would assume that the guys would love to hear your feedback (within reason of course). Lastly let's point out that there is a reason why we keep on talking about this - significant performance improvement [1] [2]. One that surpasses wine+CSMT and in some cases even the official/binary drivers on top of it. Can we work together so that both project benefit from this effort ? Thanks Emil [1] http://www.linuxsystems.it/2014/09/wine-vanilla-vs-csmt-d3dstream-vs-gallium-nine-vs-catalyst/ [2] https://www.youtube.com/playlist?list=PLfaZPGij0wwI69Bce1sbjLlcwRMWINYNy ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 17/11/14 20:05, Emil Velikov wrote: Henri, Considering the interface note able, would you say that any new implementation towards handling D3D9 in wine is acceptable ? Please note that I'm not talking about improving the existing one be that via GL extensions or otherwise. How about if such an implementation is disabled by default in the build, and people have to explicitly opt to (via regedit) use it ? A one that falls back to wine, when it does not work (missing driver or otherwise) and does not hinder your d3d10/d3d11 efforts ? If you're concerned about it's maintenance, I'm pretty sure that one of the guys can step in. If it's about wine mesa(nine) interface I would assume that the guys would love to hear your feedback (within reason of course). Lastly let's point out that there is a reason why we keep on talking about this - significant performance improvement [1] [2]. One that surpasses wine+CSMT and in some cases even the official/binary drivers on top of it. In case the above came as me being smart/cocky/disrespectful - it's meant to say (amongst other things): - If there is something we can do to improve things, please keep us in the loop. - People do not know the wine internals as you do, so any feedback and you can provide about a reasonable interface is greatly appreciated. Taking into account the whole we cannot really export gallium of course. Cheers, Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
Acked by me. I didn't review the state tracker code, but at least I didn't notice anything wrong with the changes to the auxiliary modules, and I don't obecjt having this merged back in now that it is being actively maintained, Jose From: mesa-dev mesa-dev-boun...@lists.freedesktop.org on behalf of Emil Velikov emil.l.veli...@gmail.com Sent: 14 November 2014 14:14 To: David Heidelberg; mesa-dev@lists.freedesktop.org Cc: emil.l.veli...@gmail.com Subject: Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine On 02/11/14 18:27, David Heidelberg wrote: Hello everyone! First I'd like thank you for great feedback. Sending third Gallium Nine merge request. We reduced number of commits to necessary minimum. I hope all proposed changes are incorporated in v3. Thank you Gents, Can we get an acked-by/reviewed-by for this ? Would be a shame to torture David to keep rebasing this for another three months. Afaics he's already applied to commit access with the sole perpose to maintain the state-tracker. Thanks Emil P.S. Patches 3 and 6 have minor comments to address. I don't mind if patch 6 is resolved after the merge. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddevd=AAIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzEm=eN-BbuqoGCTkisd-4qwlqZT03Gccr_3oPmVy9RTe370s=n4htOYU6cyo0-OAtl4G2eksxLIwAxGWHvtK16W4TdRUe= ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 02/11/14 18:27, David Heidelberg wrote: Hello everyone! First I'd like thank you for great feedback. Sending third Gallium Nine merge request. We reduced number of commits to necessary minimum. I hope all proposed changes are incorporated in v3. Thank you Gents, Can we get an acked-by/reviewed-by for this ? Would be a shame to torture David to keep rebasing this for another three months. Afaics he's already applied to commit access with the sole perpose to maintain the state-tracker. Thanks Emil P.S. Patches 3 and 6 have minor comments to address. I don't mind if patch 6 is resolved after the merge. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On Fri, Nov 14, 2014 at 9:14 AM, Emil Velikov emil.l.veli...@gmail.com wrote: On 02/11/14 18:27, David Heidelberg wrote: Hello everyone! First I'd like thank you for great feedback. Sending third Gallium Nine merge request. We reduced number of commits to necessary minimum. I hope all proposed changes are incorporated in v3. Thank you Gents, Can we get an acked-by/reviewed-by for this ? Would be a shame to torture David to keep rebasing this for another three months. To the best of my knowledge, wine has no intent on merging anything related to nine/st. There are no tests, either. What's the path forward for this project? I know it's a pain to maintain out of tree, but that alone isn't a good reason to merge something. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 14 November 2014 16:21, Ilia Mirkin imir...@alum.mit.edu wrote: To the best of my knowledge, wine has no intent on merging anything related to nine/st. That's a bit broader than I'd put it, but yes, in it's current form this is not something we'd merge. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
We plan make automatized tests based on apitrace (documented how to use it with wine just few days ago) of used games. Also we have wine tests. About merging to wine, it needs more work to be done, but in generally, we have packages for wide range of distributions, inlucluding livecd etc. Maintaining it out-of tree make us bisecting more difficult, so it would be really blessing to have it in upstream repository. David On 11/14/2014 04:21 PM, Ilia Mirkin wrote: On Fri, Nov 14, 2014 at 9:14 AM, Emil Velikov emil.l.veli...@gmail.com wrote: On 02/11/14 18:27, David Heidelberg wrote: Hello everyone! First I'd like thank you for great feedback. Sending third Gallium Nine merge request. We reduced number of commits to necessary minimum. I hope all proposed changes are incorporated in v3. Thank you Gents, Can we get an acked-by/reviewed-by for this ? Would be a shame to torture David to keep rebasing this for another three months. To the best of my knowledge, wine has no intent on merging anything related to nine/st. There are no tests, either. What's the path forward for this project? I know it's a pain to maintain out of tree, but that alone isn't a good reason to merge something. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 11/14/2014 04:31 PM, Henri Verbeet wrote: On 14 November 2014 16:21, Ilia Mirkin imir...@alum.mit.edu wrote: To the best of my knowledge, wine has no intent on merging anything related to nine/st. That's a bit broader than I'd put it, but yes, in it's current form this is not something we'd merge. At this moment we still improving wine tests compliance and catching bugs. We're ready to accept any ideas to make it better, which helps accepting into wine upstream. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On Fri, Nov 14, 2014 at 10:31 AM, Henri Verbeet hverb...@gmail.com wrote: On 14 November 2014 16:21, Ilia Mirkin imir...@alum.mit.edu wrote: To the best of my knowledge, wine has no intent on merging anything related to nine/st. That's a bit broader than I'd put it, but yes, in it's current form this is not something we'd merge. Is there a different form that you believe would be more likely to be merged? -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 14 November 2014 16:36, Ilia Mirkin imir...@alum.mit.edu wrote: Is there a different form that you believe would be more likely to be merged? The main issue is probably that we'd really like to avoid having two parallel implementations of the high-level d3d9 stuff. I.e., anything dealing with (d3d9) devices, stateblocks, swapchains, etc. We'd potentially be open to using something closer to the Gallium interface instead of OpenGL on the backend in wined3d. In that scenario wined3d would essentially be the statetracker. The main issue with that approach has always been that the Gallium statetracker/driver interface isn't meant to be stable, and neither is the internal interface between wined3d and e.g. d3d9. (So it wouldn't help to e.g. move wined3d into the Mesa tree either.) Another consideration is that while the Gallium interface is a better match than OpenGL for Direct3D in some places, I'm not necessarily convinced that that's something that couldn't be fixed with appropriate GL extensions. To give an example, it's possible that translating D3D bytecode to TGSI instead of GLSL ends up with better shader code for the hardware. Unfortunately that kind of analysis is completely missing as far as I'm aware, but if that were the case, it would probably be fixable by making some improvements to the GLSL compiler. If that's not possible for some reason we could consider adding an extension for authoring shaders in TGSI instead of GLSL, and so on. I guess the basic point is that replacing OpenGL is a pretty big hammer, that would need corresponding amounts of analysis and justification. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On Fri, Nov 14, 2014 at 11:15 AM, Henri Verbeet hverb...@gmail.com wrote: On 14 November 2014 16:36, Ilia Mirkin imir...@alum.mit.edu wrote: Is there a different form that you believe would be more likely to be merged? The main issue is probably that we'd really like to avoid having two parallel implementations of the high-level d3d9 stuff. I.e., anything dealing with (d3d9) devices, stateblocks, swapchains, etc. We'd potentially be open to using something closer to the Gallium interface instead of OpenGL on the backend in wined3d. In that scenario wined3d would essentially be the statetracker. The main issue with that approach has always been that the Gallium statetracker/driver interface isn't meant to be stable, and neither is the internal interface between wined3d and e.g. d3d9. (So it wouldn't help to e.g. move wined3d into the Mesa tree either.) Dave Airlie's virgl work is creating a gallium driver which actually uses OpenGL for hardware. I'm not sure how far he is, but I believe he has enough for GL3. This could be a way forward towards *only* using gallium (since otherwise you'd still have to have an OpenGL-based backend for the hw/platforms that don't have gallium drivers). However gallium will never support fixed-function hardware, so that may still not work for you. Another consideration is that while the Gallium interface is a better match than OpenGL for Direct3D in some places, I'm not necessarily convinced that that's something that couldn't be fixed with appropriate GL extensions. To give an example, it's possible that translating D3D bytecode to TGSI instead of GLSL ends up with better shader code for the hardware. Unfortunately that kind of analysis is completely missing as far as I'm aware, but if that were the case, it would probably be fixable by making some improvements to the GLSL compiler. If that's not possible for some reason we could consider adding an extension for authoring shaders in TGSI instead of GLSL, and so on. I guess the basic point is that replacing OpenGL is a pretty big hammer, that would need corresponding amounts of analysis and justification. While I don't have this justification, I always just assumed this was due to mismatches between how d3d wanted to do things and how OpenGL let you do things, so you ended up having to do some fairly heavy-handed things in OpenGL solely due to the silliness of the API. Let's say that all such things could be identified and extensions created for, you'd still end up effectively managing 2 backends -- one that assumes that the various d3d-helper extensions are there, and one that doesn't. I strongly doubt that the performance increases are due to better d3d9 bytecode - TGSI conversion than - glsl - tgsi conversion -- most serious backends (r600, radeonsi, nouveau) have optimizing compilers that should take care of such issues. They won't, however, take care of issues where you had to change the way resources are managed, the data passed to the GPU, etc. Anyways, from your comments it sounds like the only way forward and given the current capabilities of nine/st would be to create some sort of out-of-tree solution that plugs into wine, providing native d3d9.dll or whatever it's called. That way you guys aren't stuck maintaining 2 backends, and people can get improved performance on d3d9 games on linux. Henri, if you take the fact that people want to use nine/st in its ~current form on linux as a given, is there a different, simpler approach that I'm overlooking? Cheers, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
[...] We'd potentially be open to using something closer to the Gallium interface instead of OpenGL on the backend in wined3d. In that scenario wined3d would essentially be the statetracker. The main issue with that approach has always been that the Gallium statetracker/driver interface isn't meant to be stable, and neither is the internal interface between wined3d and e.g. d3d9. Yes, I don't recommend gallium for that. It sounds you want to design a WINE D3D9 DDI pretty much along the lines of the WDDM D3D9 DDI: http://msdn.microsoft.com/en-us/library/windows/hardware/ff552927(v=vs.85).aspx Basically, the runtime is one, but there would be two implementations of that DDI. Runtime would do validation, keep copy of current state for application state queries, etc. Jose From: mesa-dev mesa-dev-boun...@lists.freedesktop.org on behalf of Henri Verbeet hverb...@gmail.com Sent: 14 November 2014 16:15 To: Ilia Mirkin Cc: mesa-dev@lists.freedesktop.org; Emil Velikov; David Heidelberg Subject: Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine On 14 November 2014 16:36, Ilia Mirkin imir...@alum.mit.edu wrote: Is there a different form that you believe would be more likely to be merged? The main issue is probably that we'd really like to avoid having two parallel implementations of the high-level d3d9 stuff. I.e., anything dealing with (d3d9) devices, stateblocks, swapchains, etc. We'd potentially be open to using something closer to the Gallium interface instead of OpenGL on the backend in wined3d. In that scenario wined3d would essentially be the statetracker. The main issue with that approach has always been that the Gallium statetracker/driver interface isn't meant to be stable, and neither is the internal interface between wined3d and e.g. d3d9. (So it wouldn't help to e.g. move wined3d into the Mesa tree either.) Another consideration is that while the Gallium interface is a better match than OpenGL for Direct3D in some places, I'm not necessarily convinced that that's something that couldn't be fixed with appropriate GL extensions. To give an example, it's possible that translating D3D bytecode to TGSI instead of GLSL ends up with better shader code for the hardware. Unfortunately that kind of analysis is completely missing as far as I'm aware, but if that were the case, it would probably be fixable by making some improvements to the GLSL compiler. If that's not possible for some reason we could consider adding an extension for authoring shaders in TGSI instead of GLSL, and so on. I guess the basic point is that replacing OpenGL is a pretty big hammer, that would need corresponding amounts of analysis and justification. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddevd=AAIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzEm=o3EpupCH7razLQXx0J0R5qQH6tzqk37RKYUG-_pJTl0s=35b52J3rqlzw27gT9LOmvCEHU8Vau408cZeCj5kRU1Ae= ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 14/11/2014 17:15, Henri Verbeet wrote : On 14 November 2014 16:36, Ilia Mirkin imir...@alum.mit.edu wrote: Is there a different form that you believe would be more likely to be merged? The main issue is probably that we'd really like to avoid having two parallel implementations of the high-level d3d9 stuff. [] Hi, We understand the will of wine devs not to support two implementations. However first, we will maintain that implementation, and the wine bits are rather small (a few files). It's more important for us to be merged in Mesa, because it is much easier for users to install a custom wine build (via playOnLinux, etc) than Mesa. Second d3d9 as gallium state tracker seems much easier than d3d9 on OpenGL. As for me, I contributed only since a few months ago, and was able to implement a lot of things quite easily, for exemple: . Respect the number of backbuffer asked by the app (as far as I know wine doesn't support = 2 and behaves like 1) . Support the Render-ahead d3d9 behaviour (d3d9 doesn't have tripple buffering like Opengl can have) . wine seems to have a lot of issues with stuttering, etc. We have control of throttling and vsync, and thus don't have any particular issue there . We have very good DRI_PRIME support (better than what GLX has currently). The fact that nine was develloped so fast by few devs show well that it was easier. Some glitches that wine has do not appear on nine. (we have others, but we fix them rapidly when we find them). Nine gets better performance than wine. On my AMD hd 7730m, I get a consistent 10% gain (I'm gpu limited). Others with better cards get better gains. But above all, games fell much more playable due to stable framerate. Third Nine doesn't harm wine implementation. The user explicitly enable/disable Nine support in wine, and if it is enabled and fails to load, it will fallback to normal wine support. User gets a message in console to tell him why it failed/ if Nine is activated. I hope these arguments will help convince you, Axel Davy ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 14 November 2014 17:37, Ilia Mirkin imir...@alum.mit.edu wrote: Dave Airlie's virgl work is creating a gallium driver which actually uses OpenGL for hardware. I'm not sure how far he is, but I believe he has enough for GL3. This could be a way forward towards *only* using gallium (since otherwise you'd still have to have an OpenGL-based backend for the hw/platforms that don't have gallium drivers). However gallium will never support fixed-function hardware, so that may still not work for you. Fixed-function hardware is becoming less and less relevant, but on the other hand we try to avoid breaking things that currently work. But yes, that's certainly something that's interesting to see how it turns out. Another consideration is that while the Gallium interface is a better match than OpenGL for Direct3D in some places, I'm not necessarily convinced that that's something that couldn't be fixed with appropriate GL extensions. To give an example, it's possible that translating D3D bytecode to TGSI instead of GLSL ends up with better shader code for the hardware. Unfortunately that kind of analysis is completely missing as far as I'm aware, but if that were the case, it would probably be fixable by making some improvements to the GLSL compiler. If that's not possible for some reason we could consider adding an extension for authoring shaders in TGSI instead of GLSL, and so on. I guess the basic point is that replacing OpenGL is a pretty big hammer, that would need corresponding amounts of analysis and justification. While I don't have this justification, I always just assumed this was due to mismatches between how d3d wanted to do things and how OpenGL let you do things, so you ended up having to do some fairly heavy-handed things in OpenGL solely due to the silliness of the API. Well yes, but the issues tend to be things like those solved by ARB_clip_control, ARB_vertex_array_bgra, ARB_provoking_vertex, etc. Let's say that all such things could be identified and extensions created for, you'd still end up effectively managing 2 backends -- one that assumes that the various d3d-helper extensions are there, and one that doesn't. Yes, but that's much more limited in scope than replacing all of OpenGL. I strongly doubt that the performance increases are due to better d3d9 bytecode - TGSI conversion than - glsl - tgsi conversion -- most serious backends (r600, radeonsi, nouveau) have optimizing compilers that should take care of such issues. It was just an example, but at least in the past I've seen for example the translation for D3D cnd and cmp result in pretty sub-optimal code in r600g. In GLSL 1.30 and up mix() with a bool argument could perhaps make it easier for the driver to end up with something reasonable. But not knowing where the actual differences/advantages are is a large part of what makes it hard to discuss st/nine in concrete terms from a Wine perspective. Anyways, from your comments it sounds like the only way forward and given the current capabilities of nine/st would be to create some sort of out-of-tree solution that plugs into wine, providing native d3d9.dll or whatever it's called. That way you guys aren't stuck maintaining 2 backends, and people can get improved performance on d3d9 games on linux. Henri, if you take the fact that people want to use nine/st in its ~current form on linux as a given, is there a different, simpler approach that I'm overlooking? Probably not. For what it's worth, while I think the approach of doing the analysis mentioned above will ultimately have better results both for Wine and other GL applications, I realise very well that that's real work and not necessarily a lot of fun. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 14 November 2014 17:42, Jose Fonseca jfons...@vmware.com wrote: [...] We'd potentially be open to using something closer to the Gallium interface instead of OpenGL on the backend in wined3d. In that scenario wined3d would essentially be the statetracker. The main issue with that approach has always been that the Gallium statetracker/driver interface isn't meant to be stable, and neither is the internal interface between wined3d and e.g. d3d9. Yes, I don't recommend gallium for that. It sounds you want to design a WINE D3D9 DDI pretty much along the lines of the WDDM D3D9 DDI: http://msdn.microsoft.com/en-us/library/windows/hardware/ff552927(v=vs.85).aspx Basically, the runtime is one, but there would be two implementations of that DDI. Runtime would do validation, keep copy of current state for application state queries, etc. Yeah, essentially. In a way we already have that kind of interface, but it's wined3d internal instead of a proper API. And of course we'll want d3d10/11 as well at some point. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 14 November 2014 17:52, Axel Davy axel.d...@ens.fr wrote: Second d3d9 as gallium state tracker seems much easier than d3d9 on OpenGL. As for me, I contributed only since a few months ago, and was able to implement a lot of things quite easily, for exemple: . Respect the number of backbuffer asked by the app (as far as I know wine doesn't support = 2 and behaves like 1) . Support the Render-ahead d3d9 behaviour (d3d9 doesn't have tripple buffering like Opengl can have) . wine seems to have a lot of issues with stuttering, etc. We have control of throttling and vsync, and thus don't have any particular issue there Most of the stuttering I'm aware of is GLSL compiler related. . We have very good DRI_PRIME support (better than what GLX has currently). The fact that nine was develloped so fast by few devs show well that it was easier. I don't want to sound overly negative, but I'm afraid that what you're seeing is mostly just the first 80% of any project being a lot easier than the last 1% or so. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
Le 14/11/2014 18:40, Henri Verbeet a écrit : On 14 November 2014 17:52, Axel Davy axel.d...@ens.fr wrote: Second d3d9 as gallium state tracker seems much easier than d3d9 on OpenGL. As for me, I contributed only since a few months ago, and was able to implement a lot of things quite easily, for exemple: . Respect the number of backbuffer asked by the app (as far as I know wine doesn't support = 2 and behaves like 1) . Support the Render-ahead d3d9 behaviour (d3d9 doesn't have tripple buffering like Opengl can have) . wine seems to have a lot of issues with stuttering, etc. We have control of throttling and vsync, and thus don't have any particular issue there Most of the stuttering I'm aware of is GLSL compiler related. As far as I have seen with our logs, games generally compile shaders during game load, but then are done with it. Do you mean you compile them again and again ? . We have very good DRI_PRIME support (better than what GLX has currently). The fact that nine was develloped so fast by few devs show well that it was easier. I don't want to sound overly negative, but I'm afraid that what you're seeing is mostly just the first 80% of any project being a lot easier than the last 1% or so. I'm not expert, but I think we have sufficiently complex apps working perfectly to say we are more than 80% and near wine state (again, wine has some bugs we haven't, and nine has some bugs wine doesn't have, but that seems easier to solve). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
While I agree it would be useful to have some D3D features in OpenGL as extensions to facilitate porting D3D apps to GL, I don't think the features would be very useful for playing Windows D3D games on Linux, because I don't believe that translating D3D to GL is even an option if you want performance. As a fallback, sure why not, but not as a solution that everybody should use. We should take the shortest route from D3D to hardware, skip all these useless translations between APIs and driver interfaces which only add more cruft into shaders and constant buffers and more state changes, resulting in more work for the CPU and the GPU in the end, skip all the useless shader IRs because D3D shaders are actually optimized to a certain degree by the D3D shader compiler from the beginning and only need a hw-specific shader backend. No useless layers and shader IRs, no fallbacks, no workarounds for missing features, no shader variants outside of the hw-specific code, and straight to hardware, please. Marek On Fri, Nov 14, 2014 at 5:15 PM, Henri Verbeet hverb...@gmail.com wrote: On 14 November 2014 16:36, Ilia Mirkin imir...@alum.mit.edu wrote: Is there a different form that you believe would be more likely to be merged? The main issue is probably that we'd really like to avoid having two parallel implementations of the high-level d3d9 stuff. I.e., anything dealing with (d3d9) devices, stateblocks, swapchains, etc. We'd potentially be open to using something closer to the Gallium interface instead of OpenGL on the backend in wined3d. In that scenario wined3d would essentially be the statetracker. The main issue with that approach has always been that the Gallium statetracker/driver interface isn't meant to be stable, and neither is the internal interface between wined3d and e.g. d3d9. (So it wouldn't help to e.g. move wined3d into the Mesa tree either.) Another consideration is that while the Gallium interface is a better match than OpenGL for Direct3D in some places, I'm not necessarily convinced that that's something that couldn't be fixed with appropriate GL extensions. To give an example, it's possible that translating D3D bytecode to TGSI instead of GLSL ends up with better shader code for the hardware. Unfortunately that kind of analysis is completely missing as far as I'm aware, but if that were the case, it would probably be fixable by making some improvements to the GLSL compiler. If that's not possible for some reason we could consider adding an extension for authoring shaders in TGSI instead of GLSL, and so on. I guess the basic point is that replacing OpenGL is a pretty big hammer, that would need corresponding amounts of analysis and justification. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 15 November 2014 03:25, Henri Verbeet hverb...@gmail.com wrote: On 14 November 2014 17:37, Ilia Mirkin imir...@alum.mit.edu wrote: Dave Airlie's virgl work is creating a gallium driver which actually uses OpenGL for hardware. I'm not sure how far he is, but I believe he has enough for GL3. This could be a way forward towards *only* using gallium (since otherwise you'd still have to have an OpenGL-based backend for the hw/platforms that don't have gallium drivers). However gallium will never support fixed-function hardware, so that may still not work for you. Fixed-function hardware is becoming less and less relevant, but on the other hand we try to avoid breaking things that currently work. But yes, that's certainly something that's interesting to see how it turns out. Another consideration is that while the Gallium interface is a better match than OpenGL for Direct3D in some places, I'm not necessarily convinced that that's something that couldn't be fixed with appropriate GL extensions. To give an example, it's possible that translating D3D bytecode to TGSI instead of GLSL ends up with better shader code for the hardware. Unfortunately that kind of analysis is completely missing as far as I'm aware, but if that were the case, it would probably be fixable by making some improvements to the GLSL compiler. If that's not possible for some reason we could consider adding an extension for authoring shaders in TGSI instead of GLSL, and so on. I guess the basic point is that replacing OpenGL is a pretty big hammer, that would need corresponding amounts of analysis and justification. While I don't have this justification, I always just assumed this was due to mismatches between how d3d wanted to do things and how OpenGL let you do things, so you ended up having to do some fairly heavy-handed things in OpenGL solely due to the silliness of the API. Well yes, but the issues tend to be things like those solved by ARB_clip_control, ARB_vertex_array_bgra, ARB_provoking_vertex, etc. Let's say that all such things could be identified and extensions created for, you'd still end up effectively managing 2 backends -- one that assumes that the various d3d-helper extensions are there, and one that doesn't. Yes, but that's much more limited in scope than replacing all of OpenGL. I strongly doubt that the performance increases are due to better d3d9 bytecode - TGSI conversion than - glsl - tgsi conversion -- most serious backends (r600, radeonsi, nouveau) have optimizing compilers that should take care of such issues. It was just an example, but at least in the past I've seen for example the translation for D3D cnd and cmp result in pretty sub-optimal code in r600g. In GLSL 1.30 and up mix() with a bool argument could perhaps make it easier for the driver to end up with something reasonable. But not knowing where the actual differences/advantages are is a large part of what makes it hard to discuss st/nine in concrete terms from a Wine perspective. It seems like a bad example, maybe someone could actually figure out why wine is slower, From my experience, its rarely been compiler optimisations that make a single massive difference, its probably something more architectural with having mismatches at other levels in the APIs and overheads of recompiling shaders. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 0/9] Gallium Nine
Hello everyone! First I'd like thank you for great feedback. Sending third Gallium Nine merge request. We reduced number of commits to necessary minimum. I hope all proposed changes are incorporated in v3. Thank you Axel Davy (2): nine: Add drirc options (v2) nine: Implement threadpool Christoph Bumiller (6): tgsi/ureg: add ureg_UARL shortcut (v2) winsys/sw/wrapper: implement is_displaytarget_format_supported for swrast gallium/auxiliary: implement sw_probe_wrapped gallium/auxiliary: add inc and dec alternative with return (v2) gallium/auxiliary: add contained and rect checks (v3) gallium/auxiliary: add dump functions for bind and transfer flags Joakim Sindholt (1): nine: Add state tracker nine for Direct3D9 (v2) configure.ac | 26 + include/D3D9/d3d9.h| 1858 +++ include/D3D9/d3d9caps.h| 387 +++ include/D3D9/d3d9types.h | 1797 ++ include/d3dadapter/d3dadapter9.h | 101 + include/d3dadapter/drm.h | 44 + include/d3dadapter/present.h | 137 + src/gallium/Makefile.am|4 + src/gallium/auxiliary/pipe-loader/pipe_loader.h| 11 + src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c | 22 + .../auxiliary/target-helpers/inline_sw_helper.h| 28 + src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h |1 + src/gallium/auxiliary/util/u_atomic.h | 78 + src/gallium/auxiliary/util/u_box.h | 230 ++ src/gallium/auxiliary/util/u_dump.h|6 + src/gallium/auxiliary/util/u_dump_defines.c| 86 + src/gallium/auxiliary/util/u_rect.h| 28 + src/gallium/state_trackers/nine/Makefile.am| 13 + src/gallium/state_trackers/nine/Makefile.sources | 73 + src/gallium/state_trackers/nine/README | 78 + src/gallium/state_trackers/nine/adapter9.c | 1081 ++ src/gallium/state_trackers/nine/adapter9.h | 137 + .../state_trackers/nine/authenticatedchannel9.c| 78 + .../state_trackers/nine/authenticatedchannel9.h| 65 + src/gallium/state_trackers/nine/basetexture9.c | 504 +++ src/gallium/state_trackers/nine/basetexture9.h | 138 + src/gallium/state_trackers/nine/cryptosession9.c | 115 + src/gallium/state_trackers/nine/cryptosession9.h | 86 + src/gallium/state_trackers/nine/cubetexture9.c | 274 ++ src/gallium/state_trackers/nine/cubetexture9.h | 79 + src/gallium/state_trackers/nine/device9.c | 3450 src/gallium/state_trackers/nine/device9.h | 798 + src/gallium/state_trackers/nine/device9ex.c| 396 +++ src/gallium/state_trackers/nine/device9ex.h| 148 + src/gallium/state_trackers/nine/device9video.c | 62 + src/gallium/state_trackers/nine/device9video.h | 57 + src/gallium/state_trackers/nine/guid.c | 66 + src/gallium/state_trackers/nine/guid.h | 36 + src/gallium/state_trackers/nine/indexbuffer9.c | 218 ++ src/gallium/state_trackers/nine/indexbuffer9.h | 88 + src/gallium/state_trackers/nine/iunknown.c | 126 + src/gallium/state_trackers/nine/iunknown.h | 153 + src/gallium/state_trackers/nine/nine_debug.c | 104 + src/gallium/state_trackers/nine/nine_debug.h | 135 + src/gallium/state_trackers/nine/nine_defines.h | 55 + src/gallium/state_trackers/nine/nine_dump.c| 813 + src/gallium/state_trackers/nine/nine_dump.h| 52 + src/gallium/state_trackers/nine/nine_ff.c | 2213 + src/gallium/state_trackers/nine/nine_ff.h | 32 + src/gallium/state_trackers/nine/nine_helpers.c | 100 + src/gallium/state_trackers/nine/nine_helpers.h | 176 + src/gallium/state_trackers/nine/nine_lock.c| 3319 +++ src/gallium/state_trackers/nine/nine_lock.h| 51 + src/gallium/state_trackers/nine/nine_pdata.h | 45 + src/gallium/state_trackers/nine/nine_pipe.c| 410 +++ src/gallium/state_trackers/nine/nine_pipe.h| 568 src/gallium/state_trackers/nine/nine_quirk.c | 49 + src/gallium/state_trackers/nine/nine_quirk.h | 36 + src/gallium/state_trackers/nine/nine_shader.c | 2959 + src/gallium/state_trackers/nine/nine_shader.h | 142 + src/gallium/state_trackers/nine/nine_state.c | 1489 + src/gallium/state_trackers/nine/nine_state.h | 234 ++ .../state_trackers/nine/nineexoverlayextension.c | 46 + .../state_trackers/nine/nineexoverlayextension.h | 49 + src/gallium/state_trackers/nine/pixelshader9.c | 172 + src/gallium/state_trackers/nine/pixelshader9.h | 82 + src/gallium/state_trackers/nine/query9.c | 358 ++
