As in summary, on an Ultra2/Creator3D (FFB2+(H)) system CFLAGS="-mcpu=v8 -mtune=v9 -O2 -pipe" after ebuild xfree-4.3.0-r2.ebuild fetch unpack compile install qmerge etc-update xinit glxgears I get Segfault in /usr/lib/opengl/xfree/lib/libGL.so.1.2* Reproducible: Always Steps to Reproduce: 1.install xfree-4.3.0-r2 2.etc-update (all 80 of them) 3.glxgears Actual Results: Segfault Expected Results: most anything else; best would be some spinning gears. All openGL applications demonstrate the same failure. 'uname -srvmpio' shows: Linux 2.4.20-sparc-r0 #3 SMP Fri Jan 3 15:56:09 UTC 2003 sparc64 sun4u TI UltraSparc II (BlackBird) GNU/Linux ----------------------------------------- The Module section in XF8sConfig shows: Section "Module" Load "dbe" Load "type1" Load "speedo" Load "drm" Load "dri" Load "glx" Load "extmod" Load "freetype" # Load "pex5" # Load "record" # Load "xie" EndSection and Section "DRI" Group "video" Mode 0666 EndSection ======================================= And, here is the requested 'emerge info' ======================================= lacewing X11 # emerge info Portage 2.0.47-r10 (default-sparc64-1.4, gcc-3.2.2, glibc-2.2.5-r2,2.3.1-r4) ================================================================= System uname: 2.4.20-sparc-r0 sparc64 sun4u GENTOO_MIRRORS="http://gentoo.oregonstate.edu/ http://www.ibiblio.org/pub/Linux/distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="/home1/portage" USE="sparc apm avi cups encode fbcon gif jpeg mikmod mpeg ncurses nls png pdflib spell truetype xv xml2 xmms gdbm berkdb slang readline tetex tcltk java guile X sdl gpm tcpd pam libwww ssl perl python imlib gnome gtk qt kde motif opengl mozilla cdr mysql -oggvorbis crypt -arts -alsa -esd -oss ruby tiff zlib" COMPILER="gcc3" CHOST="sparc-unknown-linux-gnu" CFLAGS="-mcpu=v8 -mtune=v9 -O2 -pipe" CXXFLAGS="-mcpu=v8 -mtune=v9 -O2 -pipe -Wno-deprecated -fpermissive" ACCEPT_KEYWORDS="sparc" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache" ================================== I have marked the Severity as "Major" because if this is a bug anyplace but on my system, it is severe. (If it is something peculiar to my system, I'd like to know that, too of course.)
Created attachment 10999 [details] Current complete XF86Config file. ((Just for completeness))
Created attachment 11000 [details] Current complete XF86Config file. ((Just for completeness))
And, if I just use .../libGL.so.1.2 from xfree-4.2.1-r2, "everything" (well, glxgears & blender at least) work fine. Better, if fact, than with xfree-4.2.1. So, even though the version number did not change, for me, sparc/openGL-4.3.0 is broken, and its size is significantly bigger. I'll see if I can find out anything more later. ----------------------- lacewing lib # size *-r2 text data bss dec hex filename 362111 14841 12280 389232 5f070 libGL.so.1.2-4.2.1-r2 lacewing lib # size *-4.3.0 text data bss dec hex filename 417056 34080 12264 463400 71228 libGL.so.1.2-4.3.0 -----------------------
Third comment. As best as I can tell from -gdb-, the abort comes from glViewport, which is a tiny piece of sparc assembler code in glapi_sparc.S (in /var/tmp/portage/xfree-4.3.0-r2/work/xc/extras/Mesa/src/SPARC which is linked to /var/tmp/portage/xfree-4.3.0-r2/work/xc/lib/GL/glx/glapi_sparc.S); the failure is independent of whether or not the __sparc_v9_ assembler version is used. (I have tried both: default is without, but you can get either version by playing with the Makefile in .../glx.) For reference, the code in its entirity reads: ------------------- .globl glViewport .type glViewport,#function glViewport: #ifdef __sparc_v9__ sethi %hi(0x00000000), %g2 sethi %hi(0x00000000), %g1 or %g2, %lo(0x00000000), %g2 or %g1, %lo(0x00000000), %g1 sllx %g2, 32, %g2 ldx [%g1 + %g2], %g1 sethi %hi(8 * _gloffset_Viewport), %g2 or %g2, %lo(8 * _gloffset_Viewport), %g2 ldx [%g1 + %g2], %g3 #else sethi %hi(0x00000000), %g1 ld [%g1 + %lo(0x00000000)], %g1 ld [%g1 + (4 * _gloffset_Viewport)], %g3 #endif jmpl %g3, %g0 nop ------------------ You get to this code indirectly, it appears, through a vector set up in g_render.c. The assembler code itself is generated by a script from a template, but I haven't found them yet, as they do not seem to be part of the xfree86 source.
More information: Short description-- If you build in /var/tmp/portage/xfree-4.3.0-r2/work/xc/lib/GL/glx with "make ASM_DEFS=-UUSE_SPARC_ASM", after having edited 'glapi_sparc.S' with appropriate "#ifdef USE_SPARC_ASM / #endif" (I put them around ".globl glNewList" and right in fromt of ".globl _mesa_sparc_glapi_end" at the end of the routine), then -glxgears- works fine. So, on my system at least, the assembler code is wrong. Unfortunately, there are several possible culprits; I am in free association mode now, so please be patient about my ramblings. 1. For sake of argument, I believe that the code as presented works for XF86 testing, and possibly on every system but mine. 2. I suspect but do not know that XF/Sparc testing is mostly Solaris based using Solaris compiler (because the Makefile as presented in ".../glx" cannot build a v9-specific version, but the assembler code certainly makes the distinction. To get a v9 version with gcc, you have to make sure to "-D__sparc_v9__" and to set "-mv9" at every opportunity.) 3. The assembler code makes lots of linkage/register assumptions. As best as I can tell from gdb, the failing instruction (non-v9 mode) is ld [%g1],%g1 or, in V9-mode, ldx [%g1 + %g2], %g3 which says that the linkage assumptions are wrong (%g1 is not a good address.) Here is what gdb says happens: %g1 = 0x800000 (entry -- certainly not a good data address) %g1 = 0 (not surprising after the sethi) Segfault (not surprising after ld[%g1],%g1) 3a. How can this possibly work? As I read the Sparc architecture, here's what the sequence does: sethi %hi(0),%g1 %g1(bits 0-10) <- 0 %g1(bits 32-63) <- 0 %g1(bits 10-31) <- %hi(0) == 0 I.e., %g1<-0 ld [%g1],%g1 Load into %g1 indirect through %g1 (==0) Similarly, it looks to me like the -V9 version carefully sets %g1, %g2 to 0 and then tries ldx [%g1+g2],.... 4. Unfortunately, at this point, I haven't determined if this is coming from a bad assumption on X's part, a gcc/X mismatch, a Linux(sparc)/X mismatch, or what. More to come, I am sure.
OK, those "sethi %hi(0),..." instructions are supposed to be filled in at library init to point to the real parameter list. They are not. (Someone is supposed to walk through the entire pointer-to-glXXX blocks and do something like B[0] |= (glapi_addr >> 10); B[1] |= (glapi_addr & 0x3FF); for non-V9, and something similar for V9, as in glapi.c+1870, but I haven't found anything like that.) Incidently, in the static version of the library, symbols like glViewport are not defined at all (although with XF4.2 they were). I would like to use the sparc assembler code, but it is beyond me at this point to see how you are supposed to make it work.
Created attachment 11126 [details] stripped down sparc.c
Here's how you fix it by hand. I do not believe the code as provided & built is complete. We are in the directory <xc/lib/GL/glx> in the xfree-4.3.0-r2 build tree, with xfree-4.3.2-r2 already compiled and installed so that you are using it. 1. Remove the soft links for 'glapi.c', 'glapi_sparc.S', and copy the files in from <../../../../xc/extras/Mesa/src/[SPARC]>. Bring in 'sparc.c' as well for reference (you are going to replace it in step 4). 2. Edit glapi_sparc.S to include near the beginning the lines #ifdef __sparc_v9__ #undef __sparc_v9__ #endif because we never have 64-bit addresses around, whatever the compiler options. 3. Apply this little patch to your private 'glapi.c' ============================= --- glapi.c.orig 2003-04-25 13:00:01.000000000 +0000 +++ glapi.c 2003-04-25 13:00:24.000000000 +0000 @@ -51,6 +51,7 @@ #include "glapitable.h" #include "glthread.h" +extern void _glx_mesa_init_sparc_glapi_relocs(void); /***** BEGIN NO-OP DISPATCH *****/ static GLboolean WarnFlag = GL_FALSE; @@ -305,6 +306,7 @@ _glapi_Dispatch = dispatch; } #endif /*THREADS*/ + _glx_mesa_init_sparc_glapi_relocs(); } ================================ 4. Use the attached sparc.c for _glx_mesa_init_sparc_glapi_relocs() (or just add it to glapi.c -- we're talking about 12 lines of code here). This replaces the one you copied in at the beginning. 5. If you kept the code separate, add sparc.o to the GLX_OBJS in the Makefile. 6. make; cd ..; make; cp GL/libGL.so.1.2 /usr/lib/opengl/xfree/lib With these changes, -glxgears- (and blender) work again. Whether or not the changes are any good in general, I cannot say. Opengl as built out of the box for sparc cannot possibly work, though, so far as I can make out. (Or, if it does, what am I missing here?)
german keyboard layout won't work correctly with r2. i can't type any characters that need "ALTGr" to be invoked, like "@, |, ?, \". these are my localization settings: LANG="en_GB" LANGUAGE="en_GB" LC_CTYPE="de_DE@euro" LC_NUMERIC="de_DE@euro" LC_TIME="C" LC_COLLATE="de_DE@euro" LC_MONETARY="de_DE@euro" LC_MESSAGES="en_GB"
sorry, ignore my last post. my browser mixed something up. this goes into "keyboard broken".
Are you still having this issue or did you resolve it?
If you are asking about the keyboard question, ignore the rest of this comment; I don't know anything about it. If you are asking about the Segfault in /usr/lib/opengl/xfree/lib/libGL.so.1.2: The changes outlined in comment 8 fix the problem for me. Two other people have reported the same problem (with xfree-4.3.0-r2, glxinfo & friends all segfault) so I believe the problem is a genuine problem with xfree-4.3.0 as distributed. (One reported the problem as a discussion in the sparc forum; one asked me directly.) In one case, at least, the approach outlined above did correct the problem. As I read the code in the <.../lib/GL/glx> portion of libGL, the SPARC version as distributed and configured by its .ebuild file cannot possibly work. So, for me myself the problem is temporarily resolved (I know how to get around it), but so far as I can see, the sparc/openGL portion of xf-4.3.0-r2 is broken. <.../GL/glx> directory apparently doesn't get set up quite right to handle the SPARC assembler code, but I have now idea how the problem was indroduced (in xfree-4.2.xx, the problem is absent because glx doesn't try to use any sparc-specific assembler.) Hope this helps, Regards
I just would like to conform the bug on my system. Xfree 4.3.0-r2, Elite3D (with the afb.ucode patch), glxgears *always* segfaults.
Anybody tried -r3 yet ? If not, I should be able to make that fix into a sane patch, but I do not know when I will get to it though :(
I am running the fetch/unpack/compile part of -r3 as an ebuild; I will be able to tell from the result in the lib/GL/glx directory whether or not the bug is fixed. I haven't tried to turn the bandaid fix into a good patch because: 1. I don't know how, since the symbolic links is GL/glx are set up as part of the actual compile process in "make World" 2. I don't know for sure if it puts the patch-all-the-addresses call in at the right place(s) in glapi.c Regards,
Martin, I'm running -r3 but I have the "ATI Mach64 GT (264GT), aka 3D RAGE" and this bug may not apply... see output below so when I run glxgears it goes like this: Xlib: extension "XFree86-DRI" missing on display ":0.0". Segmentation fault
The source from '-r2' -> '-r3' did not change for xc/lib/GL/glx, so any fix would have been by some other means. And, hand-executing 'glxinfo' suggests the segfault bug is still present, thus: antaresia lib # ./GL #!/bin/bash -v export LD_PRELOAD="/var/tmp/portage/xfree-4.3.0-r3/image/usr/lib/libGLU.so.1 /var/tmp/portage/xfree-4.3.0-r3/image/usr/lib/opengl/xfree/lib/libGL.so.1" export LD_LOAD_PATH="/var/tmp/portage/xfree-4.3.0-r3/image/usr/lib:/var/tmp/portage/xfree-4.3.0-r3/image/usr/lib/opengl/xfree/lib" glxinfo name of display: lacewing.inforead.com:0.0 Xlib: extension "XFree86-DRI" missing on display ":0.0". ./GL: line 4: 21044 Segmentation fault glxinfo # It occurs to me that the easiest fix might be to disable ASM_DEFS = -DUSE_SPARC_ASM *For lib/GL/glx only!* until a good way to fix up the assembly version of the address patching can be worked out. In effect, this reverts libGL to how it was in 4.2.xx. Note, though, I have not tried this, and I have no idea if it would work or if the result would be compatible with everything else. Note for Chris Russell: The bug is xfree-4.3.x--on--sparc64 specific. It does not matter what your graphics card is, because libGL.so as built for sparc64 in xfree-4.3.x is 100% broken. Regards, Ferris
Chris, DRI for mach64 chipsets isn't in the portage tree yet. It'll hopefully show up with xfree-drm-4.3.0-r7, or when I can make it work. Until then, either check out http://www.retinalburn.net/linux/dri_HOWTO.html or comment out the dri module in /etc/X11/XF86Config like this: # Load "dri" Please follow bug #27099 instead of adding to this bug.
Stupid question - what is the compile flags for xc/lib/GL/glx ? It should in theory have a '-m32' there if you have 32bit userland on sparc64 - is this the case? Or am I trying to find a problem where there is none ?
We are using 32-bit userland on sparc64.
So far as I know, there is no '-m32' flag, because it is always 32 bit for users. There is a problem, but it is not related to that, except for forcing the assembler code always to run in 32-bit mode (that's the #ifdef __sparc_v9__ #undef __sparc_v9__ bit added to glapi_sparc.S). It looks like the assembler stuff originally was done on Solaris with the sun compiler, where 32 vs. 64 makes a difference. Also, under Solaris, the addresses in the assembler code must somehow get filled in by Sun's driver some other way. The problem here is that all those zeros in the address fields on glapi_sparc.S need to be filled in at run time, and as distributed for Linux on Sparc, glx has no provision for doing so. The code is fine and compiles fine; it's just incomplete under Linux. Hope this helps.
If I understand gcc correctly, it *should* only define __sparc_v9__ or __arc64__ if you have 'mcpu=v9'. What happens if you change the '-mtune=v9' to '-mtune=v8' ? Might be deeper than just xfree ... Alternatively could you try attached patch: ------------------------------------- --- xc/config/cf/Imake.cf.orig 2003-09-07 15:58:53.957841248 +0200 +++ xc/config/cf/Imake.cf 2003-09-07 16:23:13.302987064 +0200 @@ -1006,8 +1006,17 @@ #endif /* QNX/Neutrino */ #ifdef SparcArchitecture -# if defined(__sparc_v9) || defined(__arch64__) -# define Sparc64Architecture +# if defined(__sparc_v9__) +# undef __sparc_v9__ +# endif +# if defined(__sparc_v9) +# undef __sparc_v9 +# endif +# if defined(__arch64__) +# undef __arch64__ +# endif +# if defined(Sparc64Architecture) +# undef Sparc64Architecture # endif #endif
1. The bug is sparc/any dependent, not just sparc64. E.g., you see it on SS20, SS5, etc (sun4m) as well as on sun4u. See #7 below. 2. The only reason __sparc_v9_ is a problem with libGL is that xfree assumes (it seems) a SUN/SOLARIS compiler, where __sparc_v9_ implies 64-bit code, and the assembly code in GLX assumes that. 3. With Linux and the gcc compiler, __sparc_v9_ does not mean 64-bit code; there is no 64-bit user code on sparc/linux right now. 4. The only point of the extra check in the assembler code is to make sure the 64-bit linkages don't get set up (althought they might work, I suppose). 5. If you are concerned primarily with sparc32 vs. sparc64 useland issues, the better fix looks something like #if defined(__sparc_v9__) && (!defined(__linux__) || defined(__linux_sparc_64__)) ... <<where I made that last one up, because when linux has 64-bit sparc, then the Solaris & gcc compilers are in sync>> 6. So, there are two problems here. First is the problem you are addressing, which is that there might be 64-bit code lurking in xfree, and indeed in any application which assumes a Sun compiler if you are on any sort of sparc. Second is the segfault problem, which is sun-cpu independent (it is sparc specific, but it is an equal opportunity failure, once you are sparc linux of any flavor.) 7. By the way, in the original report, with CFLAGS="-mcpu=v8 -mtune=v9", this was saying: "compile for sun4m = Sparc32, but where it matters, do instruction scheduling to favor sun4u". You can easily prove this to yourself with 'gcc -v -mcpu=v8 -mtune=v9' and notice that what gets defined is __sparc_v8__ which is strictly 32-bit. So when originally reported, this bug did not have any 64-bit-ness issues. The reason fur turning off __sparc_v9__ in the assembler code was to prevent any from creeping in. The "-mcpu=v8 -mtune=v9" idiom was for a version of gcc which sometimes "got it wrong" with cpu=v9, but the ebuilds seem to catch those cases, now. 8. So now, I just '-mcpu=v9'. But I didn't when I first reported this bug. And all the _v9__ stuff was "belt & suspenders" type paranoia. (I wish I'd left it out... it's something of a red herring... but to be completely safe, you do have to #undefine it in glapi.S...) Does this help? As I look it over, what I wrote confuses me.
>1. The bug is sparc/any dependent, not just sparc64. E.g., you see it on SS20, > SS5, etc (sun4m) as well as on sun4u. See #7 below. > > 2. The only reason __sparc_v9_ is a problem with libGL is that xfree assumes > (it seems) a SUN/SOLARIS compiler, where __sparc_v9_ implies 64-bit code, > and the assembly code in GLX assumes that. > > 3. With Linux and the gcc compiler, __sparc_v9_ does not mean 64-bit code; > there is no 64-bit user code on sparc/linux right now. > Yes, this I do understand. XFree86 do not set __sparc_v9__ though, so it is kernel/glibc/gcc side (difficult to check on non sparc system). What I tried thus to say, is that if __sparc_v9__ also mean 64bit, then linux/gcc/glibc sets it wrong, and it is a bug that should be fixed. If __sparc_v9__ do *NOT* indicate 64bit, then we have to fix xfree (for linux at least) >4. The only point of the extra check in the assembler code is to make sure the > 64-bit linkages don't get set up (althought they might work, I suppose). > Yep, that I do understand. The issue is still if __sparc_v9__ donate 64bit, or if you should check __arch64__ to see if we need to generate 64bit code (yes, for linux obviously not). >5. If you are concerned primarily with sparc32 vs. sparc64 useland issues, > the better fix looks something like > #if defined(__sparc_v9__) && (!defined(__linux__) || defined(__linux_sparc_64__)) > ... <<where I made that last one up, because when linux has 64-bit sparc, > then the Solaris & gcc compilers are in sync>> > Right, but once again, does __sparc_v9__ indicate 64bit? We might change that patch like so: -------------------------------------------- --- xc/config/cf/Imake.cf.orig 2003-09-07 15:58:53.000000000 +0200 +++ xc/config/cf/Imake.cf 2003-09-07 21:56:14.876326192 +0200 @@ -1006,8 +1006,14 @@ #endif /* QNX/Neutrino */ #ifdef SparcArchitecture -# if defined(__sparc_v9) || defined(__arch64__) -# define Sparc64Architecture +# if defined(__sparc_v9) || defined(__sparc_v9__) || defined(__arch64__) +# if defined(linux) +# if defined(__arch64__) +# undef __arch64__ +# endif +# else +# define Sparc64Architecture +# endif # endif #endif ------------------------------------------- And then apply to glapi_sparc.S: ------------------------------------------- --- ../../../extras/Mesa/src/SPARC/glapi_sparc.S.orig 2003-09-07 21:58:38.171542008 +0200 +++ ../../../extras/Mesa/src/SPARC/glapi_sparc.S 2003-09-07 21:59:32.586269712 +0200 @@ -27,7 +27,7 @@ .globl glNewList .type glNewList,#function glNewList: -#ifdef __sparc_v9__ +#ifdef Sparc64Architecture sethi %hi(0x00000000), %g2 sethi %hi(0x00000000), %g1 or %g2, %lo(0x00000000), %g2 @@ -48,7 +48,7 @@ .... etc for the rest ------------------------------------------- And for any other piece that assume __sparc_v9__ imply __arch64__ (if __sparc_v9__ does indeed not imply __arch64__). >6. So, there are two problems here. First is the problem you are addressing, > which is that there might be 64-bit code lurking in xfree, and indeed in > any application which assumes a Sun compiler if you are on any sort of > sparc. > > Second is the segfault problem, which is sun-cpu independent (it is sparc > specific, but it is an equal opportunity failure, once you are sparc linux > of any flavor.) > Right, and fixing the wrong assumption that __sparc_v9__ imply __arch64__ for linux, this should be fixed as well ? >7. By the way, in the original report, with > CFLAGS="-mcpu=v8 -mtune=v9", this was saying: > "compile for sun4m = Sparc32, but where it matters, do instruction > scheduling to favor sun4u". You can easily prove this to yourself with > 'gcc -v -mcpu=v8 -mtune=v9' and notice that what gets defined is > __sparc_v8__ which is strictly 32-bit. > > So when originally reported, this bug did not have any 64-bit-ness issues. > > The reason fur turning off __sparc_v9__ in the assembler code was to > prevent any from creeping in. > > The "-mcpu=v8 -mtune=v9" idiom was for a version of gcc which sometimes > "got it wrong" with cpu=v9, but the ebuilds seem to catch those cases, now. > > 8. So now, I just '-mcpu=v9'. But I didn't when I first reported this bug. > And all the _v9__ stuff was "belt & suspenders" type paranoia. > > (I wish I'd left it out... it's something of a red herring... but to be > completely safe, you do have to #undefine it in glapi.S...) > Yes, this I do understand. gcc sources though want to indicate that __sparc_v9__ is only set if you have -mcpu=v9, and *not* when -mtune is set ... What does then set __sparc_v9__ ? A gcc bug maybe ? Is it correct taht __sparc_v9__ should be set with -mcpu=v8, and -mtune=v9 ? From a x86 perspective, I would say no, as it should not have v9 specific features, just some alignment/whatever that should work better on a v9.
And ?
I have not seen __sparc_v9__ mean 64-bit anywhere on sparc linux. I routinely use '-mcpu=ultrasparc' which does define __sparc_v9__, and the code is 32-bit. glapi_sparc.S assumes __sparc_v9__ means 64-bit, and for some compilers it seems to, but never for gcc on linux for sparc today. -mcpu=v8 -mtune=v9 does not define __sparc_v9__ In xfree, -mcpu=v9 might or might not be filtered out be the ebuild. If it is not, and if it gets passed to the glapi.S routine, the code there assumes that __sparc_v9__ implies 64 bit, which currently is not a correct assumption. So, the *only* thing that sets __sparc_v9__ is -mcpu=v9 or an explicit -D__sparc_v9__. The only reason I messed with it at all was that I noticed that no matter what flags you use to compile glx, on linux you should not get into a situation where the source itself looks at __sparc_v9__ to see if the compiler is generating 64-bit code, because the compiler is never compiling 64-bit code. (At one point, what was setting __sparc_v9__ was me, chasing down the bug. I finally saw that the bug was independent of 64-bitness. So my intent here was to take it out, and to keep it out for the dispatch table stuff, no matter how the user had CFLAGS set in make.conf. The important thing is that the dispatch table format and the code to patch the table agree on 64-bitness, and I was forcing that, no matter what the Makefile finally decided on pasing in.) xfree can use some v9-specific features, I believe, in the display driver for the creator/elite video cards, but that is another matter. So far as I know, there is no v9 requirement for xfree. What glapi_sparc.S really needs to know is whether or not we are in 64-bit user mode, and right now, the answer to that is no. However, 64-bit user support for sparc linux is in the works, bit I have no idea how that will be communicated to routines like this one. For this particular problem, so far as I know, there is no compiler problem, nor is there a library problem, and glapi_sparc.S itself is fine. The only problem is that the dispatch table in glapi_sparc.S needs to be filled in on the fly, and for that to work, the table format and its initialization code have to agree on what it looks like.
Let me add a couple things which might help. 1. I don't know how 64-bit userland is going to work for sparc, so I don't know what a proper approach to a long-term fix to make sure that the glapi_sparc.S templates agree with the code that fills them in. The code that fills them in tries to guess what the instructions are, because it is rewriting them. All that really matters is for it to guess right. It would be much better to use something besides __sparc_v9__, because: 2. For performance reasons, a user might NEVER want 64-bit linkages, but there are other reasons to use '-mcpu=v9': that enables some v9-specific insructions for the assembler that you do want. (One that comes to mind is exchange-add, which is an atomic test-and-set operation that the programmer can use for a very fast semaphore or mutual exclusion operation, and it can occur in user code.) There are other v9-but-not-64-bit instructions that the compiler can generate with cpu=v9, and so far as I know, it does when appropriate. 3. The short answer is that I really don't know how to set up the check in the setup process. I think that gcc uses -mcpu=v9 to mean "sparc-v9 architecture, but for linux, use 32-bit style addressing" and it seems that xfree is using it to mean "64-bit style addressing." 4. So far as I can tell, this matters ONLY in glapi_sparc.S and the code that fills it in, and the ONLY place this ends up getting used seems to be in libGL. At least, that's what 'find xc -name '*.[Ss]' tells me. Sorry to make this so confusing.
Currently we don't have any plans for a 64 bit userland on sparc64, however it may be best to handle this fix as if we may someday.
I'll add one more thing which might help clear up the confusion. If you are not actually building this on sparc and watching the build, you might not have noticed that for whatever reason, the GL/glx build does not run glapi_sparc.S through the compile in one step. It does this instead: rm -f glapi_sparc.i /usr/bin/cpp -Dlinux -D__sparc__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_B SD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DIN_GLX -D__ELF__ -DGLXEXT -DXF86DRI -DGLX_DIRECT_R ENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA -D__GLX_ALIGN64 -DUSE_SPARC_ASM -I../../../exports/in clude -I../../../exports/include/X11 -I../../../include/extensions -I../../../exports/include/GL -I../../../lib/GL/glx -I../../../extras/Mesa/ src -I../../../extras/Mesa/src/X -I../../../extras/Mesa/src/SPARC -I../../../extras/Mesa/include -I../../../lib/GL/include -I../.. /../lib/GL/dri glapi_sparc.S | \ grep -v '^\#' > glapi_sparc.i rm -f glapi_sparc.o gcc -c -x assembler -mtune=v9 -o glapi_sparc.o glapi_sparc.i rm -f glapi_sparc.i And it uses a different set of flags for the preprocessing stage than for the general gcc calls for the C-source. Thus, it could happen (if the sparc setup went wrong) that: 1. glapi_sparc.S got compiled as 64-bit but the little template-fixer thought it was 32-bit (that's the new sparc.c); or, 2. If we have -mcpu=v9, that the template-fixer thought glapi_sparc.S had 64-bit linkages but the make file had set it up with 32-bit linkages. I do not know why the Makefile gets set up that way, but it does, and that strikes me as pretty bad. (The sunffb driver build for Creator & Elite video potentially has the same problem, and I'll report on that another day.) I have verified that it is unnecessary (gcc can handle the .S file just fine) for Linux, but for other compilers it might be required. So, if you look at sparc.c, you will see that I have forced it to assume that glapi_sparc.S was built with 32-bit linkages when it patches in the real dispatch table. This meant that no matter how xfree finally decided to build glapi_sparc.S, it HAD to use the 32-bit linkages, because sparc.c had no reliable way of figuring out what the build had decided on. Originally, the sparc.c that I copied in used the same check for __sparc_v9__ as glapi_sparc.S used, but for whatever reason, the configure process screws that up if it allows -mcpu=v9 (as it should) but does not propagate that to the cases where it decides to build the object in two stages. I have no clue why the build gets set up this way; that is in the Imakefile (which keys of the SparcArchitecture define) and imake's template for assembler files (whereever that is). SUMMARY: With the build today, __sparc_v9__ could never be set for glapi_sparc.S, so I arranged glapi.c never to build 64-bit linkages, no matter what architecture the user was optimizing for. Once you do that, glapi_sparc.S has to be backfit so that no matter what the Configure chooses to use as flags for the preprocessor, you don't get 64-bit linkages. The problem is that however you patch the linkage code, you have to patch for the correct linkages, and the way the Makefile gets built, that is hard unless you just force it (it seems to me). I don't know how to do a general fix for this, because I don't know all places the "corrected" code has to keep running (beyond GenToo). All this is for is to make sure the API dispatch table gets filled in, and that the dispatch table and the code to patch the addresses in to the instructions agree on the table format. Sorry to be so long winded; it becomes easier to see if you tear apart the output from the make. The right person to address this is whoever introduced the -DUSE_SPARC_ASSEMB decision into xfree-4.3.0 (it is new with this release), but I don't know who that is. (I would hope that person wouldn't have to guess what is supposed to be going on here ;).)
I've experienced this bug on an Ultra 2 Creator 3D. I did some looking around, and I think the best thing would be to contact someone who actually knows what is going on. The problem code is part of Mesa, so they would know what to do, I hope. Here are links to the cvsweb for the sparc asm: http://cvsweb.xfree86.org/cvsweb/xc/extras/Mesa/src/SPARC/ http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mesa3d/Mesa/src/SPARC/ Progress has been made by mesa3d which is not included in xfree86. Xfree86's last sync was to Mesa 4.0.1 I'm not sure what to look for in the files at the above sites, but there may be a fixed version already there.
I just tried to compile libGL using the suggestion of removing the USE_SPARC_ASM define. I ran ebuild xfree-4.3.0-r2.ebuild compile and I stopped the compile after all the Makefiles were setup. I then edited xc/lib/GL/glx/Makefile and Imakefile to replace 'ASM_DEFS = -DUSE_SPARC_ASM' with 'ASM_DEFS = ' I then ran make in /xc/lib/GL/glx/ followed by make in /xc/lib/GL/. I got the following error. There are a whole lot of the "multiple definition" lines, so I just pasted the ones at the end, the earlier ones go off the top of aterm's buffer. : multiple definition of `glLoadTransposeMatrixf' ../../../lib/GL/glx/dispatch.o(.text+0xe130): first defined here ../../../lib/GL/glx/glapi_sparc.o(.data+0x33a4): In function `glMultTransposeMatrixd': : multiple definition of `glMultTransposeMatrixd' ../../../lib/GL/glx/dispatch.o(.text+0xe17c): first defined here ../../../lib/GL/glx/glapi_sparc.o(.data+0x33b8): In function `glMultTransposeMatrixf': : multiple definition of `glMultTransposeMatrixf' ../../../lib/GL/glx/dispatch.o(.text+0xe1c8): first defined here ../../../lib/GL/glx/glapi_sparc.o(.data+0x33cc): In function `glSampleCoverage': : multiple definition of `glSampleCoverage' ../../../lib/GL/glx/dispatch.o(.text+0xe214): first defined here /usr/lib/gcc-lib/sparc-unknown-linux-gnu/3.2.3/../../../../sparc-unknown-linux-gnu/bin/ld: cannot find -lXext collect2: ld returned 1 exit status + rm -f libGL.so.1 + ln -s libGL.so.1.2 libGL.so.1 + rm -f ../../../exports/lib/libGL.so.1 + cd ../../../exports/lib + ln -s ../../lib/GL/GL/libGL.so.1 . rm -f libGL.so.1.2 mv -f libGL.so.1.2~ libGL.so.1.2 mv: cannot stat `libGL.so.1.2~': No such file or directory make[1]: *** [libGL.so.1.2] Error 1 make[1]: Leaving directory `/var/tmp/portage/xfree-4.3.0-r2/work/xc/lib/GL/GL' make: *** [all] Error 2 A little thinking and I also changed 'ASM_OBJS = glapi_sparc.o' to 'ASM_OBJS = ' and 'ASM_SRCS = glapi_sparc.S' to 'ASM_SRCS = ' But now, there is an error: + gcc -o ./libGL.so.1.2~ -shared -Wl,-Bsymbolic -Wl,-soname,libGL.so.1 ../../../lib/GL/glx/clientattrib.o ../../../lib/GL/glx/compsize.o ../../../lib/GL/glx/dispatch.o ../../../lib/GL/glx/eval.o ../../../lib/GL/glx/g_render.o ../../../lib/GL/glx/g_single.o ../../../lib/GL/glx/g_vendpriv.o ../../../lib/GL/glx/glapi.o ../../../lib/GL/glx/glthread.o ../../../lib/GL/glx/glxcmds.o ../../../lib/GL/glx/glxext.o ../../../lib/GL/glx/indirect_init.o ../../../lib/GL/glx/pixel.o ../../../lib/GL/glx/pixelstore.o ../../../lib/GL/glx/render2.o ../../../lib/GL/glx/renderpix.o ../../../lib/GL/glx/single2.o ../../../lib/GL/glx/singlepix.o ../../../lib/GL/glx/vertarr.o ../../../lib/GL/glx/xfont.o ../../../lib/GL/dri/XF86dri.o ../../../lib/GL/dri/dri_glx.o -lpthread -L../../../exports/lib -lXext -lX11 -ldl -lc /usr/lib/gcc-lib/sparc-unknown-linux-gnu/3.2.3/../../../../sparc-unknown-linux-gnu/bin/ld: cannot find -lXext collect2: ld returned 1 exit status + rm -f libGL.so.1 + ln -s libGL.so.1.2 libGL.so.1 + rm -f ../../../exports/lib/libGL.so.1 + cd ../../../exports/lib + ln -s ../../lib/GL/GL/libGL.so.1 . rm -f libGL.so.1.2 mv -f libGL.so.1.2~ libGL.so.1.2 mv: cannot stat `libGL.so.1.2~': No such file or directory make[1]: *** [libGL.so.1.2] Error 1 make[1]: Leaving directory `/var/tmp/portage/xfree-4.3.0-r2/work/xc/lib/GL/GL' make: *** [all] Error 2 So I modified xc/lib/GL/GL/Makefile to include /usr/X11R6/lib by setting "LDPRELIB = -L$(BUILDLIBDIR) $(INSTALLED_LIBS) -L/usr/X11R6/lib" (adding the "-L/usr/X11R6/lib" ). This let libGL.so.1.2 build. Modifying LDPRELIB should not be necessary if a full build is being preformed. I believe it was necessary in this case since exports/lib does not contain any libraries. I presume the make process places built libraries into exports/lib, and they were not present because I was only compiling libGL.so I, like Ferris, don't know how you can have the ebuild automatically change the Makefile when the Makefiles are dynamically generated.
After looking around some, it looks like you can probably just modify xc/lib/GL/glx/Imakefile at the end of the unpack stage. There you can blank out ASM_SRCS, ASM_OBJS, and ASM_DEFS. Then when the Makefile is created, it will not have the variables defined, and the non-assembly versions will be used. --- xc/lib/GL/glx/Imakefile.orig 2003-09-17 19:02:10.000000000 -0400 +++ xc/lib/GL/glx/Imakefile 2003-09-17 19:02:36.000000000 -0400 @@ -107,9 +107,9 @@ ASM_DEFS = -DUSE_X86_ASM #endif #if defined(SparcArchitecture) - ASM_SRCS = glapi_sparc.S - ASM_OBJS = glapi_sparc.o - ASM_DEFS = -DUSE_SPARC_ASM + ASM_SRCS = + ASM_OBJS = + ASM_DEFS = #endif #if GlxBuiltInXMesa
1. Jason's (the_deuce's) suggestion builds a working library for me (at least, good enough for -glxgears- and -blender-): -edit Imakefile as per the_deuce (well, I used '-UUSE_SPARC_ASSM' because I am a little paranoid, and I wanted to keep track in my local copy that there was an option here that I explicitly wanted disabled.) -restore original link for glapi.c -make clean -make Makefile -make -cd .. ; make -hand install new libGL.so.1.2 fron xc/lib/GL/GL (I have been keeping a completely built xfree in /usr/tmp/portage on U2 & U60) 2. For glxgears, no performance difference that I can see. 3. And much cleaner. 4. This puts off Martin's question about __sparc_v9__, because if Mesa and other applications depend on this (-mcpu=ultrasparc) to mean 64-bit linkages, while gcc (for linux) means ultrasparc architecture with 32-bit linkages, there will be problems. But that, I suppose, needs to be bounced to the gcc people and to the kernel 2.6 people...?
Created attachment 18634 [details, diff] patch based on suggestions from Azarah
I tried a patch to the X source based on comments here and from Azarah on IRC. I have attached it here, but it did not remedy it for me.
thanks for the help guys i patched my libGL and activated everything needed for OGL/DRI XF86 reports all extensions active, especially the dri module and XFree86-DRI, but glxinfo still reports Direct Rendering: No why? what did I forget? does it work at all? 75 fps on glxgears isn't bad for a 166MHz Ultra1, but i'd prefer a little more... btw: i'm using -r3 and there wasn't any fix yet had to do it myself
Following Gregor Riepl's advice, I have cross-referenced this entire bug to xfree, at <http://bugs.xfree86.org/show_bug.cgi?id=923> I hope I have done it in such a way that they can actually find this discussion. And I hope this problem isn't somehow GenToo-only :-)
Please note also bug #852204 in the Mesa3D project at SourceForge. This addresses the '__sparc_v9__' problem. Notice that Mesa (5.0.2) as a replacement for xfree's version of Mesa-as-libGL seems to work fine as-is if you make all the changes I noted in the 852204 report: Change #ifdef __sparc_v9__ to #if ( (defined(__sparc_v9__) && !defined(__linux__) )
It looks as if Mesa is going to take care of the 32/64 bit user mode mismatch which arises from '-mcpu=ultrasparc' when building libGL. Please see <https://sourceforge.net/tracker/?func=detail&atid=100003&aid=852204&group_id=3> And please see <http://bugs.xfree86.org/show_bug.cgi?id=923> for more comments regarding Mesa-xfree interface.
Here's a start on what's going on, and it sheds some light on the message: ========= Xlib: extension "XFree86-DRI" missing on display ":0.0". ========= The dispatch table is initialized by Mesa; specifically, from the _math_init part of Mesa initialization. And, when GL is built for SPARC, it is told to build it using Mesa. It is also told to NOT to build this into libGL; rather, it puts it in the module dri/ffb_dri.so So, most of Mesa is not really part of libGL, and it never gets initialized. (If you want to see the differences, compare xfree-glxinfo with Mesa-glxinfo: ================= ---- from xfree ---- ferris@lacewing:~/Packages/Snakes [390]% glxinfo name of display: :0.0 Xlib: extension "XFree86-DRI" missing on display ":0.0". display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.3 Mesa 4.0.4 OpenGL extensions: GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_border_clamp, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x27 24 tc 1 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None 0x28 24 tc 1 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None 0x29 24 tc 1 24 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None 0x2a 24 tc 1 24 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None 0x2b 24 dc 1 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None 0x2c 24 dc 1 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None 0x2d 24 dc 1 24 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None 0x2e 24 dc 1 24 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None 0x2f 8 pc 1 24 0 c y . 0 0 0 0 0 16 0 0 0 0 0 0 0 None 0x30 8 gs 1 24 0 c y . 0 0 0 0 0 16 0 0 0 0 0 0 0 None 0x31 8 sg 1 24 0 c y . 0 0 0 0 0 16 0 0 0 0 0 0 0 None ============== ===== --- from Mesa: --- ./glxinfo | more name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: Brian Paul server glx version string: 1.4 Mesa 5.0.2 server glx extensions: GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap, GLX_MESA_release_buffers, GLX_ARB_get_proc_address, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGI_video_sync, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer client glx vendor string: Brian Paul client glx version string: 1.4 Mesa 5.0.2 client glx extensions: GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap, GLX_MESA_release_buffers, GLX_ARB_get_proc_address, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGI_video_sync, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer GLX extensions: GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap, GLX_MESA_release_buffers, GLX_ARB_get_proc_address, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGI_video_sync, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer OpenGL vendor string: Brian Paul OpenGL renderer string: Mesa X11 OpenGL version string: 1.4 Mesa 5.0.2 OpenGL extensions: GL_ARB_depth_texture, GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_point_parameters, GL_ARB_shadow, GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_transpose_matrix, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_histogram, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, GL_EXT_paletted_texture, GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_shared_texture_palette, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_object, GL_EXT_texture_lod_bias, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_HP_occlusion_test, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_resize_buffers, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_blend_square, GL_NV_point_sprite, GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_NV_vertex_program, GL_NV_vertex_program1_1, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_pixel_texture, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_pixel_texture, GL_SGIX_shadow, GL_SGIX_shadow_ambient glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x27 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None 0x28 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x29 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x2a 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x2b 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x2c 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x2d 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x2e 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x2f 8 pc 0 8 0 r y . 2 3 3 0 0 16 8 16 16 16 16 0 0 None 0x30 8 gs 0 8 0 r y . 2 3 3 0 0 16 8 16 16 16 16 0 0 None 0x31 8 sg 0 8 0 r y . 2 3 3 0 0 16 8 16 16 16 16 0 0 None ======) NOW, if you replace 'Load "dri"' in XF86Config with this: SubSection "dri" Option "ffb_dri" "true" EndSubSection you seem to get Xfree-DRI extension added, although glxinfo still does not know about it. So, it lookg like Mesa still is not initialized. I suspect that there is a clue in the note "server glx vendor string: SGI" I am starting to sort-of see what is going on here, but I don't see yet what is supposed to be happening. I will next see what happens if you tell it to build the ffb_dri stuff into libGL instead of into an xfree module, but something about this is not looking right. What am I missing here?
Please note a very long summary of what seems to be going on here at <http://bugs.xfree86.org/show_bug.cgi?id=923> comment #11. Is any of this starting to make sense?
Created attachment 21699 [details, diff] Patch in GLapi dispatch table initialization for xfree-libGL See also <http://bugs.xfree86.org/show_bug.cgi?id=923> See also <https://sourceforge.net/tracker/?func=detail&atid=100003&aid=852204&group_id=3> Assume also the 813 #ifdef changes #ifdef __sparc_v9__ ==> #if (defined(__sparc_v9__) && !defined(__linux__) ) to the Mesa source in xfree. Assume you are working within xfree-4.3.99.16. Then, this little patch (to xc/lib/GL/glx/glxext.c) seems to give a version of libGL which can handle glxinfo, glxgears, blender, and crystal-space. This version of libGL doesn't give the annoying "XFree86-DRI extension missing" message anymore (no performance improvement, though.) However, since I don't actually know how glx works, this needs a lot of testing by people who actually use libGL... This proposal is based on intuition, not knowledge. Regards, Ferris
I should add that my testing has been limited to systems (U2, U60) with Elite video cards. Thus, the only driver used has been sunffb, and sunffb-Elite does NOT use xfree's dri module. So there is a lot of stuff that needs checking. But the effect of this patch is just to move the initialization from 'glapi.c' (which is part of Mesa) to glxext.c (which is from SGA, I believe.) This shouldn't matter, but I can't verify it. (With enough time, I can play with the Creator path through sunffb, but not right away.)
Three comments further: 1. The brace on the next-to-last line of the patch should be moved up to the other side of the #else three lines above it (or glext.c will not compile on non-sparc systems); 2. This approach does work for sunffb-Creator (I retrofit the stuff back into xfree-4.3.0-r3 for the Creator test. The original test was against latest xfree at xfree's perfectly reasonable request.) 3. This is more of a user-type question: Dawes in the response to the corresponding bug report at xfree (comment #42 for reference) believes that the xfree module ffb_dri.so in /usr/X11R6/lib/modules/dri should be initializing the libGL glAPI table. But I don't see it. Where in the documentation can I find how to even use this module? It has to be something in the XF86Config file, but I can't find it documented, and a source scan of the entire xfree (xc) build tree does not turn up anything useful to me. I can't see that the libdri (dri extension), the logical owner, does anything with it. For this to work, it has to be linked into the libGL address space, and it has to preempt the libGL initialization, but it has to have libGL present because that's where the unitialized dispatch table is to begin with. (ffb_dri.so does not have it at all.) I'm completely missing something pretty basic here. HELP?!!?
Created attachment 21789 [details, diff] Corresponding patch for xc/lib/GL/glx/glxext.c, zfree-4.3.0-r3 Attached patch will apply to xc/lib/GL/glx/glxext.c in xfree-4.3.0-r3. Along with the corresponding #ifdef __sparc_v9__ changes (only 600 or so in this version), the resulting library appears to work.
And, in case it is not clear from all my ramblings: There are three modules affected by this (either by the change to glxext.c, or by the 600+ #ifdef changes in xc/extras/Mesa/src[/SPARC]). 1. libGL.so.1.2 itself 2. ffb_dri.so (built in xc/lib/GL/mesa/src/drv/ffb/ffb_dri.so and installed in /usr/X11R6/lib/modules/dri 3. libOSMesa built in /xc/lib/GL/mesa/src/OSmesa/libOSMesa.so.4.0 and installed in /usr/X11R6/lib Because the glx extension is not built with -DUSE_SPARC_ASM, it and its helper libGLCore.a do not change. So, a fair test needs to have the 3 *.so modules from lib/GL put into production. I don't think anything else in the xfree installation is changed.
Please review the last few comments at <http://bugs.xfree86.org/show_bug.cgi?id=923> for sanity, but I am pretty sure that 2003-12-0[46] patches are pretty close to what is required to fix this for current and proposed xfree-4.3.xx Again, for this to work, all of the #ifdef __sparc_v9__ tests in xc/extras/Mesa/src[/SPARC] need to be sometning like #if (defined(__sparc_v9__) && (!defined(__linux__) || defined(__sparc_linux_64__))) To recap the comments in the corresponding xfree bug 923: 1. This initialization has to happen through software because the assember loader combination either can't or won't for sparc (&_glapi_Dispatch gets split across 2 instructions.) 2. This is a local address (to libGL). The server can provide linkages within the table, but not the address of the table itself. So the xfree speculation that the server should set this up seems wrong. 3. This patch occurs as part of the glXInitialization which I think always has to happen before libGL can do anything, no matter who puts the address of the dispatch vector into _glapi_Dispatch. Does this make any sense? Regards,
Xfree (at bug 923) has taken this patch. I sure hope it's right, because I'll have to crawl under rocks someplace if I've really screwed up after all of this.
Created attachment 21930 [details] Automate the #ifdef --> #if (defined(_sparc_v9__).... changes to xc/extras/Mesa Running this script in the work directory where you are building xfree will patch the (known) Mesa files containing #ifdef __sparc_v9__ As long as Mesa does not add or delete from the set of files using this flag, the script should work regardless of what version of xfree you are playing with. My test looked like: cd /var/tmp/portage/xfree-4.3.0-r3/work cp ~ferris/PATCH_V9 . ./PATCH_V9
The last attachment is a little bash script to complete the automation of a possible fix for this. It is a little collection of '"sed's" which edit the Mesa sources which depend on Sparc assembler to change #ifdef __sparc_v9__ ==> #if (defined(__sparc_v9__) && (!defined(__linux__) || defined(__linux_64__))) where __linux_64__ is just something I made up to indicate that if we are in 64-bit usermode for sparc, we don't want to disable the 64-bit addressing. So, an automated fix which apparently works for xfree-4.3.0-r3 looks like 1. Unpack sources 2. cp glx.patch var/tmp/portage/xfree-4.3.0-r3/work/ cp PATCH_V9 var/tmp/portage/xfree-4.3.0-r3/work/ (or whatever you call them) 3. cd /var/tmp/portage/xfree-4.3.0-r3/work 4. patch -b -z - -p0 < glx.patch 5. ./PATCH_V9 6. cd xc and manually verify that the changes you wanted are present 7. Build & test Regards, Ferris
Just for the record, glxgears works fine on my Ultra5 with the newest XFree. [ebuild R ] x11-base/xfree-4.3.99.902-r2 -(3dfx) -cjk -debug -doc -ipv6 -nls +pam -sdk -static +truetype -xml2 bazik@darwin bazik $ glxgears 307 frames in 5.0 seconds = 61.400 FPS 320 frames in 5.0 seconds = 64.000 FPS 320 frames in 5.0 seconds = 64.000 FPS 320 frames in 5.0 seconds = 64.000 FPS 320 frames in 5.0 seconds = 64.000 FPS Not very fast tho ;)
Thanks for the information. I'll try to look at it in the next day or so. How fast is your CPU and what kind of graphics card are you using? Because no, that's not very fast at all. (Unless you have about a 176MHz CPU).
> How fast is your CPU and what kind of graphics card are you using? 440 Mhz Ultrasparc IIi and the onboard 4 MB ATI card. direct rendering is disabled, so it looks like it useses software rendering. How can I enable direct rendering? Never had use for it on Linux ;) glxinfo: bazik@darwin bazik $ glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_make_current_read client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group GLX extensions: GLX_ARB_get_proc_address, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGI_make_current_read OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.4 Mesa 5.0.2 OpenGL extensions: GL_ARB_depth_texture, GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_point_parameters, GL_ARB_shadow, GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_transpose_matrix, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_texture_mirror_once, GL_ATI_texture_env_combine3, GL_IBM_texture_mirrored_repeat, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_NV_blend_square, GL_NV_texgen_reflection, GL_NV_texture_rectangle, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow, GL_SGIX_shadow_ambient glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x23 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x24 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 None 0x25 16 tc 0 24 0 r y . 5 6 5 8 0 16 8 16 16 16 16 0 0 None 0x26 16 tc 0 24 0 r . . 5 6 5 8 0 16 8 16 16 16 16 0 0 None 0x27 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x28 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 None 0x29 16 dc 0 24 0 r y . 5 6 5 8 0 16 8 16 16 16 16 0 0 None 0x2a 16 dc 0 24 0 r . . 5 6 5 8 0 16 8 16 16 16 16 0 0 None
So far as I can tell, xfree doesn't build direct rendering support for the ATI (mach64?) card. (Of course, what it "builds" for the Creator is flat out broken.) That said, though, in your Config file's Modules section, you ought to be able to Load "dri" Load "drm" Load "glx" and your driver should use as much of this as it can. There are several ati-related drivers, and some of them do talk about DRM. They seem to be for radeon stuff, though, and I really don't know anything about ati cards at all. I'll look more closely at it in a day or so. I've been tied up on some other things for the last two or three days.
mach64 cards should be able to use direct rendering, at least on x86. Don't know of any special issues on sparc. You'll need the kernel module for mach64 though.
As Sven Blumenstein suspected, the final patch and set of #ifdefs are present in xfree-4.3.99.902-r2: You neither need to nor want to apply them by hand if you are testing this version. (Notice that the #ifdef version is testing #if defined(__sparc_v9__) && !defined(__linux__) so if you are testing a 64-but userland version of xfree, you need to unapply them. But why would you want a 64-bit version of libGL???)
Created attachment 29642 [details, diff] Patch to today's cvs ebuilds for -r5, -r6 which fixes this bug. As requested by spyderous, I am attaching a patch file against today's cvs version of the ebuilds for 4.3.0-r5, 4.3.0-r6 which should close this bug. For reference, I shall next attach the patch file these (patched) ebuilds use, but it is the same as number 21789.
Created attachment 29643 [details, diff] The patch file referenced ain the previous attachment as ${FILESDIR}/sparc-glx-4.3.0-patch This is the file from which the patched ebuilds do their 'epatch' in my test tree. It should be the same as 21789.
At spyderous's request, reassign to xfree@gentoo.org for final processing. From a sparc point of view, this bug is fixed (i.e., unless spyderous needs anything more from me, I am finished with it.)
Ferris, could you convert all that sed stuff in the ebuild into a source patch and integrate it with the other source patch? I didn't realize it was so extensive.
Sure, I'll do it tomorrow. I did it with sed because as a patch, it's huge. (It'll take me about 5 minutes to do it, but I don't have the source unpacked on the system I'm on now). You will have the entire fix in one big patch file. Regards,
Created attachment 29686 [details, diff] Entire fix for sparc, xfree-4.3.0, as one big patch file Donnie, Here's the complete fix as one big patch. It forces dispatch table initialization and makes sure never to use 64-bit user mode in Mesa. This really only matters to sparc, and it is for 4.3.0 only. It is already present in the 4.3.99.902-r2 snapshot, and it is present in the xorg-x11-6.7.0 branch (which is where I am going to concentrate), although in a somewhat cleaner form (so far as the sparc_v9 checks go). Hope this helps. Regards, Ferris
I am taking this bug back in preparation of closing it. The problem described here is fixed in xorg-x11, essentially as shown in the current patch attachment. xorg-x11 is now stable on sparc and is the default for new installations. Consequently, this bug should not show up again. I am going to hold it for a couple days, and if nothing unexpected turns up, I am going to close it as fixed in xorg-x11.
This bug is fixed in xorg-x11-6.7.0, which has been stable for sparc for a little over a week with no problems reported. xorg-x11 is currently stable also for ppc, arm, and amd64. Spyderous's 3 June ChangeLog entry indicates that probably xorg-x11 should be ready to go stable pretty much across the board. Therefore, I am marking this as fixed. There is no need to apply the patch to xfree-4.3.0-r5, because xorg-x11 is a stable alternative in which the patch is already present.