[wined3d] Converting Wined3d to use WGL instead of GLX
Hi all, A while back I had started to work on, and mostly completed, converting wined3d to using WGL instead of directly accessing glX functions. That was a few months ago, and it was a pretty big change, but not too difficult as WGL and GLX are very similar. However, my patch is now greatly out of date thanks to the excellent work progressing in wined3d. I was just interested in getting some feedback on whether anyone thinks this is something worth me continuing to pursue, or just drop it? As I see it, there are a few merits to having wined3d on wgl instead of glx. The biggest one being that all the glX code won't be duplicated in multiple places as it is now (dlls/opengl32 and dlls/wined3d). Along with that comes maintainability and consistency as all glX code would only exist in one place and would be shared by all, applications and wined3d alike. Work-arounds for the various glX revisions (recently discussed glx 1.2, 1.3, etc) would also be localized to a single dll. Of course, on the down side, we take a hit of one extra layer of indirection by going through WGL. However as WGL/glX functions are rarely called, this should be a minimal of a performance hit. All in all I think it would be worth while, but I'd still like to hear from others so as not to waste (a lot!) of my time. Regards, Aric
--- Aric Cyr <Aric.Cyr(a)gmail.com> wrote:
Hi all,
A while back I had started to work on, and mostly completed, converting wined3d to using WGL instead of directly accessing glX functions. That was a few months ago, and it was a pretty big change, but not too difficult as WGL and GLX are very similar.
However, my patch is now greatly out of date thanks to the excellent work progressing in wined3d. I was just interested in getting some feedback on whether anyone thinks this is something worth me continuing to pursue, or just drop it?
As I see it, there are a few merits to having wined3d on wgl instead of glx. The biggest one being that all the glX code won't be duplicated in multiple places as it is now (dlls/opengl32 and dlls/wined3d). Along with that comes maintainability and consistency as all glX code would only exist in one place and would be shared by all, applications and wined3d alike. Work-arounds for the various glX revisions (recently discussed glx 1.2, 1.3, etc) would also be localized to a single dll.
Of course, on the down side, we take a hit of one extra layer of indirection by going through WGL. However as WGL/glX functions are rarely called, this should be a minimal of a performance hit.
All in all I think it would be worth while, but I'd still like to hear from others so as not to waste (a lot!) of my time.
If wines WGL implementation is fully implemented then it may be a good idea switching to wgl, a wgl implemenatation would also make debugging much easier because wined3d can be run under windows to isolate problems. Nick Burns also started work on a wgl version of wined3d that I haven't got around to fully merging yet, I can send you the patch. Oliver.
Regards, Aric
___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
On 11/25/05, Oliver Stieber <oliver_stieber(a)yahoo.co.uk> wrote:
--- Aric Cyr <Aric.Cyr(a)gmail.com> wrote:
Hi all,
A while back I had started to work on, and mostly completed, converting wined3d to using WGL instead of directly accessing glX functions. That was a few months ago, and it was a pretty big change, but not too difficult as WGL and GLX are very similar.
However, my patch is now greatly out of date thanks to the excellent work progressing in wined3d. I was just interested in getting some feedback on whether anyone thinks this is something worth me continuing to pursue, or just drop it?
As I see it, there are a few merits to having wined3d on wgl instead of glx. The biggest one being that all the glX code won't be duplicated in multiple places as it is now (dlls/opengl32 and dlls/wined3d). Along with that comes maintainability and consistency as all glX code would only exist in one place and would be shared by all, applications and wined3d alike. Work-arounds for the various glX revisions (recently discussed glx 1.2, 1.3, etc) would also be localized to a single dll.
Of course, on the down side, we take a hit of one extra layer of indirection by going through WGL. However as WGL/glX functions are rarely called, this should be a minimal of a performance hit.
All in all I think it would be worth while, but I'd still like to hear from others so as not to waste (a lot!) of my time.
If wines WGL implementation is fully implemented then it may be a good idea switching to wgl, a wgl implemenatation would also make debugging much easier because wined3d can be run under windows to isolate problems.
Wine's WGL is well implemented, and probably more correct than what is in wined3d currently (well, last time I checked anyways).
Nick Burns also started work on a wgl version of wined3d that I haven't got around to fully merging yet, I can send you the patch.
Sure send me the patch (off list is fine). I was planning on restarting from scratch anyways, so I'd like to see what Nick had in mind and build on it. Regards, Aric -- Aric Cyr <Aric.Cyr at gmail dot com> (http://acyr.net)
If wines WGL implementation is fully implemented then it may be a good idea switching to wgl, a wgl implemenatation would also make debugging much easier because wined3d can be run under windows to isolate problems. Wasn't there also the idea of running WineD3D in Vista to allow the new 3D Desktop to run with full OpenGL support? I think Oliver mentioned this somewhere.
Stefan
--- Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
If wines WGL implementation is fully implemented then it may be a good idea switching to wgl, a wgl implemenatation would also make debugging much easier because wined3d can be run under windows to isolate problems. Wasn't there also the idea of running WineD3D in Vista to allow the new 3D Desktop to run with full OpenGL support? I think Oliver mentioned this somewhere.
So long as the dll doesn't need to be signed (or we can find someone to sign it!) that's still a possiblity. Oliver
Stefan
___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
Am Freitag, 25. November 2005 18:00 schrieb Jakob Eriksson:
Aric Cyr wrote:
All in all I think it would be worth while, but I'd still like to hear from others so as not to waste (a lot!) of my time.
ReactOS would benefit as well from your approach. From what I have read in the ReactOS forums, they don't like this approach, because they have the ability to implement real Direct3D. It's also expected to be much easier than the D3D->OGL approach, because a lot of D3D functionality is provided by the device drivers.
So, I don't think that they would benefit much.
Stefan Dösinger wrote:
Am Freitag, 25. November 2005 18:00 schrieb Jakob Eriksson:
Aric Cyr wrote:
All in all I think it would be worth while, but I'd still like to hear from others so as not to waste (a lot!) of my time.
ReactOS would benefit as well from your approach.
From what I have read in the ReactOS forums, they don't like this approach, because they have the ability to implement real Direct3D. It's also expected to be much easier than the D3D->OGL approach, because a lot of D3D functionality is provided by the device drivers.
So, I don't think that they would benefit much.
They would, but they don't know it. :-) It's quite conceivable for ReactOS to run on hardware where there is OpenGL support, but no vendor DirectX drivers. regards, Jakob
All in all I think it would be worth while, but I'd still like to hear from others so as not to waste (a lot!) of my time.
ReactOS would benefit as well from your approach. From what I have read in the ReactOS forums, they don't like this approach, because they have the ability to implement real Direct3D. It's also expected to be much easier than the D3D->OGL approach, because a lot of D3D functionality is provided by the device drivers.
So, I don't think that they would benefit much.
participants (4)
-
Aric Cyr -
Jakob Eriksson -
Oliver Stieber -
Stefan Dösinger