ATI Opengl regression (DRI?)
Raphael
fenix at club-internet.fr
Thu Dec 22 02:48:15 CST 2005
On Friday 16 December 2005 02:26, Aric Cyr wrote:
> Raphael <fenix <at> club-internet.fr> writes:
> > On Thursday 15 December 2005 19:55, Jesse Allen wrote:
> > > Hi,
> > >
> > > It seems that the patch
> > > git-1399edb0925966a802a6a39835025c22c22c18e1.patch found here
> > > http://www.winehq.org/pipermail/wine-cvs/2005-December/019731.html
> > > causes an opengl regression on my system. With the patch loading War3
> > > causes X Error of failed request: GLXUnsupportedPrivateRequest
> > > Major opcode of failed request: 143 (GLX)
> > > Minor opcode of failed request: 17 (X_GLXVendorPrivateWithReply)
> > > Serial number of failed request: 429
> > > Current serial number in output stream: 429
> > >
> > > Which seems to stop the game loading thread and causes the game to use
> > > the fail-safe thread "Please insert disc", so the game wont load.
> > > Reversing the patch fixes the problem.
> > >
> > > I have a Radeon 9200 using DRI snapshots about 20051024.
> > >
> > > X Window System Version 6.8.99.901 (6.9.0 RC 1) (Minimal DRI build from
> > > X.org tr ee)
> > > Release Date: 18 October 2005 + cvs
> > > X Protocol Version 11, Revision 0, Release 6.8.99.901
> > > Build Operating System: Linux 2.6.14-rc5 i686 [ELF]
> > > Current Operating System: Linux tesore 2.6.15-rc4-git1 #1 PREEMPT Fri
> > > Dec 2 17:0 3:32 MST 2005 i686
> > > Build Date: 28 October 2005
> > >
> > > Is this a DRI problem?
> >
> > No, only that DRI don't implement GLX 1.3
> > i just sent a patch to fix (ie. by-pass) this regression.
>
> You really don't need to use glXQueryServerString() and
> glXQueryClientString(). It would be better, easier (not strcmp) and more
> correct to just use glXQueryVersion(). glXQueryVersion will automatically
> report the version common to both the client and server (so in this case
> 1.2).
No, we cannot
- glXGetFBConfigs is implemented by glx client (normally when glx client
version > 1.2 but in many 1.2 implementations its provided by Xorg).
- glXQueryDrawable is only implemented by glx server (when glx server version
> 1.2)
- for others calls we check if client version > 1.2 else we use SGIX extension
> Another thing I don't understand in your patch is why you have wine_glx_t
> and wine_glx defined at global scope. It looks like the only place in your
> patch they are used is in wgl.c, so why not define wine_glx_t in wgl.c and
> make wine_glx static? Sorry if I am missing something.
It's for future use by wgl_ext.c.
I don't like the idea to duplicate glx version/extensions checks and
glXGetProcAddressARB pointer parameter on functions
> (Also there is some DEPTH_BITS hack in internal_glGetIntegerv which I
> assume is unrelated to this GLX patch?)
yes i comment it (i use it for debug)
> > i thought that DRI implemented GLX 1.3 specs but seems they use a too
> > older x code :(
> > http://cvs.sourceforge.net/viewcvs.py/dri/xc/xc/programs/Xserver/GL/glx/
>
> Too old perhaps, but that what DRI (and hence ATI) are using. Both support
> most of the 1.3 features so there really isn't much of an issue. The
> problem is that we cannot assume 1.3 regardless of how old 1.2 is. The
> reason for the glx version is so that we can do the right thing in any
> case.
Not really, many of GLX features are supported by glx clients.
And only old clients (ie X versions) reports 1.2 caps (and generaly they
support 1.3 extensions)
I have only problems with "1.2 glx servers" (who don't support drawable
queries), who is the DRI / ATI configuration :(
> Also seems like we should be relying on glXGetProcAddress() but need to be
> using glXGetProcAddressARB() since nVidia apparently doesn't export the
> former.
??? where you see glXGetProcAddress use ?
wgl.c:1044: p_glXGetProcAddressARB = wine_dlsym(opengl_handle,
"glXGetProcAddressARB", NULL, 0);
> Regards,
> Aric
Regards,
Raphael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20051222/f5b1dba8/attachment.pgp
More information about the wine-devel
mailing list