From: Roland S. <rsc...@hi...> - 2005-07-30 09:48:37
|
Applications which use display lists are broken for me on r200. Below is the debug output for glxgears, which obviously doesn't really want to call glGenerateMipmap... (it displays completely black, on the upside though framerate is high :-)). Not sure what caused it, happens with both linux-dri and linux-dri-x86 targets (but software mesa, "linux" target works). MESA_DEBUG=verbose LIBGL_DEBUG=verbose glxgears libGL: XF86DRIGetClientDriverName: 5.0.1 r200 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r200_dri.so drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 Mesa warning: software DXTn compression/decompression available Mesa: User error: GL_INVALID_ENUM in glGenerateMipmapEXT(target) Mesa: User error: GL_INVALID_OPERATION in glEndList Mesa: User error: GL_INVALID_ENUM in glGenerateMipmapEXT(target) Mesa: User error: GL_INVALID_OPERATION in glEndList Mesa: User error: GL_INVALID_ENUM in glGenerateMipmapEXT(target) Mesa: User error: GL_INVALID_OPERATION in glEndList 24863 frames in 5.0 seconds = 4972.600 FPS To get the driver to compile in the first place, I also had to copy Xthreads.h from /usr/X11R6/include/X11 to the src/glx/x11 directory, I couldn't see an obvious change why it no longer gets picked up (latest xorg cvs headers installed). Otherwise I got the error below. I hope that doesn't explain the display list issue, thread problems can be fishy... gcc -c -I. -I../../../include -I../../../include/GL/internal -I../../../src/mesa -I../../../src/mesa/main -I../../../src/mesa/glapi -I../../../src/mesa/math -I../../../src/mesa/transform -I../../../src/mesa/swrast -I../../../src/mesa/swrast_setup -I../../../src/mesa/drivers/dri/common -I../../../../dri/drm/libdrm -I../../../../dri/drm/shared-core -I/usr/X11R6/include -I/usr/X11R6/include/X11/extensions -Wall -O -g -m32 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DXF86VIDMODE -D_REENTRANT -UIN_DRI_DRIVER -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -std=c99 -ffast-math -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DXF86VIDMODE -D_REENTRANT -UIN_DRI_DRIVER clientattrib.c -o clientattrib.o In file included from clientattrib.c:38: glxclient.h:64:23: Xthreads.h: Datei oder Verzeichnis nicht gefunden In file included from clientattrib.c:38: glxclient.h:581: error: parse error before "__glXmutex" glxclient.h:581: warning: type defaults to `int' in declaration of `__glXmutex' glxclient.h:581: warning: data definition has no type or storage class In file included from clientattrib.c:39: indirect.h:67: warning: `fastcall' attribute directive ignored indirect.h:70: warning: `fastcall' attribute directive ignored make[3]: *** [clientattrib.o] Fehler 1 make[3]: Leaving directory `/usr/tmp/Mesa-orig/src/glx/x11' make[2]: *** [subdirs] Fehler 1 make[2]: Leaving directory `/usr/tmp/Mesa-orig/src' make[1]: *** [default] Fehler 1 make[1]: Leaving directory `/usr/tmp/Mesa-orig' make: *** [linux-dri-x86] Fehler 2 And, even with that change, the s3v and savage drivers did not compile, both failed the same way (though I didn't care too much as I only needed r200 anyway...). gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I../../../../../../dri/drm/shared-core -I../../../../../include -I../../../../../include/GL/internal -I../../../../../src/mesa -I../../../../../src/mesa/main -I../../../../../src/mesa/glapi -I../../../../../src/mesa/math -I../../../../../src/mesa/transform -I../../../../../src/mesa/shader -I../../../../../src/mesa/swrast -I../../../../../src/mesa/swrast_setup -I../../../../../src/egl/main -I../dri_client -I../dri_client/imports -Wall -O -g -m32 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -std=c99 -ffast-math -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING s3v_state.c -o s3v_state.o In file included from ../../../../../src/mesa/main/mtypes.h:41, from s3v_screen.h:5, from s3v_context.h:13, from s3v_state.c:6: ../../../../../src/mesa/glapi/glthread.h:202: error: conflicting types for `_glthread_TSD' ../../../../../src/mesa/glapi/glthread.h:92: error: previous declaration of `_glthread_TSD' ../../../../../src/mesa/glapi/glthread.h:204: error: redefinition of `_glthread_Thread' ../../../../../src/mesa/glapi/glthread.h:94: error: `_glthread_Thread' previously declared here ../../../../../src/mesa/glapi/glthread.h:206: error: redefinition of `_glthread_Mutex' ../../../../../src/mesa/glapi/glthread.h:96: error: `_glthread_Mutex' previously declared here Roland |
From: Ian R. <id...@us...> - 2005-08-01 16:38:07
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Roland Scheidegger wrote: > Applications which use display lists are broken for me on r200. Below is > the debug output for glxgears, which obviously doesn't really want to > call glGenerateMipmap... (it displays completely black, on the upside > though framerate is high :-)). Not sure what caused it, happens with > both linux-dri and linux-dri-x86 targets (but software mesa, "linux" > target works). I'm going to try and reporduce the r200 display list problem after the various build problems are fixed. > To get the driver to compile in the first place, I also had to copy > Xthreads.h from /usr/X11R6/include/X11 to the src/glx/x11 directory, I > couldn't see an obvious change why it no longer gets picked up (latest > xorg cvs headers installed). Otherwise I got the error below. I hope > that doesn't explain the display list issue, thread problems can be > fishy... It builds fine on my main machine. I tried a build on a fresh system install (with X.org CVS installed) and hit the same problem. I committed a fix for it just a few minutes ago. I think the problem here is related to the next problem... > And, even with that change, the s3v and savage drivers did not compile, > both failed the same way (though I didn't care too much as I only needed > r200 anyway...). > gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver > -I../../../../../../dri/drm/shared-core -I../../../../../include > -I../../../../../include/GL/internal -I../../../../../src/mesa > -I../../../../../src/mesa/main -I../../../../../src/mesa/glapi > -I../../../../../src/mesa/math -I../../../../../src/mesa/transform > -I../../../../../src/mesa/shader -I../../../../../src/mesa/swrast > -I../../../../../src/mesa/swrast_setup -I../../../../../src/egl/main > -I../dri_client -I../dri_client/imports -Wall -O -g -m32 > -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE > -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER > -DGLX_DIRECT_RENDERING -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM > -DUSE_SSE_ASM -std=c99 -ffast-math -D_POSIX_SOURCE > -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE > -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER > -DGLX_DIRECT_RENDERING s3v_state.c -o s3v_state.o > In file included from ../../../../../src/mesa/main/mtypes.h:41, > from s3v_screen.h:5, > from s3v_context.h:13, > from s3v_state.c:6: > ../../../../../src/mesa/glapi/glthread.h:202: error: conflicting types > for `_glthread_TSD' > ../../../../../src/mesa/glapi/glthread.h:92: error: previous declaration > of `_glthread_TSD' The only way this could happen is if *both* PTHREADS and XTHREADS are defined. I suspect the Xthreads.h problem was always there, but it was never hit because XTHREADS was never defined. Some how, somewhere, XTHREADS is getting set. I'll have to look into it, but I think this is a bug in whatever X.org header is defining XTHREADS for us. :( -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFC7k/RX1gOwKyEAw8RAnjBAJ40ipTTTM1i2vZReEzHYl0rQfv1ogCfetZH cnQMN2r2UuJTiwxyRCtexWs= =r9w9 -----END PGP SIGNATURE----- |
From: khaqq <kh...@fr...> - 2005-08-01 16:56:31
|
On Mon, 01 Aug 2005 09:37:37 -0700 Ian Romanick <id...@us...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Roland Scheidegger wrote: > > Applications which use display lists are broken for me on r200. Below is > > the debug output for glxgears, which obviously doesn't really want to > > call glGenerateMipmap... (it displays completely black, on the upside > > though framerate is high :-)). Not sure what caused it, happens with > > both linux-dri and linux-dri-x86 targets (but software mesa, "linux" > > target works). > > I'm going to try and reporduce the r200 display list problem after the > various build problems are fixed. Dunno if that helps, but I can reproduce the "black glxgears" problem quite easily here with 2.6.11.10, drm cvs from saturday, dri cvs from saturday (linux-dri target), and xorg 6.8.99.15. Everything built fine. My R200 is a FireGL 8800. khaqq |
From: Sergio M. B. <se...@se...> - 2005-08-30 02:36:14
Attachments:
smime.p7s
|
Hi,=20 The s3v and savage drivers did not compile with exactly the same error. I hit this problem on X.org CVS with Mesa from there. Since Mesa on X.org is the stable branch 6.3.2, is your fix there ?=20 or anyone knows how fix this problem. I can get build the others DRI drives.=20 But make linux-dri-x86 has a strange bug, enter in loop in the finish of building and I have to stop it with Ctrl+C. thanks,=20 On Mon, 2005-08-01 at 09:37 -0700, Ian Romanick wrote: > It builds fine on my main machine. I tried a build on a fresh system > install (with X.org CVS installed) and hit the same problem. I > committed a fix for it just a few minutes ago. I think the problem here > is related to the next problem... >=20 > > And, even with that change, the s3v and savage drivers did not compile, > > both failed the same way (though I didn't care too much as I only neede= d > > r200 anyway...). > > gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver > > -I../../../../../../dri/drm/shared-core -I../../../../../include > > -I../../../../../include/GL/internal -I../../../../../src/mesa > > -I../../../../../src/mesa/main -I../../../../../src/mesa/glapi > > -I../../../../../src/mesa/math -I../../../../../src/mesa/transform > > -I../../../../../src/mesa/shader -I../../../../../src/mesa/swrast > > -I../../../../../src/mesa/swrast_setup -I../../../../../src/egl/main > > -I../dri_client -I../dri_client/imports -Wall -O -g -m32 > > -D_POSIX_SOURCE -D_POSIX_C_SOURCE=3D199309L -D_SVID_SOURCE -D_BSD_SOURC= E > > -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=3D1 -DIN_DRI_DRIVER > > -DGLX_DIRECT_RENDERING -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM > > -DUSE_SSE_ASM -std=3Dc99 -ffast-math -D_POSIX_SOURCE > > -D_POSIX_C_SOURCE=3D199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE > > -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=3D1 -DIN_DRI_DRIVER > > -DGLX_DIRECT_RENDERING s3v_state.c -o s3v_state.o > > In file included from ../../../../../src/mesa/main/mtypes.h:41, > > from s3v_screen.h:5, > > from s3v_context.h:13, > > from s3v_state.c:6: > > ../../../../../src/mesa/glapi/glthread.h:202: error: conflicting types > > for `_glthread_TSD' > > ../../../../../src/mesa/glapi/glthread.h:92: error: previous declaratio= n > > of `_glthread_TSD' >=20 > The only way this could happen is if *both* PTHREADS and XTHREADS are > defined. I suspect the Xthreads.h problem was always there, but it was > never hit because XTHREADS was never defined. Some how, somewhere, > XTHREADS is getting set. I'll have to look into it, but I think this is > a bug in whatever X.org header is defining XTHREADS for us. :( --=20 S=E9rgio M.B. |
From: Ian R. <id...@us...> - 2005-08-01 17:51:41
Attachments:
Mesa-200508011040.patch
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In addition to my recent commit to Mesa CVS, try this patch. I have verified that everything builds and that glxgears works on a system with current X.org CVS installed. The problem with display lists was really, really stupid. The changes to dispatch.h existed when I tested everything. However, I had added them by hand. Shortly before committing, I regenerated the file. Since the script did not contain the changes, they were lost when the file was regenerated. D'oh! I'm really, really confused as to why this bug doesn't hit X.org CVS builds. The only way that it would not hit is if IN_DRI_DRIVER isn't set. If that's the case, it's also a bug. I'm not sure if we should just apply this patch (should just need the changes to dispatch.h) to X.org CVS or re-import Mesa with the patch applied. Fortunately for me, it's not my call to make. :) As for the s/XTHREADS/USE_XTHREADS/ change, I'm not terribly happy about it. The problem is that XlibConf.h contains '#define XTHREADS' to make it easier to build X extensions in the modular build. This used to be set on the command line by imake. My *personal* opinion is that it should be set on the command line by configure. 7ddbfb1ad2cbd6b3c3e61e7128f906b6 Mesa-200508011040.patch -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD4DBQFC7mEQX1gOwKyEAw8RAlMdAKCZe3qcw61nVEw9mLfS4TCMxjGeRACY1aen 2yT61/LyAUhN7ivtLfhdjQ== =x6eQ -----END PGP SIGNATURE----- |
From: Roland S. <rsc...@hi...> - 2005-08-02 00:41:11
|
Ian Romanick wrote: > I'm really, really confused as to why this bug doesn't hit X.org CVS > builds. The only way that it would not hit is if IN_DRI_DRIVER isn't > set. If that's the case, it's also a bug. I'm not sure if we should > just apply this patch (should just need the changes to dispatch.h) to > X.org CVS or re-import Mesa with the patch applied. Fortunately for me, > it's not my call to make. :) > Index: src/mesa/glapi/dispatch.h > =================================================================== > RCS file: /cvs/mesa/Mesa/src/mesa/glapi/dispatch.h,v > retrieving revision 1.2 > diff -u -d -r1.2 dispatch.h > --- src/mesa/glapi/dispatch.h 28 Jul 2005 00:29:53 -0000 1.2 > +++ src/mesa/glapi/dispatch.h 1 Aug 2005 17:39:36 -0000 > @@ -40,11 +40,20 @@ > */ > > #define CALL_by_offset(disp, cast, offset, parameters) \ > - (*(cast (((_glapi_proc *)(disp))[offset]))) parameters > + (*(cast (GET_by_offset(disp, offset))) parameters > #define GET_by_offset(disp, offset) \ > - (((_glapi_proc *)(disp))[offset]) > + (offset != 0) ? (((_glapi_proc *)(disp))[offset]) : NULL > #define SET_by_offset(disp, offset, fn) \ > - ((((_glapi_proc *)(disp))[offset]) = (_glapi_proc) fn) > + do { \ > + if ( (offset) == 0 ) { \ > + fprintf( stderr, "[%s:%u] SET_by_offset(%p, %d, %s)!\n", \ > + __func__, __LINE__, disp, offset, # fn); \ > + abort(); \ > + } \ > + else { \ > + ( (_glapi_proc *) (disp) )[offset] = (_glapi_proc) fn; \ > + } \ > + } while(0) > > #define CALL_NewList(disp, parameters) (*((disp)->NewList)) parameters > #define GET_NewList(disp) ((disp)->NewList) > Index: src/mesa/glapi/gl_table.py > =================================================================== > RCS file: /cvs/mesa/Mesa/src/mesa/glapi/gl_table.py,v > retrieving revision 1.8 > diff -u -d -r1.8 gl_table.py > --- src/mesa/glapi/gl_table.py 28 Jul 2005 00:29:53 -0000 1.8 > +++ src/mesa/glapi/gl_table.py 1 Aug 2005 17:39:36 -0000 > @@ -91,11 +91,20 @@ > > def printBody(self, api): > print '#define CALL_by_offset(disp, cast, offset, parameters) \\' > - print ' (*(cast (((_glapi_proc *)(disp))[offset]))) parameters' > + print ' (*(cast (GET_by_offset(disp, offset))) parameters' > print '#define GET_by_offset(disp, offset) \\' > - print ' (((_glapi_proc *)(disp))[offset])' > + print ' (offset != 0) ? (((_glapi_proc *)(disp))[offset]) : NULL' > print '#define SET_by_offset(disp, offset, fn) \\' > - print ' ((((_glapi_proc *)(disp))[offset]) = (_glapi_proc) fn)' > + print ' do { \\' > + print ' if ( (offset) == 0 ) { \\' > + print ' fprintf( stderr, "[%s:%u] SET_by_offset(%p, %d, %s)!\\n", \\' > + print ' __func__, __LINE__, disp, offset, # fn); \\' > + print ' abort(); \\' > + print ' } \\' > + print ' else { \\' > + print ' ( (_glapi_proc *) (disp) )[offset] = (_glapi_proc) fn; \\' > + print ' } \\' > + print ' } while(0)' > print '' > > abi = [ "1.0", "1.1", "1.2", "GL_ARB_multitexture" ] Doesn't compile, the parantheses in the CALL_by_offset definition don't seem to add up (in both the python script and dispatch.h). I tried a quick fix without really looking at the code (adding that paranthesis...) but it still didn't compile (at a different place, this time in vtxfmt_tmp.h, I didn't look through all the macro definitions where the error apparently happened). Roland |
From: Jon S. <jon...@gm...> - 2005-08-02 20:17:26
|
I think I'm hitting the display list problem in EGL too. I can't get eglgears to draw but other apps do. On 8/1/05, Ian Romanick <id...@us...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > In addition to my recent commit to Mesa CVS, try this patch. I have > verified that everything builds and that glxgears works on a system with > current X.org CVS installed. >=20 > The problem with display lists was really, really stupid. The changes > to dispatch.h existed when I tested everything. However, I had added > them by hand. Shortly before committing, I regenerated the file. Since > the script did not contain the changes, they were lost when the file was > regenerated. D'oh! >=20 > I'm really, really confused as to why this bug doesn't hit X.org CVS > builds. The only way that it would not hit is if IN_DRI_DRIVER isn't > set. If that's the case, it's also a bug. I'm not sure if we should > just apply this patch (should just need the changes to dispatch.h) to > X.org CVS or re-import Mesa with the patch applied. Fortunately for me, > it's not my call to make. :) >=20 > As for the s/XTHREADS/USE_XTHREADS/ change, I'm not terribly happy about > it. The problem is that XlibConf.h contains '#define XTHREADS' to make > it easier to build X extensions in the modular build. This used to be > set on the command line by imake. My *personal* opinion is that it > should be set on the command line by configure. >=20 > 7ddbfb1ad2cbd6b3c3e61e7128f906b6 Mesa-200508011040.patch > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org >=20 > iD4DBQFC7mEQX1gOwKyEAw8RAlMdAKCZe3qcw61nVEw9mLfS4TCMxjGeRACY1aen > 2yT61/LyAUhN7ivtLfhdjQ=3D=3D > =3Dx6eQ > -----END PGP SIGNATURE----- >=20 >=20 > _______________________________________________ > xorg mailing list > xo...@li... > http://lists.freedesktop.org/mailman/listinfo/xorg >=20 >=20 >=20 >=20 --=20 Jon Smirl jon...@gm... |
From: Ian R. <id...@us...> - 2005-08-03 23:25:08
Attachments:
Mesa-200508031610.patch.gz
mesa_test.sh
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian Romanick wrote: > In addition to my recent commit to Mesa CVS, try this patch. I have > verified that everything builds and that glxgears works on a system with > current X.org CVS installed. This patch *should* fix everything. :) I built it on a system *without* X.org 7.0rc0 on it, so there may still be build problems on those systems. Dunno. I have also attached the script that I used to test on r200. Run the script as "./mesa_test.sh ~/devel/Mesa-build/lib ~/devel/Mesa-build". The first parameter tells it where to find the DRI drivers (it uses it to set DRI_DRIVERS_PATH) and the second parameter tells it where to find Mesa's progs/demos & progs/tests. It assumes that everything is already made in those locations. The only problem I hit was the following assertion in the ARB_vertex_program tests. I don't think that one is my fault, but it could be. r200_swtcl.c:103: r200SetVertexFormat: Assertion `VB->AttribPtr[VERT_ATTRIB_POS] != ((void *)0)' failed. I will try to test on r100, mga, and r128 tonight. I may be able to hit savage as well. If somebody can try i915, unichrome, and tdfx, that would rock. > I'm really, really confused as to why this bug doesn't hit X.org CVS > builds. The only way that it would not hit is if IN_DRI_DRIVER isn't > set. If that's the case, it's also a bug. I'm not sure if we should > just apply this patch (should just need the changes to dispatch.h) to > X.org CVS or re-import Mesa with the patch applied. Fortunately for me, > it's not my call to make. :) I'm going to try and figure out what's going on with the X.org build tomorrow (Thursday). My guess is that IN_DRI_DRIVER isn't included in the defines. > As for the s/XTHREADS/USE_XTHREADS/ change, I'm not terribly happy about > it. The problem is that XlibConf.h contains '#define XTHREADS' to make > it easier to build X extensions in the modular build. This used to be > set on the command line by imake. My *personal* opinion is that it > should be set on the command line by configure. I went ahead and committed this part. 381936c4ef432d131188fe65617ec72b Mesa-200508031610.patch.gz 6242a7bddebf1e823f09802a71db0561 mesa_test.sh -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFC8VIoX1gOwKyEAw8RAjvoAJ9ZR5Ok0YV6WOjB9pWNiBUHFcQC+gCfeGMh h50ylD5bloXmpnNF5h2kMAE= =bYu+ -----END PGP SIGNATURE----- |
From: Vladimir D. <vo...@mi...> - 2005-08-04 04:17:17
|
Hi Ian, Your patch does fix build problems and the bug I have previously seen, however there is a new issue where glxgears segfaults in different place: #0 0x00000000 in ?? () #1 0xb7ba4947 in execute_list (ctx=0x806b290, list=145) at main/dlist.c:6420 #2 0xb7ba5102 in _mesa_CallList (list=1) at main/dlist.c:6749 #3 0xb7bedd67 in neutral_CallList (i=1) at vtxfmt_tmp.h:304 #4 0x0804b387 in draw () #5 0x0804bc1f in event_loop () #6 0x0804c09e in main () thank you ! Vladimir Dergachev On Wed, 3 Aug 2005, Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ian Romanick wrote: >> In addition to my recent commit to Mesa CVS, try this patch. I have >> verified that everything builds and that glxgears works on a system with >> current X.org CVS installed. > > This patch *should* fix everything. :) I built it on a system *without* > X.org 7.0rc0 on it, so there may still be build problems on those > systems. Dunno. > > I have also attached the script that I used to test on r200. Run the > script as "./mesa_test.sh ~/devel/Mesa-build/lib ~/devel/Mesa-build". > The first parameter tells it where to find the DRI drivers (it uses it > to set DRI_DRIVERS_PATH) and the second parameter tells it where to find > Mesa's progs/demos & progs/tests. It assumes that everything is already > made in those locations. > > The only problem I hit was the following assertion in the > ARB_vertex_program tests. I don't think that one is my fault, but it > could be. > > r200_swtcl.c:103: r200SetVertexFormat: Assertion > `VB->AttribPtr[VERT_ATTRIB_POS] != ((void *)0)' failed. > > I will try to test on r100, mga, and r128 tonight. I may be able to hit > savage as well. If somebody can try i915, unichrome, and tdfx, that > would rock. > >> I'm really, really confused as to why this bug doesn't hit X.org CVS >> builds. The only way that it would not hit is if IN_DRI_DRIVER isn't >> set. If that's the case, it's also a bug. I'm not sure if we should >> just apply this patch (should just need the changes to dispatch.h) to >> X.org CVS or re-import Mesa with the patch applied. Fortunately for me, >> it's not my call to make. :) > > I'm going to try and figure out what's going on with the X.org build > tomorrow (Thursday). My guess is that IN_DRI_DRIVER isn't included in > the defines. > >> As for the s/XTHREADS/USE_XTHREADS/ change, I'm not terribly happy about >> it. The problem is that XlibConf.h contains '#define XTHREADS' to make >> it easier to build X extensions in the modular build. This used to be >> set on the command line by imake. My *personal* opinion is that it >> should be set on the command line by configure. > > I went ahead and committed this part. > > 381936c4ef432d131188fe65617ec72b Mesa-200508031610.patch.gz > 6242a7bddebf1e823f09802a71db0561 mesa_test.sh > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFC8VIoX1gOwKyEAw8RAjvoAJ9ZR5Ok0YV6WOjB9pWNiBUHFcQC+gCfeGMh > h50ylD5bloXmpnNF5h2kMAE= > =bYu+ > -----END PGP SIGNATURE----- > |
From: Roland S. <rsc...@hi...> - 2005-08-04 13:31:03
|
Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ian Romanick wrote: > >>In addition to my recent commit to Mesa CVS, try this patch. I have >>verified that everything builds and that glxgears works on a system with >>current X.org CVS installed. > > > This patch *should* fix everything. :) I built it on a system *without* > X.org 7.0rc0 on it, so there may still be build problems on those > systems. Dunno. Works for me (built with latest xorg cvs). Hurray, glxgears runs again, the world is saved :-) > I have also attached the script that I used to test on r200. Run the > script as "./mesa_test.sh ~/devel/Mesa-build/lib ~/devel/Mesa-build". > The first parameter tells it where to find the DRI drivers (it uses it > to set DRI_DRIVERS_PATH) and the second parameter tells it where to find > Mesa's progs/demos & progs/tests. It assumes that everything is already > made in those locations. > > The only problem I hit was the following assertion in the > ARB_vertex_program tests. I don't think that one is my fault, but it > could be. > > r200_swtcl.c:103: r200SetVertexFormat: Assertion > `VB->AttribPtr[VERT_ATTRIB_POS] != ((void *)0)' failed. > > I will try to test on r100, mga, and r128 tonight. I may be able to hit > savage as well. If somebody can try i915, unichrome, and tdfx, that > would rock. > > >>I'm really, really confused as to why this bug doesn't hit X.org CVS >>builds. The only way that it would not hit is if IN_DRI_DRIVER isn't >>set. If that's the case, it's also a bug. I'm not sure if we should >>just apply this patch (should just need the changes to dispatch.h) to >>X.org CVS or re-import Mesa with the patch applied. Fortunately for me, >>it's not my call to make. :) > > > I'm going to try and figure out what's going on with the X.org build > tomorrow (Thursday). My guess is that IN_DRI_DRIVER isn't included in > the defines. > > >>As for the s/XTHREADS/USE_XTHREADS/ change, I'm not terribly happy about >>it. The problem is that XlibConf.h contains '#define XTHREADS' to make >>it easier to build X extensions in the modular build. This used to be >>set on the command line by imake. My *personal* opinion is that it >>should be set on the command line by configure. > > > I went ahead and committed this part. > > 381936c4ef432d131188fe65617ec72b Mesa-200508031610.patch.gz > 6242a7bddebf1e823f09802a71db0561 mesa_test.sh > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFC8VIoX1gOwKyEAw8RAjvoAJ9ZR5Ok0YV6WOjB9pWNiBUHFcQC+gCfeGMh > h50ylD5bloXmpnNF5h2kMAE= > =bYu+ > -----END PGP SIGNATURE----- |
From: Roland S. <rsc...@hi...> - 2005-08-04 13:39:16
|
(sorry for the previous message, wasn't meant to be sent...) Ian Romanick wrote: > This patch *should* fix everything. :) I built it on a system > *without* X.org 7.0rc0 on it, so there may still be build problems on > those systems. Dunno. Works for me on r200 (built on latest xorg cvs). Everybody's favorite benchmark runs once again :-). >> I'm really, really confused as to why this bug doesn't hit X.org >> CVS builds. The only way that it would not hit is if IN_DRI_DRIVER >> isn't set. If that's the case, it's also a bug. I'm not sure if >> we should just apply this patch (should just need the changes to >> dispatch.h) to X.org CVS or re-import Mesa with the patch applied. >> Fortunately for me, it's not my call to make. :) > > > I'm going to try and figure out what's going on with the X.org build > tomorrow (Thursday). My guess is that IN_DRI_DRIVER isn't included > in the defines. This seems correct. I've just done a make World and nowhere in the log did it mention IN_DRI_DRIVER. It doesn't define USE_EXTERNAL_DXTN_LIB neither, no idea if this is intentional? Roland |
From: Jon S. <jon...@gm...> - 2005-08-05 04:01:55
|
This patch worked to make gears display in EGL On 8/3/05, Ian Romanick <id...@us...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Ian Romanick wrote: > > In addition to my recent commit to Mesa CVS, try this patch. I have > > verified that everything builds and that glxgears works on a system wit= h > > current X.org CVS installed. >=20 > This patch *should* fix everything. :) I built it on a system *without* > X.org 7.0rc0 on it, so there may still be build problems on those > systems. Dunno. >=20 > I have also attached the script that I used to test on r200. Run the > script as "./mesa_test.sh ~/devel/Mesa-build/lib ~/devel/Mesa-build". > The first parameter tells it where to find the DRI drivers (it uses it > to set DRI_DRIVERS_PATH) and the second parameter tells it where to find > Mesa's progs/demos & progs/tests. It assumes that everything is already > made in those locations. >=20 > The only problem I hit was the following assertion in the > ARB_vertex_program tests. I don't think that one is my fault, but it > could be. >=20 > r200_swtcl.c:103: r200SetVertexFormat: Assertion > `VB->AttribPtr[VERT_ATTRIB_POS] !=3D ((void *)0)' failed. >=20 > I will try to test on r100, mga, and r128 tonight. I may be able to hit > savage as well. If somebody can try i915, unichrome, and tdfx, that > would rock. >=20 > > I'm really, really confused as to why this bug doesn't hit X.org CVS > > builds. The only way that it would not hit is if IN_DRI_DRIVER isn't > > set. If that's the case, it's also a bug. I'm not sure if we should > > just apply this patch (should just need the changes to dispatch.h) to > > X.org CVS or re-import Mesa with the patch applied. Fortunately for me= , > > it's not my call to make. :) >=20 > I'm going to try and figure out what's going on with the X.org build > tomorrow (Thursday). My guess is that IN_DRI_DRIVER isn't included in > the defines. >=20 > > As for the s/XTHREADS/USE_XTHREADS/ change, I'm not terribly happy abou= t > > it. The problem is that XlibConf.h contains '#define XTHREADS' to make > > it easier to build X extensions in the modular build. This used to be > > set on the command line by imake. My *personal* opinion is that it > > should be set on the command line by configure. >=20 > I went ahead and committed this part. >=20 > 381936c4ef432d131188fe65617ec72b Mesa-200508031610.patch.gz > 6242a7bddebf1e823f09802a71db0561 mesa_test.sh > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org >=20 > iD8DBQFC8VIoX1gOwKyEAw8RAjvoAJ9ZR5Ok0YV6WOjB9pWNiBUHFcQC+gCfeGMh > h50ylD5bloXmpnNF5h2kMAE=3D > =3DbYu+ > -----END PGP SIGNATURE----- >=20 >=20 >=20 --=20 Jon Smirl jon...@gm... |
From: Daniel S. <da...@fo...> - 2005-08-30 03:06:04
|
On Mon, 2005-08-01 at 09:37 -0700, Ian Romanick wrote: > It builds fine on my main machine. I tried a build on a fresh system > install (with X.org CVS installed) and hit the same problem. I > committed a fix for it just a few minutes ago. I think the problem here > is related to the next problem... > > > And, even with that change, the s3v and savage drivers did not compile, > > both failed the same way (though I didn't care too much as I only needed > > r200 anyway...). > > gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver > > -I../../../../../../dri/drm/shared-core -I../../../../../include > > -I../../../../../include/GL/internal -I../../../../../src/mesa > > -I../../../../../src/mesa/main -I../../../../../src/mesa/glapi > > -I../../../../../src/mesa/math -I../../../../../src/mesa/transform > > -I../../../../../src/mesa/shader -I../../../../../src/mesa/swrast > > -I../../../../../src/mesa/swrast_setup -I../../../../../src/egl/main > > -I../dri_client -I../dri_client/imports -Wall -O -g -m32 > > -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE > > -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER > > -DGLX_DIRECT_RENDERING -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM > > -DUSE_SSE_ASM -std=c99 -ffast-math -D_POSIX_SOURCE > > -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE > > -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER > > -DGLX_DIRECT_RENDERING s3v_state.c -o s3v_state.o > > In file included from ../../../../../src/mesa/main/mtypes.h:41, > > from s3v_screen.h:5, > > from s3v_context.h:13, > > from s3v_state.c:6: > > ../../../../../src/mesa/glapi/glthread.h:202: error: conflicting types > > for `_glthread_TSD' > > ../../../../../src/mesa/glapi/glthread.h:92: error: previous declaration > > of `_glthread_TSD' > > The only way this could happen is if *both* PTHREADS and XTHREADS are > defined. I suspect the Xthreads.h problem was always there, but it was > never hit because XTHREADS was never defined. Some how, somewhere, > XTHREADS is getting set. I'll have to look into it, but I think this is > a bug in whatever X.org header is defining XTHREADS for us. :( Yes, you're spot on about PTHREADS and XTHREADS both being defined. XlibConf.h now defines XTHREADS if we're using it, the consensus being that if you're using <X11/Xlibint.h>, you deserve everything you get. I think this already got fixed, so the constructs are more like: #if defined(PTHREADS) ... #elif defined(XTHREADS) ... #elif defined(...) ... #endif |
From: Ian R. <id...@us...> - 2005-08-30 15:33:54
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Stone wrote: > On Mon, 2005-08-01 at 09:37 -0700, Ian Romanick wrote: > >>The only way this could happen is if *both* PTHREADS and XTHREADS are >>defined. I suspect the Xthreads.h problem was always there, but it was >>never hit because XTHREADS was never defined. Some how, somewhere, >>XTHREADS is getting set. I'll have to look into it, but I think this is >>a bug in whatever X.org header is defining XTHREADS for us. :( > > Yes, you're spot on about PTHREADS and XTHREADS both being defined. > XlibConf.h now defines XTHREADS if we're using it, the consensus being > that if you're using <X11/Xlibint.h>, you deserve everything you get. Which I consider to be a bug, but apparently I'm the only one. If I wanted XTHREADS support, I'd ask for it. > I think this already got fixed, so the constructs are more like: > #if defined(PTHREADS) > ... > #elif defined(XTHREADS) > ... > #elif defined(...) > ... > #endif I did a global s/XTHREADS/USE_XTHREADS/ in Mesa. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDFHvUX1gOwKyEAw8RAuVaAJ9iiEwNWlxb36hEkppEZdbzQPnfmACfb11B fOFf7DBnT8Z06+AS6IpWw5E= =uqHq -----END PGP SIGNATURE----- |
From: Adam J. <aj...@nw...> - 2005-08-30 18:04:03
|
On Tuesday 30 August 2005 11:31, Ian Romanick wrote: > Daniel Stone wrote: > > On Mon, 2005-08-01 at 09:37 -0700, Ian Romanick wrote: > >>The only way this could happen is if *both* PTHREADS and XTHREADS are > >>defined. I suspect the Xthreads.h problem was always there, but it was > >>never hit because XTHREADS was never defined. Some how, somewhere, > >>XTHREADS is getting set. I'll have to look into it, but I think this is > >>a bug in whatever X.org header is defining XTHREADS for us. :( > > > > Yes, you're spot on about PTHREADS and XTHREADS both being defined. > > XlibConf.h now defines XTHREADS if we're using it, the consensus being > > that if you're using <X11/Xlibint.h>, you deserve everything you get. > > Which I consider to be a bug, but apparently I'm the only one. If I > wanted XTHREADS support, I'd ask for it. You _have_ to have it defined correctly. The Xlib ABI changes based on=20 whether it was built with XTHREADS support. We didn't have to define=20 XTHREADS in an installed header file in the monolith because everything was= =20 built in the same pass and imake would define it for us. This is no longer= =20 the case. The s/XTHREADS/USE_&/ conversion is correct, to the extent that it lets you= =20 choose whether your libGL is threadsafe. Whether we should allow people to= =20 do that is perhaps debatable. =2D ajax |
From: Ian R. <id...@us...> - 2005-08-30 19:30:26
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Jackson wrote: > You _have_ to have it defined correctly. The Xlib ABI changes based on > whether it was built with XTHREADS support. We didn't have to define > XTHREADS in an installed header file in the monolith because everything was > built in the same pass and imake would define it for us. This is no longer > the case. > > The s/XTHREADS/USE_&/ conversion is correct, to the extent that it lets you > choose whether your libGL is threadsafe. Whether we should allow people to > do that is perhaps debatable. libGL is still thread-safe. It just uses -DPTHREADS instead. The pthreads paths tend to be slightly more efficient and match the way the drivers get built. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDFLNNX1gOwKyEAw8RAgjtAJ4gdfMiyYN4abI+oHuw1cykY1XGNwCfVCt0 z4NGlqZZi/z9Ugb06SvjjbU= =p5ZW -----END PGP SIGNATURE----- |