On Monday 14 August 2006 19:57, you wrote:
Hi Raphael,
Hi Roderick,
sorry for late response i was in holidays (and before that a long moving to my new apartment)
I'm not sure how well you are monitoring the wine-devel lists these days, so I'm also directing this mail directly to you. I have been trying to fix various problems in the Wine OpenGL code. See the attached email and the patch for more info.
Basicly I changed the opengl code to only advertise the format of wine's main visual. I think the changes I made are more or less correct to Alexandre changes like this sounded correct aswell. But as he isn't an OpenGL expert he wanted to know the opinion of others and especially from people who know the code well.
I already asked Lionel but he said that he isn't that familiar with the current code which you rewrote a while ago. To Lionel the format advertising change sounded correctly aswell although he hasn't checked the code.
Could you comment on the patch? (reply to the wine-devel list)
Regards, Roderick Colenbrander
-------- Original-Message -------- Datum: Mon, 14 Aug 2006 17:04:52 +0200 From: "Roderick Colenbrander" thunderbird2k@gmx.net To: wine-devel@winehq.org Subject: RFC: OpenGL x11drv rewrite (WoW fix)
Hi,
<snip>
For me your patch seems correct
Anyway the problem is you can add regression in cases: - application want a very specific needs that isn't compatible with current selected visual (use of SetPixelFormat before first CreateContext, now you don't care about user wanted PixelFormat) - application wants to create many context with not compatible pixel format (supported on windows)
So you may restore many of the original problems but fixed the more problematic problem of BadMatch :)
What it'll be interesting to do next is to move all low-level GLW/GLX utilities calls to x11drv to permit better access to x11drv internals (and to permit better portability on non GLX os, and better share with wined3d). This will help a lot for the famous bug of openGL chils windows.
And after that, when user use the SetPixelFormat API, find a way to change the default created wine visual (use of SetPixelFormat is only permited once on windows). The problem is that visual is created by default before the application specify it's needs (ie. when the windows is created). We have the same problem for WineD3D, many games create a window and after want to choose a specific frame buffer (and if not compatible with current visual -> problem)
I wanted to delay this visual creation (or better dynamically change this on X, if permited) but no chance (same problem for glwShareLists) :(
Keep your good job :)
Best Regards, Raphael
There's one big issue regarding windowed opengl rendering and pbuffers. A while ago Huw added some code for bitmap rendering using GLX Pixmaps. In the end our wglMakeCurrent checks whether the DC is used for offscreen rendering or not. If offscreen rendering is used (there's no distinction between a pixmap or a pbuffer!) it an indirect GLX Context as that's needed for pixmaps (mesa+dri doesn't accelerate it).
This code is also entered for games like World of Warcraft which use pbuffers. The main issue is that some glDrawBuffer line is called (single buffer emulation). In case of non-Nvidia users the indirect rendering context which shouldn't be needed for pbuffers is very bad, as most drivers don't accelerate indirect rendering yet. The glxpixmap code should be rewritten using pbuffers or perhaps there's a different way.
On irc someone suggested to create a new window for opengl rendering and put it on top of the place that needs rendering. He claimed that something similar is done on Windows.
This would solve the issues. I was also thinking about layering WineD3D on top of WGL also for the sake of portability and it will allow us to use WineD3D on Windows for testing purposes. It would be usefull if our opengl can atleast handle windowed rendering. I don't know the code that well to change it.
Roderick
For me your patch seems correct
Anyway the problem is you can add regression in cases:
- application want a very specific needs that isn't compatible with
current selected visual (use of SetPixelFormat before first CreateContext, now you don't care about user wanted PixelFormat)
- application wants to create many context with not compatible pixel
format (supported on windows)
So you may restore many of the original problems but fixed the more problematic problem of BadMatch :)
What it'll be interesting to do next is to move all low-level GLW/GLX utilities calls to x11drv to permit better access to x11drv internals (and to permit better portability on non GLX os, and better share with wined3d). This will help a lot for the famous bug of openGL chils windows.
And after that, when user use the SetPixelFormat API, find a way to change the default created wine visual (use of SetPixelFormat is only permited once on windows). The problem is that visual is created by default before the application specify it's needs (ie. when the windows is created). We have the same problem for WineD3D, many games create a window and after want to choose a specific frame buffer (and if not compatible with current visual -> problem)
I wanted to delay this visual creation (or better dynamically change this on X, if permited) but no chance (same problem for glwShareLists) :(
Keep your good job :)
Best Regards, Raphael
On Saturday 19 August 2006 17:26, Roderick Colenbrander wrote:
There's one big issue regarding windowed opengl rendering and pbuffers. A while ago Huw added some code for bitmap rendering using GLX Pixmaps. In the end our wglMakeCurrent checks whether the DC is used for offscreen rendering or not. If offscreen rendering is used (there's no distinction between a pixmap or a pbuffer!) it an indirect GLX Context as that's needed for pixmaps (mesa+dri doesn't accelerate it).
This code is also entered for games like World of Warcraft which use pbuffers. The main issue is that some glDrawBuffer line is called (single buffer emulation). In case of non-Nvidia users the indirect rendering context which shouldn't be needed for pbuffers is very bad, as most drivers don't accelerate indirect rendering yet. The glxpixmap code should be rewritten using pbuffers or perhaps there's a different way.
what about a flag for specifics glxpixmaps ?
On irc someone suggested to create a new window for opengl rendering and put it on top of the place that needs rendering. He claimed that something similar is done on Windows.
Yes i thought about the same :) But seems ugly to handle on x11drv (2 window for the same => redirect input, etc...)
This would solve the issues. I was also thinking about layering WineD3D on top of WGL also for the sake of portability and it will allow us to use WineD3D on Windows for testing purposes. It would be usefull if our opengl can atleast handle windowed rendering. I don't know the code that well to change it.
Problem with WineD3D on top of WGL is that we lost many of usefull APIs I think WineD3D on top of x11drv (as WGL on top of x11drv) should a the better way
Roderick
Regards, Raphael
In case of non-Nvidia users the indirect rendering
context which shouldn't be needed for pbuffers is very bad, as most
drivers
don't accelerate indirect rendering yet. The glxpixmap code should be rewritten using pbuffers or perhaps there's a different way.
what about a flag for specifics glxpixmaps ?
You mean an X flag? I have been thinking about setting some flag for DCs to which a pbuffer is associated. I'm not sure if I'm correct but from what I saw some WGL extension needs to be called to receive a DC for a pbuffer. If we could set a pbuffer flag in there and retrieve it in wglMakeCurrent it would work. I fear that this can only be done in a clean way if it code would be in x11drv :(
On irc someone suggested to create a new window for opengl rendering and put it on top of the place that needs rendering. He claimed that
something
similar is done on Windows.
Yes i thought about the same :) But seems ugly to handle on x11drv (2 window for the same => redirect input, etc...)
I doubt that Alexandre will allow something this :(
This would solve the issues. I was also thinking about layering WineD3D
on
top of WGL also for the sake of portability and it will allow us to use WineD3D on Windows for testing purposes. It would be usefull if our
opengl
can atleast handle windowed rendering. I don't know the code that well
to
change it.
Problem with WineD3D on top of WGL is that we lost many of usefull APIs I think WineD3D on top of x11drv (as WGL on top of x11drv) should a the better way
Perhaps that would be cleaner.
Roderick
In case of non-Nvidia users the indirect rendering
context which shouldn't be needed for pbuffers is very bad, as most
drivers
don't accelerate indirect rendering yet. The glxpixmap code should be rewritten using pbuffers or perhaps there's a different way.
what about a flag for specifics glxpixmaps ?
You mean an X flag? I have been thinking about setting some flag for DCs to which a pbuffer is associated. I'm not sure if I'm correct but from what I saw some WGL extension needs to be called to receive a DC for a pbuffer. If we could set a pbuffer flag in there and retrieve it in wglMakeCurrent it would work. I fear that this can only be done in a clean way if it code would be in x11drv :(
An evil way would be to not call SetPixelFormat from wglGetPbufferDCARB. When this isn't called the pixel format is set to 0. A call to GetPixelFormat will nicely return 0. A check to see if the pixel format is 0 could be used as a hack to distinguish between a pixmap and a pbuffer in case OBJ_MEMDC is set.
Roderick
Roderick Colenbrander wrote:
If we could set a pbuffer flag in there and retrieve it in wglMakeCurrent it would work. I fear that this can only be done in a clean way if it code would be in x11drv :(
I did that, I created a new field in the PDEVICE structure and used two new ExtEscape codes (SET_FLAGS/GET_FLAGS), but Alexandre doesn't want to add new ExtEscape codes.. That's why I hacked even more on wine and moved the wgl implementation to x11drv... and there they are, my old patches. I never bothered updating them though.
tom
I did that, I created a new field in the PDEVICE structure and used two new ExtEscape codes (SET_FLAGS/GET_FLAGS), but Alexandre doesn't want to add new ExtEscape codes.. That's why I hacked even more on wine and moved the wgl implementation to x11drv... and there they are, my old patches. I never bothered updating them though.
tom
We don't need very big changes. Basicly all code can be moved to x11drv. Then basicly we want access to our wglGetProcAddress function to get access to our wgl functions. We can dynamicly load those from opengl32 that way. All wgl functions in opengl32 can be stubs.I think this is the right way to do it. It works a bit more like a real ICD this way aswell. I believe that in case of a real ICD some ExtEscape-like call is used to retrieve a table with all exported opengl functions from an icd driver. It then does something similar to a GetProcAdress. The difference would be that we don't transfer the whole table but only a function to retrieve function calls.
Roderick
I did that, I created a new field in the PDEVICE structure and used two new ExtEscape codes (SET_FLAGS/GET_FLAGS), but Alexandre doesn't want to add new ExtEscape codes.. That's why I hacked even more on wine and moved the wgl implementation to x11drv... and there they are, my old patches. I never bothered updating them though.
tom
We don't need very big changes. Basicly all code can be moved to x11drv. Then basicly we want access to our wglGetProcAddress function to get access to our wgl functions. We can dynamicly load those from opengl32 that way. All wgl functions in opengl32 can be stubs.I think this is the right way to do it. It works a bit more like a real ICD this way aswell. I believe that in case of a real ICD some ExtEscape-like call is used to retrieve a table with all exported opengl functions from an icd driver. It then does something similar to a GetProcAdress. The difference would be that we don't transfer the whole table but only a function to retrieve function calls.
Roderick
I have asked Alexandre about this on irc. Basicly all we have to do is call GetModuleHandle("winex11.drv") and then we can use the standard GetProcAddress. That's all nothing else is needed :)
Roderick
Hi,
Problem with WineD3D on top of WGL is that we lost many of usefull APIs I think WineD3D on top of x11drv (as WGL on top of x11drv) should a the better way
WineD3D on top of WGL has the advantage that we can use our D3D libraries in windows too. This can be useful for testing(no other libs interfering), and it might come handy to use gl for D3D games in windows too, like d3d10 on xp once we have d3d10 support :-) . I personally prefer the way to support glX, wgl and agl in wined3d directly, without using wine's wgl or x11drv.
Raphael <fenix <at> club-internet.fr> writes:
This would solve the issues. I was also thinking about layering WineD3D on top of WGL also for the sake of portability and it will allow us to use WineD3D on Windows for testing purposes. It would be usefull if our opengl can atleast handle windowed rendering. I don't know the code that well to change it.
Problem with WineD3D on top of WGL is that we lost many of usefull APIs I think WineD3D on top of x11drv (as WGL on top of x11drv) should a the better way
Like what APIs? I did a patch (never published though) of porting wined3d to wgl... it worked fine and there was no problems. The only thing it does require is more strict coding guidelines so as to totally eliminate all glX calls and use their wgl alternatives. There should only be a few places where wined3d actually uses glX/wgl so there is no solid reason winded3d couldn't be layered on wgl which is then layered on x11drv.
The biggest issue I had when porting was the OpenGL extensions. All extensions had to be called through the wgl thunks to get the calling conventions right, but that isn't hard, just a little extra initial work.
- Aric
The biggest issue I had when porting was the OpenGL extensions. All extensions had to be called through the wgl thunks to get the calling conventions right, but that isn't hard, just a little extra initial work.
- Aric
I have done the same a while ago. The calling convention first was a pain (it led to strange crashes) but in the end it worked fine by adjusting GLAPIENTRY :)
Roderick
-
Aric Cyr -
Raphael -
Roderick Colenbrander -
Stefan Dösinger -
Tomas Carnecky