Re: Moving forward with the TLS work
Am Samstag, 3. Juli 2004 01:12 schrieb Roland Scheidegger: > Dieter Nützel wrote: > > Am Freitag, 2. Juli 2004 02:03 schrieb Ian Romanick: > >>Dieter Nützel wrote: > >>>Am Donnerstag, 1. Juli 2004 20:07 schrieb Dieter Nützel: > Am Donnerstag, 1. Juli 2004 18:53 schrieb Ian Romanick: > >Dieter Nützel wrote: > >>quake3-smp do NOT work anylonger. > > > >Could you try these two patches? They *should* fix the crash you're > >seeing. > > The "first" one, YES. But... > >> > >>Okay. I just committed fixes that /should/ take care of everything. In > >>addition to the changes in the patch, there were a couple of dumb > >>mistakes in glapi.c. I have verified that Quake 3 SMP works as well on > >>MGA as it did before any of the TLS work. I also verified glthreads > >>with 10 threads. > > > > GOOD work! > > Hmm, and I'm sitting here and now can't get anything to work with these > changes. I think I'll just update to SuSE 9.1, with 2.6 kernel and > whatnot, that might just fix the problem ;-). SuSE 9.0, but with glibc-2.3.3-73 (SuSE 9.0.42) kernel 2.6.4-54.5-smp (SuSE 9.0.42/9.1) but much to old some newer packages Based on old SuSE 9.0 XFree86. NPTL needed? Greetings, Dieter I have to stop, now. --- My wife;-) --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Moving forward with the TLS work
Dieter Nützel wrote: Am Freitag, 2. Juli 2004 02:03 schrieb Ian Romanick: Dieter Nützel wrote: Am Donnerstag, 1. Juli 2004 20:07 schrieb Dieter Nützel: Am Donnerstag, 1. Juli 2004 18:53 schrieb Ian Romanick: Dieter Nützel wrote: quake3-smp do NOT work anylonger. Could you try these two patches? They *should* fix the crash you're seeing. The "first" one, YES. But... Okay. I just committed fixes that /should/ take care of everything. In addition to the changes in the patch, there were a couple of dumb mistakes in glapi.c. I have verified that Quake 3 SMP works as well on MGA as it did before any of the TLS work. I also verified glthreads with 10 threads. GOOD work! Hmm, and I'm sitting here and now can't get anything to work with these changes. I think I'll just update to SuSE 9.1, with 2.6 kernel and whatnot, that might just fix the problem ;-). Roland --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Moving forward with the TLS work
Am Freitag, 2. Juli 2004 02:03 schrieb Ian Romanick: > Dieter Nützel wrote: > > Am Donnerstag, 1. Juli 2004 20:07 schrieb Dieter Nützel: > >>Am Donnerstag, 1. Juli 2004 18:53 schrieb Ian Romanick: > >>>Dieter Nützel wrote: > quake3-smp do NOT work anylonger. > >>> > >>>Could you try these two patches? They *should* fix the crash you're > >>>seeing. > >> > >>The "first" one, YES. But... > > Okay. I just committed fixes that /should/ take care of everything. In > addition to the changes in the patch, there were a couple of dumb > mistakes in glapi.c. I have verified that Quake 3 SMP works as well on > MGA as it did before any of the TLS work. I also verified glthreads > with 10 threads. GOOD work! -Dieter --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Moving forward with the TLS work
Dieter Nützel wrote: Am Donnerstag, 1. Juli 2004 20:07 schrieb Dieter Nützel: Am Donnerstag, 1. Juli 2004 18:53 schrieb Ian Romanick: Dieter Nützel wrote: quake3-smp do NOT work anylonger. Could you try these two patches? They *should* fix the crash you're seeing. The "first" one, YES. But... Okay. I just committed fixes that /should/ take care of everything. In addition to the changes in the patch, there were a couple of dumb mistakes in glapi.c. I have verified that Quake 3 SMP works as well on MGA as it did before any of the TLS work. I also verified glthreads with 10 threads. --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Moving forward with the TLS work
Am Donnerstag, 1. Juli 2004 20:07 schrieb Dieter Nützel:
> Am Donnerstag, 1. Juli 2004 18:53 schrieb Ian Romanick:
> > Dieter Nützel wrote:
> > > quake3-smp do NOT work anylonger.
> >
> > Could you try these two patches? They *should* fix the crash you're
> > seeing.
>
> The "first" one, YES. But...
>
> ...loading 'scripts/skin.shader'
> ...loading 'scripts/sky.shader'
> ...loading 'scripts/test.shader'
> - finished R_Init -
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1233759152 (LWP 9827)]
> 0x44c3bfb9 in _mesa_Viewport () from /usr/X11R6/lib/modules/dri/r200_dri.so
> (gdb) c
> Continuing.
> Received signal 11, exiting...
>
> Program exited normally.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1233849264 (LWP 32396)]
_mesa_Viewport (x=0, y=0, width=640, height=480) at matrix.c:551
551ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH(ctx);
(gdb) list
546 */
547 void GLAPIENTRY
548 _mesa_Viewport( GLint x, GLint y, GLsizei width, GLsizei height )
549 {
550GET_CURRENT_CONTEXT(ctx);
551ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH(ctx);
552_mesa_set_viewport(ctx, x, y, width, height);
553 }
554
555 /**
(gdb) info registers
eax0x0 0
ecx0x896b758144095064
edx0xf7f3967
ebx0x0 0
esp0x498b0984 0x498b0984
ebp0x0 0x0
esi0x1e0480
edi0x280640
eip0x44c438d9 0x44c438d9
eflags 0x10212 66066
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
Is this more helpful?
-Dieter
---
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Moving forward with the TLS work
Am Donnerstag, 1. Juli 2004 18:53 schrieb Ian Romanick: > Dieter Nützel wrote: > > quake3-smp do NOT work anylonger. > > Could you try these two patches? They *should* fix the crash you're > seeing. The "first" one, YES. But... ...loading 'scripts/skin.shader' ...loading 'scripts/sky.shader' ...loading 'scripts/test.shader' - finished R_Init - Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1233759152 (LWP 9827)] 0x44c3bfb9 in _mesa_Viewport () from /usr/X11R6/lib/modules/dri/r200_dri.so (gdb) c Continuing. Received signal 11, exiting... Program exited normally. -Dieter --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Moving forward with the TLS work
On Thu, 01 Jul 2004 08:56:31 -0700 Ian Romanick <[EMAIL PROTECTED]> wrote: > Dieter Nützel wrote: > > > quake3-smp do NOT work anylonger. > > Allow me to express, for the record, how much I *HATE* the XFree86 build > process. The problem is that assembly files don't get built with the > threading related defines (i.e., -DXTHREADS). The result is that > glapi_x86.S gets built without threading support. I'm trying to figure > out which magic incantation is required to get the right flags on the > right command line. Man, imake just *sucks*. I remember having a similar problem once. Check the mailing list archives for a mail with this subject: Problem with t_vtx_x86_gcc.S in DRI build system Hope this helps, Felix | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Moving forward with the TLS work
Dieter Nützel wrote: quake3-smp do NOT work anylonger. Could you try these two patches? They *should* fix the crash you're seeing. ? src/mesa/glapi/gl_XML.pyc ? src/mesa/glapi/license.pyc Index: src/mesa/glapi/gl_x86_asm.py === RCS file: /cvs/mesa/Mesa/src/mesa/glapi/gl_x86_asm.py,v retrieving revision 1.2 diff -u -d -r1.2 gl_x86_asm.py --- src/mesa/glapi/gl_x86_asm.py29 Jun 2004 19:08:20 - 1.2 +++ src/mesa/glapi/gl_x86_asm.py1 Jul 2004 16:50:46 - @@ -77,6 +77,10 @@ print '#define GLOBL_FN(x) GLOBL x' print '#endif' print '' + print '#if defined(PTHREADS) || defined(XTHREADS) || defined(SOLARIS_THREADS) || defined(WIN32_THREADS) || defined(BEOS_THREADS)' + print '# define THREADS' + print '#endif' + print '' print '#if defined(PTHREADS)' print '# define GL_STUB(fn,off,fn_alt)\t\t\t\\' print 'ALIGNTEXT16;\t\t\t\t\t\t\\' Index: src/mesa/x86/glapi_x86.S === RCS file: /cvs/mesa/Mesa/src/mesa/x86/glapi_x86.S,v retrieving revision 1.37 diff -u -d -r1.37 glapi_x86.S --- src/mesa/x86/glapi_x86.S29 Jun 2004 19:08:20 - 1.37 +++ src/mesa/x86/glapi_x86.S1 Jul 2004 16:50:47 - @@ -47,6 +47,10 @@ #define GLOBL_FN(x) GLOBL x #endif +#if defined(PTHREADS) || defined(XTHREADS) || defined(SOLARIS_THREADS) || defined(WIN32_THREADS) || defined(BEOS_THREADS) +# define THREADS +#endif + #if defined(PTHREADS) # define GL_STUB(fn,off,fn_alt) \ ALIGNTEXT16; \ Index: lib/GL/glx/Imakefile === RCS file: /cvs/dri/xc/xc/lib/GL/glx/Imakefile,v retrieving revision 1.25 diff -u -d -r1.25 Imakefile --- lib/GL/glx/Imakefile17 Jun 2004 21:23:05 - 1.25 +++ lib/GL/glx/Imakefile1 Jul 2004 16:50:33 - @@ -135,7 +135,7 @@ SRCS = $(GLX_SRCS) $(ASM_SRCS) $(DRI_SRCS) OBJS = $(GLX_OBJS) $(ASM_OBJS) $(DRI_OBJS) - DEFINES = $(GLX_DEFS) $(ASM_DEFS) $(XMESA_DEFINES) + DEFINES = $(GLX_DEFS) $(ASM_DEFS) $(XMESA_DEFINES) $(THREADS_DEFINES) INCLUDES = -I$(XINCLUDESRC) \ -I$(MESASRCDIR)/include \
Re: Moving forward with the TLS work
Am Donnerstag, 1. Juli 2004 17:56 schrieb Ian Romanick: > Dieter Nützel wrote: > > quake3-smp do NOT work anylonger. > > Allow me to express, for the record, how much I *HATE* the XFree86 build > process. The problem is that assembly files don't get built with the > threading related defines (i.e., -DXTHREADS). The result is that > glapi_x86.S gets built without threading support. I'm trying to figure > out which magic incantation is required to get the right flags on the > right command line. Man, imake just *sucks*. Don't worry, be happy...;-) Ian, you are so fast. I can resign my DEBUG compilation run. Thanks! -- Dieter Nützel @home: --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Moving forward with the TLS work
Dieter Nützel wrote: quake3-smp do NOT work anylonger. Allow me to express, for the record, how much I *HATE* the XFree86 build process. The problem is that assembly files don't get built with the threading related defines (i.e., -DXTHREADS). The result is that glapi_x86.S gets built without threading support. I'm trying to figure out which magic incantation is required to get the right flags on the right command line. Man, imake just *sucks*. --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Moving forward with the TLS work
Am Freitag, 25. Juni 2004 11:06 schrieb Dieter Nützel: > Am Freitag, 25. Juni 2004 00:10 schrieb Ian Romanick: > > Dieter Nützel wrote: > > > Am Mittwoch, 23. Juni 2004 02:22 schrieb Ian Romanick: > > >>This patch also still requires you to manually generate glapi_x86.S by > > >>doing: > > >> > > >>cd src/mesa/glapi > > >>python2 ./gl_x86_asm.py > ../x86/glapi_x86.S > > > > > > With and without I get this in _normal_ DRI CVS: > > > > You probably need to rebuild everything. > > That's my _daily_ work... OK, this _one_ is SOLVED. But TLS is VERY expensive. quake3-smp do NOT work anylonger. fps are down to 134 (from 173). /opt/Mesa> quake3-smp & [1] 9040 /opt/Mesa> [1]Fertigquake3-smp Nothing remarkable in my log. /opt/games/quake3/log is attached. But with gdb I get something: Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 1076387968 (LWP 9226)] 0x44cf6b78 in _mesa_test_os_sse_exception_support () from /usr/X11R6/lib/modules/dri/r200_dri.so (gdb) c Continuing. Mesa: software DXTn compression/decompression available GL_RENDERER: Mesa DRI R200 20030328 AGP 4x x86/MMX+/3DNow!+/SSE TCL Initializing OpenGL extensions ...using GL_S3_s3tc ...using GL_EXT_texture_env_add ...using GL_ARB_multitexture ...using GL_EXT_compiled_vertex_array XF86 Gamma extension initialized Trying SMP acceleration... Render thread starting [New Thread 1233742768 (LWP 9270)] ...succeeded. GL_VENDOR: Tungsten Graphics, Inc. GL_RENDERER: Mesa DRI R200 20030328 AGP 4x x86/MMX+/3DNow!+/SSE TCL GL_VERSION: 1.3 Mesa 6.1 GL_EXTENSIONS: GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture 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_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate 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_histogram GL_EXT_packed_pixels GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texture GL_EXT_texture3D GL_EXT_texture_compression_s3tc GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_vertex_array GL_APPLE_packed_pixels GL_ATI_blend_equation_separate GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate GL_MESA_pack_invert GL_MESA_ycbcr_texture GL_MESA_window_pos GL_NV_blend_square GL_NV_light_max_exponent GL_NV_texture_rectangle GL_NV_texgen_reflection GL_SGI_color_matrix GL_SGI_color_table GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_S3_s3tc GL_MAX_TEXTURE_SIZE: 2048 GL_MAX_ACTIVE_TEXTURES_ARB: 4 PIXELFORMAT: color(24-bits) Z(24-bit) stencil(8-bits) MODE: 3, 640 x 480 windowed hz:N/A GAMMA: hardware w/ 0 overbright bits CPU: rendering primitives: single glDrawElements texturemode: GL_LINEAR_MIPMAP_LINEAR picmip: 1 texture bits: 32 multitexture: enabled compiled vertex arrays: enabled texenv add: enabled compressed textures: enabled Using dual processor acceleration Program received signal SIGSEGV, Segmentation fault. 0x44b66305 in glClearDepth () from /usr/X11R6/lib/libGL.so.1 (gdb) c Continuing. Received signal 11, exiting... Program exited normally. (gdb) Will recompile with DEBUG. -Dieter log.bz2 Description: BZip2 compressed data
Re: Moving forward with the TLS work
Am Freitag, 25. Juni 2004 00:10 schrieb Ian Romanick:
> Dieter Nützel wrote:
> > Am Mittwoch, 23. Juni 2004 02:22 schrieb Ian Romanick:
> >>This patch also still requires you to manually generate glapi_x86.S by
> >>doing:
> >>
> >>cd src/mesa/glapi
> >>python2 ./gl_x86_asm.py > ../x86/glapi_x86.S
> >
> > With and without I get this in _normal_ DRI CVS:
>
> You probably need to rebuild everything.
That's my _daily_ work...
time nice +19 make -j20 realclean
find -name '*.o' | xargs rm
find -name '*.a' | xargs rm
find -name '*.so' | xargs rm
/opt/Mesa> du -s
46188 .
time nice +19 make -j20 linux-x86
1:30 later I got normally a working Mesa CVS.
Then I went to DRI CVS...
> glapi_x86.S used to get linked
> with the drivers in the Mesa tree, adn this caused problems with some of
> the changes in the most recent patch. I changed the 'sources' file in
> the Mesa tree, and that probably impacts the Makefiles in the DRI tree.
> If that doesn't fix things, I'm not really sure what the problem could
> be.
SuSE 9.0 with glibc-2.3.3 ;-)
/opt/Mesa> python -V
Python 2.3+
/opt/Mesa> gcc --version
gcc (GCC) 3.3.1 (SuSE Linux)
/opt/Mesa> cd src/mesa/glapi
mesa/glapi> l gl_x86_asm.py
-rw-r--r--1 nuetzel users3908 2004-05-18 20:33 gl_x86_asm.py
mesa/glapi> python ./gl_x86_asm.py > ../x86/glapi_x86.S
/opt/Mesa/src/mesa/glapi/gl_XML.py:89: FutureWarning: int('0...', 0): sign
will change in Python 2.4
self.value = int(attrs.get('value', "0x"), 0)
mesa/glapi> l ../x86/glapi_x86.S
-rw-r--r--1 nuetzel users 41615 2004-06-25 11:01 ../x86/glapi_x86.S
I've attached glapi_x86.S.bz2.
Thanks,
Dieter
glapi_x86.S.bz2
Description: BZip2 compressed data
Re: Moving forward with the TLS work
Dieter Nützel <[EMAIL PROTECTED]> writes: > With and without I get this in _normal_ DRI CVS: did you reconfigure Mesa (i.e. make linux-x86 or whatever your platform is)? that solved it for me. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Moving forward with the TLS work
Dieter Nützel wrote: Am Mittwoch, 23. Juni 2004 02:22 schrieb Ian Romanick: This patch also still requires you to manually generate glapi_x86.S by doing: cd src/mesa/glapi python2 ./gl_x86_asm.py > ../x86/glapi_x86.S With and without I get this in _normal_ DRI CVS: You probably need to rebuild everything. glapi_x86.S used to get linked with the drivers in the Mesa tree, adn this caused problems with some of the changes in the most recent patch. I changed the 'sources' file in the Mesa tree, and that probably impacts the Makefiles in the DRI tree. If that doesn't fix things, I'm not really sure what the problem could be. --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Moving forward with the TLS work
Am Mittwoch, 23. Juni 2004 02:22 schrieb Ian Romanick: > Ian Romanick wrote: > This patch also still requires you to manually generate glapi_x86.S by > doing: > > cd src/mesa/glapi > python2 ./gl_x86_asm.py > ../x86/glapi_x86.S With and without I get this in _normal_ DRI CVS: make[3]: Entering directory `/opt/Mesa/progs/demos' gcc -I../../include -Wall -O -march=athlon -ansi -pedantic -fPIC -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -DUSE_XSHM -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -DPTHREADS -I/usr/X11R6/include arbfplight.c -L../../lib -lglut -lGLU -lGL -lm -o arbfplight arbfplight.c: In function `Init': arbfplight.c:236: Warnung: string length `900' is greater than the length `509' ISO C89 compilers are required to support arbfplight.c:262: Warnung: string length `729' is greater than the length `509' ISO C89 compilers are required to support /tmp/ccKXsnUw.o(.text+0x1c): In function `Redisplay': : undefined reference to `glClear' /tmp/ccKXsnUw.o(.text+0x50): In function `Redisplay': : undefined reference to `glEnable' /tmp/ccKXsnUw.o(.text+0x5c): In function `Redisplay': : undefined reference to `glEnable' /tmp/ccKXsnUw.o(.text+0x68): In function `Redisplay': : undefined reference to `glDisable' /tmp/ccKXsnUw.o(.text+0x88): In function `Redisplay': : undefined reference to `glLightfv' /tmp/ccKXsnUw.o(.text+0x94): In function `Redisplay': : undefined reference to `glDisable' /tmp/ccKXsnUw.o(.text+0xa0): In function `Redisplay': : undefined reference to `glDisable' /tmp/ccKXsnUw.o(.text+0xac): In function `Redisplay': : undefined reference to `glEnable' /tmp/ccKXsnUw.o(.text+0xb1): In function `Redisplay': : undefined reference to `glPushMatrix' /tmp/ccKXsnUw.o(.text+0xd7): In function `Redisplay': : undefined reference to `glRotatef' /tmp/ccKXsnUw.o(.text+0xf1): In function `Redisplay': : undefined reference to `glRotatef' /tmp/ccKXsnUw.o(.text+0x114): In function `Redisplay': : undefined reference to `glPopMatrix' /tmp/ccKXsnUw.o(.text+0x230): In function `Reshape': : undefined reference to `glViewport' /tmp/ccKXsnUw.o(.text+0x23c): In function `Reshape': : undefined reference to `glMatrixMode' /tmp/ccKXsnUw.o(.text+0x241): In function `Reshape': : undefined reference to `glLoadIdentity' /tmp/ccKXsnUw.o(.text+0x277): In function `Reshape': : undefined reference to `glFrustum' /tmp/ccKXsnUw.o(.text+0x283): In function `Reshape': : undefined reference to `glMatrixMode' /tmp/ccKXsnUw.o(.text+0x288): In function `Reshape': : undefined reference to `glLoadIdentity' /tmp/ccKXsnUw.o(.text+0x2a4): In function `Reshape': : undefined reference to `glTranslatef' /tmp/ccKXsnUw.o(.text+0x3b1): In function `Key': : undefined reference to `glPolygonMode' /tmp/ccKXsnUw.o(.text+0x7bf): In function `Init': : undefined reference to `glGetIntegerv' /tmp/ccKXsnUw.o(.text+0x7c4): In function `Init': : undefined reference to `glGetError' /tmp/ccKXsnUw.o(.text+0x7f1): In function `Init': : undefined reference to `glGetString' /tmp/ccKXsnUw.o(.text+0xa2c): In function `Init': : undefined reference to `glGetIntegerv' /tmp/ccKXsnUw.o(.text+0xa31): In function `Init': : undefined reference to `glGetError' /tmp/ccKXsnUw.o(.text+0xa61): In function `Init': : undefined reference to `glGetString' /tmp/ccKXsnUw.o(.text+0xae7): In function `Init': : undefined reference to `glClearColor' /tmp/ccKXsnUw.o(.text+0xaf3): In function `Init': : undefined reference to `glEnable' /tmp/ccKXsnUw.o(.text+0xaff): In function `Init': : undefined reference to `glEnable' /tmp/ccKXsnUw.o(.text+0xb0b): In function `Init': : undefined reference to `glEnable' /tmp/ccKXsnUw.o(.text+0xb29): In function `Init': : undefined reference to `glMaterialfv' /tmp/ccKXsnUw.o(.text+0xb47): In function `Init': : undefined reference to `glMaterialfv' /tmp/ccKXsnUw.o(.text+0xb65): In function `Init': : undefined reference to `glMaterialf' /tmp/ccKXsnUw.o(.text+0xb71): In function `Init': : undefined reference to `glGetString' ../../lib/libGL.so: undefined reference to `glTexSubImage3D' ../../lib/libGL.so: undefined reference to `glDrawElements' ../../lib/libGL.so: undefined reference to `glSetFenceNV' ../../lib/libGL.so: undefined reference to `glCompressedTexImage3D' ../../lib/libGL.so: undefined reference to `glTexCoordPointer' ../../lib/libGL.so: undefined reference to `glTexGeniv' ../../lib/libGL.so: undefined reference to `glColorTableParameteriv' ../../lib/libGL.so: undefined reference to `glColor3ub' ../../lib/libGL.so: undefined reference to `glIsTexture' ../../lib/libGL.so: undefined reference to `glUnlockArraysEXT' ../../lib/libGL.so: undefined reference to `glMultTransposeMatrixf' ../../lib/libGL.so: undefined reference to `glGetConvolutionFilterEXT' ../../lib/libGL.so: undefined reference to `glCompressedTexImage1D' ../../lib/libGL.so: undefined reference to `glTestFenceNV' ../../lib/libGL.so: undefined reference to `glVertexAttrib4sARB' ../../lib/libGL.so: undefined reference to `glRasterPos2s' ../../lib
Re: Moving forward with the TLS work
Brian Paul wrote: Ian, I haven't had time to follow this too closely. A few questions: 1. Is thread safety in the GL API layer going to require TLS now? What about people who want thread safety but aren't using a version of Linux that supports TLS? It won't require it. We'll be able to build a libGL with or without support for TLS. libGL binaries built with TLS support will require the system to support TLS (I think), but they won't require TLS enabled drivers. I intend to add an env. variable to disable the use of TLS client-side drivers. 2. Which common Linux distros support TLS? I believe RH9 and later do, but that's all I'm aware of. There's two different issues. The first is, "Which distros support TLS at all?" I think any distro based on a 2.6.x kernel will support TLS. The other issue is, "Which distros ship a TLS enabled libGL that won't work with our nightly builds?" Redhat does, and so does one other. I don't remember which, but based on Alan's post, it's probably Mandrake. In addition, based on driver options they support, I think ATI's closed-source drivers have some sort of TLS support. --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Moving forward with the TLS work
On Wed, Jun 23, 2004 at 10:18:32AM -0600, Brian Paul wrote:
> Ian Romanick wrote:
> >Ian Romanick wrote:
> >
> >>I'm getting back to the TSL work, and I'd like to wrap it up as much
> >>as possible by the end of the week. I sent a patch out of the current
> >>state of things a little bit ago. Performance testing has shown that
> >>the new dispatch functions and the old, non-thread safe dispatch
> >>functions perform equally. The difference between the two is within
> >>the error margin of the test. That's the good news.
> >>
> >>The bad news is that the combination of a multithreaded app, with an
> >>"old" driver, and a "new" libGL will result in a segfault. The code
> >>sets _glapi_Dispatch to NULL in the multithreaded case as a signal to
> >>call _glapi_get_dispatch. When the code is fully converted to TLS,
> >>the call to _glapi_get_dispatch will be replaced with a 'movl
> >>%gs:_gl_DispatchTSD, %eax' or something similar.
> >>
> >>I want to maintain compatibility across the whole matrix of old / new
> >>libGL with old / new drivers. I may be willing to sacrifice new
> >>driver + old libGL, but that's the only combination I'd be willing to
> >>give on. I think we need to do 3 things to get there:
> >>
> >>1. Keep the old meaning of _glapi_Dispatch. This means that all the
> >>_ts_* functions and their support mechanism will have to be kept. :(
> >>However, it will only be needed for the DRI libGL. The software
> >>rendering Mesa version won't need it.
> >
> >
> >This turned out to not be as bad as I thought. There is still the extra
> >dispatch table, but all of the function pointers in it point to the
> >regular dispatch functions. In the multithreaded case, if an old driver
> >does _glapi_Dispatch->Vertex3fv, it will end up calling glVertex3fv,
> >which will see _glapi_DispatchTSD is NULL, which will call
> >_glapi_get_dispatch to get the real dispatch and call the real function.
> >
> >The _ts_* functions are still gone. Everyone is happy. :)
> >
> >The one catch is that glapitemp.h (and the Python generator scripts)
> >were modified. If NAME is not defined, glapitemp.h will not generate
> >the dispatch functions. If DISPATCH_TABLE_NAME is defined, it will
> >still generate the dispatch table.
> >
> >>2. For non-TLS "new" code, implement a new variable called
> >>_glapi_DispatchTSD that implements the new behavior. There will be a
> >>"weak" version of that variable, that is always NULL in dri_util.c.
> >>This should allow non-TLS "new" code to work with old libGL binaries.
> >
> >
> >This is done and works perfectly. The only problem *I* have with it is
> >the use of a GCC specific feature. Of course, the whole TLS thing is
> >pretty GCC specific, so I guess this is somewhat moot.
> >
> >>3. TLS "new" code can do whatever it wants. I imagine this will be a
> >>__thread variable called _glapi_tls_Dispatch or something similar.
> >
> >
> >This part isn't done yet, but should be easy enough.
> >
> >This patch also still requires you to manually generate glapi_x86.S by
> >doing:
> >
> >cd src/mesa/glapi
> >python2 ./gl_x86_asm.py > ../x86/glapi_x86.S
> >
> >The other new thing in this patch is the state variable ThreadSafe is
> >gone. Instead, the code universally uses "_glapi_DispatchTSD == NULL"
> >to determine if it is in multi-threaded mode. Some other code in
> >glapi.c changes as a direct result.
> >
> >If nobody raises any concerns, my intention is to commit these changes
> >*tomorrow* afternoon (23-June-2004).
> >
> >The next two steps will be to start adding in some of the
> >'visibility("hidden")' stuff and (of course) the TLS support. I plan to
> >mostly follow Jakub's lead with two exceptions. Instead of using
> >'hidden' as the macro for '__attribute__ ((visibility("hidden"))', I'm
> >going to take a cue from the PowerPC glibc code and use
> >attribute_hidden. I'm also going to pick a different name than
> >GLX_USE_TLS to enable compilation of the TLS code. I haven't decide
> >what to use, though.
>
> Ian, I haven't had time to follow this too closely. A few questions:
>
> 1. Is thread safety in the GL API layer going to require TLS now?
> What about people who want thread safety but aren't using a version of
> Linux that supports TLS?
>
> 2. Which common Linux distros support TLS? I believe RH9 and later
> do, but that's all I'm aware of.
I think Mandrake 10 also supports it.
Alan.
---
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Moving forward with the TLS work
Ian Romanick wrote:
Ian Romanick wrote:
I'm getting back to the TSL work, and I'd like to wrap it up as much
as possible by the end of the week. I sent a patch out of the current
state of things a little bit ago. Performance testing has shown that
the new dispatch functions and the old, non-thread safe dispatch
functions perform equally. The difference between the two is within
the error margin of the test. That's the good news.
The bad news is that the combination of a multithreaded app, with an
"old" driver, and a "new" libGL will result in a segfault. The code
sets _glapi_Dispatch to NULL in the multithreaded case as a signal to
call _glapi_get_dispatch. When the code is fully converted to TLS,
the call to _glapi_get_dispatch will be replaced with a 'movl
%gs:_gl_DispatchTSD, %eax' or something similar.
I want to maintain compatibility across the whole matrix of old / new
libGL with old / new drivers. I may be willing to sacrifice new
driver + old libGL, but that's the only combination I'd be willing to
give on. I think we need to do 3 things to get there:
1. Keep the old meaning of _glapi_Dispatch. This means that all the
_ts_* functions and their support mechanism will have to be kept. :(
However, it will only be needed for the DRI libGL. The software
rendering Mesa version won't need it.
This turned out to not be as bad as I thought. There is still the extra
dispatch table, but all of the function pointers in it point to the
regular dispatch functions. In the multithreaded case, if an old driver
does _glapi_Dispatch->Vertex3fv, it will end up calling glVertex3fv,
which will see _glapi_DispatchTSD is NULL, which will call
_glapi_get_dispatch to get the real dispatch and call the real function.
The _ts_* functions are still gone. Everyone is happy. :)
The one catch is that glapitemp.h (and the Python generator scripts)
were modified. If NAME is not defined, glapitemp.h will not generate
the dispatch functions. If DISPATCH_TABLE_NAME is defined, it will
still generate the dispatch table.
2. For non-TLS "new" code, implement a new variable called
_glapi_DispatchTSD that implements the new behavior. There will be a
"weak" version of that variable, that is always NULL in dri_util.c.
This should allow non-TLS "new" code to work with old libGL binaries.
This is done and works perfectly. The only problem *I* have with it is
the use of a GCC specific feature. Of course, the whole TLS thing is
pretty GCC specific, so I guess this is somewhat moot.
3. TLS "new" code can do whatever it wants. I imagine this will be a
__thread variable called _glapi_tls_Dispatch or something similar.
This part isn't done yet, but should be easy enough.
This patch also still requires you to manually generate glapi_x86.S by
doing:
cd src/mesa/glapi
python2 ./gl_x86_asm.py > ../x86/glapi_x86.S
The other new thing in this patch is the state variable ThreadSafe is
gone. Instead, the code universally uses "_glapi_DispatchTSD == NULL"
to determine if it is in multi-threaded mode. Some other code in
glapi.c changes as a direct result.
If nobody raises any concerns, my intention is to commit these changes
*tomorrow* afternoon (23-June-2004).
The next two steps will be to start adding in some of the
'visibility("hidden")' stuff and (of course) the TLS support. I plan to
mostly follow Jakub's lead with two exceptions. Instead of using
'hidden' as the macro for '__attribute__ ((visibility("hidden"))', I'm
going to take a cue from the PowerPC glibc code and use
attribute_hidden. I'm also going to pick a different name than
GLX_USE_TLS to enable compilation of the TLS code. I haven't decide
what to use, though.
Ian, I haven't had time to follow this too closely. A few questions:
1. Is thread safety in the GL API layer going to require TLS now?
What about people who want thread safety but aren't using a version of
Linux that supports TLS?
2. Which common Linux distros support TLS? I believe RH9 and later
do, but that's all I'm aware of.
-Brian
---
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Moving forward with the TLS work
Ian Romanick wrote:
I'm getting back to the TSL work, and I'd like to wrap it up as much as
possible by the end of the week. I sent a patch out of the current
state of things a little bit ago. Performance testing has shown that
the new dispatch functions and the old, non-thread safe dispatch
functions perform equally. The difference between the two is within the
error margin of the test. That's the good news.
The bad news is that the combination of a multithreaded app, with an
"old" driver, and a "new" libGL will result in a segfault. The code
sets _glapi_Dispatch to NULL in the multithreaded case as a signal to
call _glapi_get_dispatch. When the code is fully converted to TLS, the
call to _glapi_get_dispatch will be replaced with a 'movl
%gs:_gl_DispatchTSD, %eax' or something similar.
I want to maintain compatibility across the whole matrix of old / new
libGL with old / new drivers. I may be willing to sacrifice new driver
+ old libGL, but that's the only combination I'd be willing to give on.
I think we need to do 3 things to get there:
1. Keep the old meaning of _glapi_Dispatch. This means that all the
_ts_* functions and their support mechanism will have to be kept. :(
However, it will only be needed for the DRI libGL. The software
rendering Mesa version won't need it.
This turned out to not be as bad as I thought. There is still the extra
dispatch table, but all of the function pointers in it point to the
regular dispatch functions. In the multithreaded case, if an old driver
does _glapi_Dispatch->Vertex3fv, it will end up calling glVertex3fv,
which will see _glapi_DispatchTSD is NULL, which will call
_glapi_get_dispatch to get the real dispatch and call the real function.
The _ts_* functions are still gone. Everyone is happy. :)
The one catch is that glapitemp.h (and the Python generator scripts)
were modified. If NAME is not defined, glapitemp.h will not generate
the dispatch functions. If DISPATCH_TABLE_NAME is defined, it will
still generate the dispatch table.
2. For non-TLS "new" code, implement a new variable called
_glapi_DispatchTSD that implements the new behavior. There will be a
"weak" version of that variable, that is always NULL in dri_util.c. This
should allow non-TLS "new" code to work with old libGL binaries.
This is done and works perfectly. The only problem *I* have with it is
the use of a GCC specific feature. Of course, the whole TLS thing is
pretty GCC specific, so I guess this is somewhat moot.
3. TLS "new" code can do whatever it wants. I imagine this will be a
__thread variable called _glapi_tls_Dispatch or something similar.
This part isn't done yet, but should be easy enough.
This patch also still requires you to manually generate glapi_x86.S by
doing:
cd src/mesa/glapi
python2 ./gl_x86_asm.py > ../x86/glapi_x86.S
The other new thing in this patch is the state variable ThreadSafe is
gone. Instead, the code universally uses "_glapi_DispatchTSD == NULL"
to determine if it is in multi-threaded mode. Some other code in
glapi.c changes as a direct result.
If nobody raises any concerns, my intention is to commit these changes
*tomorrow* afternoon (23-June-2004).
The next two steps will be to start adding in some of the
'visibility("hidden")' stuff and (of course) the TLS support. I plan to
mostly follow Jakub's lead with two exceptions. Instead of using
'hidden' as the macro for '__attribute__ ((visibility("hidden"))', I'm
going to take a cue from the PowerPC glibc code and use
attribute_hidden. I'm also going to pick a different name than
GLX_USE_TLS to enable compilation of the TLS code. I haven't decide
what to use, though.
Index: src/mesa/drivers/dri/common/dri_util.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/common/dri_util.c,v
retrieving revision 1.11
diff -u -d -r1.11 dri_util.c
--- src/mesa/drivers/dri/common/dri_util.c 7 Jun 2004 21:23:12 - 1.11
+++ src/mesa/drivers/dri/common/dri_util.c 22 Jun 2004 23:32:48 -
@@ -55,6 +55,10 @@
#endif
/**
+ */
+struct _glapi_table *_glapi_DispatchTSD __attribute__((weak)) = NULL;
+
+/**
* This is used in a couple of places that call \c driCreateNewDrawable.
*/
static const int empty_attribute_list[1] = { None };
Index: src/mesa/glapi/gl_apitemp.py
===
RCS file: /cvs/mesa/Mesa/src/mesa/glapi/gl_apitemp.py,v
retrieving revision 1.2
diff -u -d -r1.2 gl_apitemp.py
--- src/mesa/glapi/gl_apitemp.py19 May 2004 23:33:08 - 1.2
+++ src/mesa/glapi/gl_apitemp.py22 Jun 2004 23:32:48 -
@@ -112,6 +112,7 @@
*/
+#if defined( NAME )
#ifndef KEYWORD1
#define KEYWORD1
#endif
@@ -120,10 +121,6 @@
#define KEYWORD2
#endif
-#ifndef NAME
-#error NAME must be defined
-#endif
-
#ifndef DISPATCH
#error DISPATCH must be defined
#endif
@@ -140,6 +137,7 @@
def printInitD
Moving forward with the TLS work
I'm getting back to the TSL work, and I'd like to wrap it up as much as possible by the end of the week. I sent a patch out of the current state of things a little bit ago. Performance testing has shown that the new dispatch functions and the old, non-thread safe dispatch functions perform equally. The difference between the two is within the error margin of the test. That's the good news. The bad news is that the combination of a multithreaded app, with an "old" driver, and a "new" libGL will result in a segfault. The code sets _glapi_Dispatch to NULL in the multithreaded case as a signal to call _glapi_get_dispatch. When the code is fully converted to TLS, the call to _glapi_get_dispatch will be replaced with a 'movl %gs:_gl_DispatchTSD, %eax' or something similar. I want to maintain compatibility across the whole matrix of old / new libGL with old / new drivers. I may be willing to sacrifice new driver + old libGL, but that's the only combination I'd be willing to give on. I think we need to do 3 things to get there: 1. Keep the old meaning of _glapi_Dispatch. This means that all the _ts_* functions and their support mechanism will have to be kept. :( However, it will only be needed for the DRI libGL. The software rendering Mesa version won't need it. 2. For non-TLS "new" code, implement a new variable called _glapi_DispatchTSD that implements the new behavior. There will be a "weak" version of that variable, that is always NULL in dri_util.c. This should allow non-TLS "new" code to work with old libGL binaries. 3. TLS "new" code can do whatever it wants. I imagine this will be a __thread variable called _glapi_tls_Dispatch or something similar. That /should/ allow support of all 4 non-TLS combinations and allow the TLS libGL to work with non-TLS drivers. However, this will defeat some of the size and linkage (prelink, etc.) benefits of the non-compatible version. I'll see if I can work something up and send out a new patch tomorrow. --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
