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
