I need to preload my own library with a custom glXSwapBuffers(). But wine opengl libGL.so directly so there's no way to do it.
I've ended up doing this: glXSwapBuffersType preload__glXSwapBuffers = (glXSwapBuffersType) wine_dlsym(RTLD_DEFAULT, "glXSwapBuffers", NULL, 0); preload__glXSwapBuffers(gdi_display, physDev->drawable);
but that is not a nice solution.
What about linking x11drv directly with libGL?
tom
On Wed, Oct 12, 2005 at 11:55:10AM +0200, Tomas Carnecky wrote:
I need to preload my own library with a custom glXSwapBuffers(). But wine opengl libGL.so directly so there's no way to do it.
Out of curiosity, why do you need this ?
What about linking x11drv directly with libGL?
If we do this, we will get a hard dependency between Wine and OpenGL which will lead to a lot of packaging nightmares.
Lionel
Lionel Ulmer wrote:
On Wed, Oct 12, 2005 at 11:55:10AM +0200, Tomas Carnecky wrote:
I need to preload my own library with a custom glXSwapBuffers(). But wine opengl libGL.so directly so there's no way to do it.
Out of curiosity, why do you need this ?
I've cerated a fraps-like library that hooks glXSwapBuffers() so I can make a movie while playing World of Warcraft.
What about linking x11drv directly with libGL?
If we do this, we will get a hard dependency between Wine and OpenGL which will lead to a lot of packaging nightmares.
I don't really see any dfference between dlopen("libGL") at run-time and linking x11drv with libGL at compile-time..
tom
On Sat, Oct 22, 2005 at 08:39:28PM +0200, Tomas Carnecky wrote:
I don't really see any dfference between dlopen("libGL") at run-time and linking x11drv with libGL at compile-time..
Well, suppose you want to do a 'full-blown' Wine distribution. You would then link to libGL at compile time. And then suppose someone uses your package on a machine without GL installed => the guy will not be able to do anything as he won't be able to load the graphics driver (this case actually happened some time back).
This is why we try to have less and less 'hard' dependencies in the Wine code and more and more 'soft' ones (which means that you can build Wine on a machine with all dependecies met while having this package still work on a much less feature-full box).
Of course, in cases where the dependency is really mandatory (like the GL dependency in the OpenGL32.DLL) we do the hard linking :-)
Lionel
Lionel Ulmer wrote:
On Sat, Oct 22, 2005 at 08:39:28PM +0200, Tomas Carnecky wrote:
I don't really see any dfference between dlopen("libGL") at run-time and linking x11drv with libGL at compile-time..
Well, suppose you want to do a 'full-blown' Wine distribution. You would then link to libGL at compile time. And then suppose someone uses your package on a machine without GL installed => the guy will not be able to do anything as he won't be able to load the graphics driver (this case actually happened some time back).
Well.. then make opengl a wine requirement... or build two packages: wine with and without opengl.. (after all there are --with-opengl and --without-opengl configure options) I personally would vore for the first option, make opengl a wine requirement, we'll soon have opengl integrated into the xserver (Xgl etc.) so sooner or later everyone will need to have an opengl implementation installed.
opengl should be installed per default on all desktop boxes (at least through mesa in pure-GPL duistributions that don't want to have any proprietary binaries)..
tom
On Sat, Oct 22, 2005 at 11:06:14PM +0200, Tomas Carnecky wrote:
I personally would vore for the first option, make opengl a wine requirement, we'll soon have opengl integrated into the xserver (Xgl etc.) so sooner or later everyone will need to have an opengl implementation installed.
Well, trust me on that one, but some times ago, Wine did link directly to OpenGL. But seeing the number of broken packages (i.e. did not advertise the GL dependency) and the time spent on bug reports / support requests, it was decided to move to a run-time link scheme.
And I think there are more people without GL installed (and without even a clue to what GL is) than one wanting to play pre-link tricks to override GL.
opengl should be installed per default on all desktop boxes (at least through mesa in pure-GPL duistributions that don't want to have any proprietary binaries)..
Maybe when it will be really mandatory we can switch back to 'hard' linking. But for now, I think GL is not yet pre-installed on all distributions and we will still have to wait a while to get to the Xgl and all other eye-candy infested stuff they are writing :-)
Lionel
Lionel Ulmer wrote:
On Sat, Oct 22, 2005 at 11:06:14PM +0200, Tomas Carnecky wrote:
I personally would vore for the first option, make opengl a wine requirement, we'll soon have opengl integrated into the xserver (Xgl etc.) so sooner or later everyone will need to have an opengl implementation installed.
Well, trust me on that one, but some times ago, Wine did link directly to OpenGL. But seeing the number of broken packages (i.e. did not advertise the GL dependency) and the time spent on bug reports / support requests, it was decided to move to a run-time link scheme.
And I think there are more people without GL installed (and without even a clue to what GL is) than one wanting to play pre-link tricks to override GL.
those people don't need to know what opengl is.. the distribution packager needs to make wine depend on opengl.. and they didn't.. so it was their fault.. I don't see why you (eg. wine developers) should need to fix something (it's not really a fix, just a workaround) that is caused by someone else (eg. the distribution packagers).
you could make --without-opengl the default option and those who know that they have opengl installed could enable it. Or why does this option exist after all? If wine works when compiled with --with-opengl and there is no opengl library, this switch seems useless in my eyes.
like with other packages that require some strange libraries, why can't opengl be a 'hard' dependency for wine?
you can say: "without opengl no wine, if you want wine, get opengl, you can get one for free from your distributor or www.mesa3d.org" problem solved !
tom
On Sat, Oct 22, 2005 at 11:33:45PM +0200, Tomas Carnecky wrote:
those people don't need to know what opengl is.. the distribution packager needs to make wine depend on opengl.. and they didn't.. so it was their fault..
Yes, but tell that to the users who complain to us 'Wine is broken, it does not work on my box, it's crap'. Wine is already somewhat hard to package, so why should we make the life of packagers harder ?
And frankly, I find it nice to only have the libraries that really need it (opengl and wined3d in the current tree) hard-link to OpenGL. That means that people can ship a 'work anywhere' Wine without even having to check the GL dependency (as Wine will handle it gracefully for them): if GL is installed, Wine supports it, if not, Wine will work except for OpenGL32.DLL and D3D8/9.DLL (which is to be expected).
I don't see why you (eg. wine developers) should need to fix something (it's not really a fix, just a workaround) that is caused by someone else (eg. the distribution packagers).
See before. It's Wine's image that is hurt by this, not the packagers.
like with other packages that require some strange libraries, why can't opengl be a 'hard' dependency for wine?
I would reverse the question: why should it be when only 2 DLLs over the 200 Wine provides needs it ?
Lionel
Am Mittwoch, 12. Oktober 2005 11:55 schrieb Tomas Carnecky:
I need to preload my own library with a custom glXSwapBuffers(). But wine opengl libGL.so directly so there's no way to do it.
Do you need it to fix the "mouse pointer lagging" problem with fglrx? This patch might be what you need. It works for me with Half-Life and Jedi Academy.
I have hacked this change into my x11drv long ago, but I have never submitted a patch? Might a patch like this go into CVS?
Stefan
Do you need it to fix the "mouse pointer lagging" problem with fglrx? This patch might be what you need. It works for me with Half-Life and Jedi Academy.
I kinda see how this could help, but it would need to be better understood first before being applied (it would need, of course, to not link directly to GL and use function pointers :-) ).
Heck, it should make performance almost worse as we add a round-trip to the X server to do this and need to flush the GL rendering pipeline at each buffer swap instead of continuing sending commands to display the new frame while the swap occurs...
Lionel
Hello,
I kinda see how this could help, but it would need to be better understood first before being applied (it would need, of course, to not link directly to GL and use function pointers :-) ).
Heck, it should make performance almost worse as we add a round-trip to the X server to do this and need to flush the GL rendering pipeline at each buffer swap instead of continuing sending commands to display the new frame while the swap occurs...
I am not a GL expert, but AFAIK the OpenGL spec requires the app to flush the rendering pipeline before swapping the buffers. Many games don't do so(ut, Q3 & friends, Half-Life, ...) Most drivers are prepared for this, so it doesn't make any problems. It's only the fglrx driver that can't cope with it, and it makes the mouse pointer lagging for up to one secound, which makes FPS games unplayable.
The best solution would be to fix the games, maybe ATI could fix their driver, but so far there are only hacks like my patch or a preloaded library with a custom glXSwapBuffers.
Stefan
I am not a GL expert, but AFAIK the OpenGL spec requires the app to flush the rendering pipeline before swapping the buffers.
I would find this extremely strange. For example, the 'glXSwapBuffers' man page says this:
(...) The update typically takes place during the vertical retrace of the monitor, rather than immediately after glXSwapBuffers is called.
glXSwapBuffers performs an implicit glFlush before it returns. Subsequent OpenGL commands may be issued immedi- ately after calling glXSwapBuffers, but are not executed until the buffer exchange is completed. The only mention I have of 'glFinish' being useful is when multiple GLX contexts share the same double buffered window (a bit later in this man page).
So I would definitely think that this is a bug in the fglrx drivers and Wine is not the place to fix it...
Lionel
PS: but thanks to have made me re-read the man page, it gives ideas on how to try to solve the multi-threaded D3D games problem :-)
-
Lionel Ulmer -
Stefan Dösinger -
Tomas Carnecky