Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
magenta wrote: On Tue, Jan 07, 2003 at 03:00:10PM -0700, Jens Owen wrote: Michel Daenzer wrote: This doesn't help mixed OpenGL and X11 rendering in the same window, but that supposedly doesn't work with the traditional method of drawing to the back buffer and then copying it over the front buffer either, so enable page flipping by default. I'm a little confused here. By traditional method are you referring to not using page flipping? What doesn't work in that method? I thought that the glX spec said that mixing X11 and OpenGL within a single drawable wasn't guaranteed anyway, and only gave hints about things that might or might not work on certain implementations. AFAIK the rendering is guaranteed. GLX Version 1.3, Section 2.2, Paragraphs 3 & 4 gives a good description of how the X and OpenGL rendering pipelines are expected to interact: Issuing OpenGL commands may cause the X buffer to be flushed, In particular, calling glFlush when indirect rendering is occuring, will flush both the X and OpenGL rendering streams. Some state is shared between the OpenGL and X. The pixel values in the X frame buffer are shared. The X double buffer extension (DBE) has a definition for which buffer is currently the displayed buffer. This information is shared with GLX. The state of which buffer is displayed tracks in both extensions, independent of which extension initiates a buffer swap. There is a description of the synchronization expectations in Section 2.7, paragraph 5: Synchronization is in the hands of the client. If can be maintained with moderate cost with the judicious use of the glFinish, glXWaitGL, glXWaitX, and XSync commands. OpenGL and X rendering can be done in parallel as long as the client does not preclude it with explicit synchronization calls. This is true even when the rendering is being done by the X server. and again in Section 3.3.10, paragraph 3: All GLX rendering context share the same notion of which are front buffers and which are back buffers for a given drawable. This notion is also shared with the X double buffer extension (DBE). This last section really tweaked my memory. I had forgotten, but indirect rendering in our "traditional" implementation isn't compliant. For indirect contexts, we're not sharing the contents of the back buffer with direct rendering contexts. There's some real interesting work that still needs to be done for indirect rendering, DBE and page flipping. If anyone's interested in improving this stuff, just speak up. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Keith wrote: Jens wrote: Michel wrote: >>> This doesn't help mixed OpenGL and X11 rendering in the same >>> window, but that supposedly doesn't work with the traditional >>> method of drawing to the back buffer and then copying it over >>> the front buffer either, so enable page flipping by default. >> What "clobbering" is allowed can be inferred from the GLX specification. If you overlook DBE for a second, I believe we are meeting the requirements of the spec, so I wouldn't say we're "broken". This isn't true. I'll clarify my statement...the traditional non-page flipping code is not broken. Consider when a diagonal line is drawn by Xlib across the active GL window, with pages flipped. --> Xlib draws in the "back buffer" It's my interpretation that this step alone doesn't comply with the GLX spec for the page flipping case, but it does work with the traditional code. Assuming the active GL window is double buffered, the X server should render to *only* the front buffer (unless DBE is being used). --> Shadow copies the bounding box of the line to the front buffer, including *all* of the backbuffer. What you really want is just a line to be drawn in the front buffer, but in fact you get a whole lot of garbage with it. Right. Just a line in the front buffer and no rendering in the back buffer (for the double buffered GLX window). A common place things like this occur is in opaque window moves -- if you move the 3d window when pages are flipped, its contents are replaced with whatever's in the backbuffer. A solution to this is to get Xlib and GL to agree which is the front buffer and always have Xlib draw into that & copy to the backbuffer. I'll add that we should only copy to the backbuffer if it's not being used by OpenGL or DBE as a double buffered window. Based on Keith's insights and other follow ups to this thread, it looks like there is more work to be done before page flipping will work correctly. Michel, I suggest you turn off page flipping by default until these issues are resolved. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] trunk (r200): status on SMP system
During the Mesa CPU detection code testing I have stopped and restarted X (the new version) from time to time. After some (two or three) X restarts my system (dual Athlon MP) hangs. Sometimes I could kill the current WM (KDE) session with SYSRQ+k, turn the FS into a save state (SYSRQ+S|U) but sometimes only SYSRQ+b or a RESET brought it back to live. I've checked with 32 and 64 MB of AGP memory. Here comes what's in the logs: Jan 9 03:10:43 SunWave1 kernel: SysRq : Emergency Sync Jan 9 03:10:43 SunWave1 kernel: Syncing device 08:03 ... OK Jan 9 03:10:43 SunWave1 kernel: Syncing device 08:02 ... OK Jan 9 03:10:43 SunWave1 kernel: Syncing device 08:05 ... OK Jan 9 03:10:43 SunWave1 kernel: Syncing device 08:06 ... OK Jan 9 03:10:43 SunWave1 kernel: Syncing device 08:07 ... OK Jan 9 03:10:43 SunWave1 kernel: Syncing device 08:08 ... OK Jan 9 03:10:43 SunWave1 kernel: Syncing device 08:11 ... OK Jan 9 03:10:43 SunWave1 kernel: Syncing device 08:15 ... OK Jan 9 03:10:43 SunWave1 kernel: Syncing device 08:16 ... OK Jan 9 03:10:43 SunWave1 kernel: Syncing device 08:17 ... OK Jan 9 03:10:43 SunWave1 kernel: Syncing device 08:18 ... OK Jan 9 03:10:43 SunWave1 kernel: Done. Jan 9 03:10:43 SunWave1 kernel: SysRq : SAK Jan 9 03:10:43 SunWave1 kdm[3149]: Server for display :0 terminated unexpectedly Jan 9 03:10:43 SunWave1 kernel: [drm:radeon_ioremapfree:mappings] *ERROR* Attempt to free NULL pointer Jan 9 03:10:43 SunWave1 kernel: [drm:radeon_ioremapfree:mappings] *ERROR* Excess frees: 5 frees, 4 allocs Jan 9 03:10:44 SunWave1 kernel: [drm] Loading R200 Microcode Jan 9 03:11:03 SunWave1 kdm[27497]: fatal IO error 32 (Broken pipe) Jan 9 03:11:03 SunWave1 kernel: [drm:radeon_ioremapfree:mappings] *ERROR* Excess frees: 9 frees, 8 allocs Jan 9 03:11:03 SunWave1 kernel: [drm:radeon_ioremapfree:mappings] *ERROR* Attempt to free NULL pointer Jan 9 03:11:03 SunWave1 kernel: [drm:radeon_ioremapfree:mappings] *ERROR* Excess frees: 10 frees, 8 allocs Jan 9 03:11:06 SunWave1 kernel: SysRq : Emergency Sync Jan 9 03:11:06 SunWave1 kernel: Syncing device 08:03 ... OK Jan 9 03:11:06 SunWave1 kernel: Syncing device 08:02 ... OK Jan 9 03:11:06 SunWave1 kernel: Syncing device 08:05 ... OK Jan 9 03:11:06 SunWave1 kernel: Syncing device 08:06 ... OK Jan 9 03:11:06 SunWave1 kernel: Syncing device 08:07 ... OK Jan 9 03:11:06 SunWave1 kernel: Syncing device 08:08 ... OK Jan 9 03:11:06 SunWave1 kernel: Syncing device 08:11 ... OK Jan 9 03:11:06 SunWave1 kernel: Syncing device 08:15 ... OK Jan 9 03:11:06 SunWave1 kernel: Syncing device 08:16 ... OK Jan 9 03:11:06 SunWave1 kernel: Syncing device 08:17 ... OK Jan 9 03:11:06 SunWave1 kernel: Syncing device 08:18 ... OK Jan 9 03:11:06 SunWave1 kernel: Done. TimeRenderer2 (VTK demo app) hangs X with a debug message like this (only from memory): r200: loading (second?) DMA buffer (or engine?) Normally it should look like this: VTK/bin> ./TimeRenderer r200AgeTextures 0 r200AgeTextures 1 Wall Time = -1.99143<--- what's that? FrameRate = -60.2583 VTK/bin> ./TimeRenderer r200AgeTextures 0 r200AgeTextures 1 Wall Time = 0.699078 FrameRate = 171.655 VTK/bin> ./TimeRenderer2 r200AgeTextures 0 r200AgeTextures 1 Wall Time = 0.979248 FrameRate = 122.543 TriRate = 9.80344e+06 Another VTK app (multi threaded, two 3D contexts) hangs or sigfaults: VTK/bin> ./TaskParallelism libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r200_dri.so libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0) libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0) drmOpenByBusid: busid is PCI:1:5:0 drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenByBusid: drmOpenMinor returns 6 drmOpenByBusid: drmGetBusid reports PCI:1:5:0 r200AgeTextures 0 r200AgeTextures 1 libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0) libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0) drmOpenByBusid: busid is PCI:1:5:0 drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: drmOpenMinor returns 8 drmOpenByBusid: drmGetBusid reports PCI:1:5:0 r200AgeTextures 0 r200AgeTextures 1 TaskParallelism: r200_vtxfmt.c:945: r200FlushVertices: Assertion `vb.context == ctx' failed. Abbruch (core dumped) Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2...done. Loaded symbols for /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 Reading symbols from /usr/X11R6/lib/modules/dri/r200_dri.so...done. Loaded symbols for /usr/X11R6/lib/modules/dri/r200_dri.so #0 0x413e6701 in kill () from /lib/libc.so.6 (gdb) bt #0 0x413e6701 in kill () from /lib/libc.so.6 #1 0x4128e89a in pthread_kill () from /lib/libpthread.so.0 #2 0x4128ed92 in raise () from /lib/libpthread.so.0 #3 0x413e7a23 in abort () from /lib/libc.so.6 #4 0x413e10ea in __assert_fail () from
[Dri-devel] Mesa CPU detection code
Am Dienstag, 31. Dezember 2002 04:20 schrieb Petr Sebor:
> Hi,
>
> I have recently rewritten the Mesa CPU detection code and
> would like someone else to give it a try.
>
> Basically, the highlights are:
>
> - added _mesa_x86_has_cpuid
> - added _mesa_x86_cpuid
> - added _mesa_x86_cpuid_eax
> - added _mesa_x86_cpuid_ebx
> - added _mesa_x86_cpuid_ecx
> - added _mesa_x86_cpuid_edx
> - removed _mesa_identify_x86_cpu_features
> - differentiated extended cpu features (in ..x86_features.h)
> from the std ones
> - changed the X86_FEATURE semantics a little bit
>
> with these tools, I am trying to parse the cpu feature while
> making distinction between the normal and extended cpu
> feature sets - no need to query the cpu vendor string, while
> making the code highly readable for people not familiar with
> the assembly langugage.
>
> Please consider applying...
I vote for it.
Petr, with your cleanup and Linus asm fix MesaCVS (5.1) works without a glitch
for me. Next I'll try it with the DRI CVS trunk.
Done.
Works fine.
Mesa/demos> ./glinfo
cpu vendor: AuthenticAMD
cpu name: AMD Athlon(tm) MP 1900+
MMX cpu detected.
3DNow! cpu detected.
Testing OS support for SSE... yes.
Testing OS support for SSE unmasked exceptions... SIGFPE, yes.
Tests of OS support for SSE passed.
SSE cpu detected.
r200AgeTextures 0
r200AgeTextures 1
GL_VERSION: 1.2 Mesa 5.0
GL_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_texture_mirrored_repeat
GL_ARB_transpose_matrix GL_ARB_window_pos GL_ATI_texture_mirror_once
GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_logic_op
GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint
GL_EXT_convolution GL_EXT_compiled_vertex_array GL_EXT_histogram
GL_EXT_packed_pixels GL_EXT_polygon_offset GL_EXT_rescale_normal
GL_EXT_secondary_color GL_EXT_stencil_wrap 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_filter_anisotropic
GL_EXT_texture_object GL_EXT_texture_lod_bias GL_EXT_vertex_array
GL_IBM_rasterpos_clip GL_MESA_pack_invert GL_MESA_ycbcr_texture
GL_MESA_window_pos GL_NV_texture_rectangle GL_NV_texgen_reflection
GL_SGI_color_matrix GL_SGI_color_table
GL_RENDERER: Mesa DRI R200 20021125 AGP 4x x86/MMX/3DNow!/SSE TCL
GL_VENDOR: Tungsten Graphics, Inc.
GLU_VERSION: 1.3
GLU_EXTENSIONS: GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess
GLUT_API_VERSION: 5
GLUT_XLIB_IMPLEMENTATION: 15
Thank you!
Dieter
Index: common_x86.c
===
RCS file: /cvsroot/mesa3d/Mesa/src/X86/common_x86.c,v
retrieving revision 1.20
diff -u -r1.20 common_x86.c
--- common_x86.c 13 Nov 2002 15:03:31 - 1.20
+++ common_x86.c 31 Dec 2002 03:02:45 -
@@ -52,8 +52,14 @@
/* No reason for this to be public.
*/
-extern int _mesa_identify_x86_cpu_features( void );
+extern int _mesa_identify_x86_cpu_features(void);
+extern GLuint _mesa_x86_has_cpuid(void);
+extern void _mesa_x86_cpuid(GLuint op, GLuint *reg_eax, GLuint *reg_ebx, GLuint *reg_ecx, GLuint *reg_edx);
+extern GLuint _mesa_x86_cpuid_eax(GLuint op);
+extern GLuint _mesa_x86_cpuid_ebx(GLuint op);
+extern GLuint _mesa_x86_cpuid_ecx(GLuint op);
+extern GLuint _mesa_x86_cpuid_edx(GLuint op);
static void message( const char *msg )
{
@@ -240,8 +246,84 @@
{
(void) message; /* silence warning */
#ifdef USE_X86_ASM
- _mesa_x86_cpu_features = _mesa_identify_x86_cpu_features();
+ _mesa_x86_cpu_features = 0;
+ if (!_mesa_x86_has_cpuid()) {
+ message("CPUID not detected");
+ }
+ else {
+ GLuint cpu_features;
+ GLuint cpu_ext_features;
+ GLuint cpu_ext_info;
+ char cpu_vendor[13];
+ GLuint result;
+
+ /* get vendor name */
+ _mesa_x86_cpuid(0, &result, (GLuint *)(cpu_vendor + 0), (GLuint *)(cpu_vendor + 8), (GLuint *)(cpu_vendor + 4));
+ cpu_vendor[12] = '\0';
+
+ message("cpu vendor: ");
+ message(cpu_vendor);
+ message("\n");
+
+ /* get cpu features */
+ cpu_features = _mesa_x86_cpuid_edx(1);
+
+ if (cpu_features & X86_CPU_FPU)
+ _mesa_x86_cpu_features |= X86_FEATURE_FPU;
+ if (cpu_features & X86_CPU_CMOV)
+ _mesa_x86_cpu_features |= X86_FEATURE_CMOV;
+
+#ifdef USE_MMX_ASM
+ if (cpu_features & X86_CPU_MMX)
+ _mesa_x86_cpu_features |= X86_FEATURE_MMX;
+#endif
+
+#ifdef USE_SSE_ASM
+ if (cpu_features & X86_CPU_XMM)
+ _mesa_x86_cpu_features |= X86_FEATURE_XMM;
+ if (cpu_features & X86_CPU_XMM2)
+ _mesa_x86_cpu_features |= X86_FEATURE_XMM2;
+#endif
+
+ /* query extended cpu features */
+ if ((cpu_ext_info = _mesa_x86_cpuid_eax(0x8000)) > 0x8000) {
+ if (cpu_ext_info >= 0x8001) {
+
+ cpu_ext_features = _mesa_x86_cpuid_edx(0x8001);
+
+ if (cpu_features & X86_CPU_MMX) {
+
+#
Re: [Dri-devel] Mesa SIGSEGV's due to broken common_x86_asm.S
Am Mittwoch, 8. Januar 2003 22:27 schrieb Linus Torvalds: > Grr. Double-grr. That assembly-language is written in some unreadable > syntax anyway, but here's a totally untested diff that may fix the crap by > de-allocating the stack only after we're actually _done_ with it. > > I was too lazy to check whether the other asm routines were similarly > broken. Anyway, the rule is: > > YOU MUST NOT USE LOCATIONS ON THE STACK UNDER THE STACK POINTER > > Ok, I feel better now after that rant. Sorry, You are a hero! As always you made my day. I've tested it with DRI CVS trunk and MesaCVS (5.1) on my dual Athlon MP. All FPU sigfaults are fixed. Ugh, if I only could understand x86 asm somewhat better. I've learned on 68k...;-) Any pointers how I can solve such problems next time for my self? How did you do it? Now, Petr have some "cleanups/speedups" handy. I'll give them a try. Regards and thank you very much. -Dieter PS One obstacle fewer to get Mesa 5.0 into XFree CVS (4.3.0). PPS What about the texmem branch? > - > Index: common_x86_asm.S > === > RCS file: /cvsroot/dri/xc/xc/extras/Mesa/src/X86/common_x86_asm.S,v > retrieving revision 1.16 > diff -u -r1.16 common_x86_asm.S > --- common_x86_asm.S 25 Nov 2002 19:57:08 - 1.16 > +++ common_x86_asm.S 8 Jan 2003 21:27:57 - > @@ -225,13 +225,13 @@ > > MOVUPS ( REGIND( ESP ), XMM1 ) > > - ADD_L ( CONST( 32 ), ESP ) > - > DIVPS ( XMM0, XMM1 ) > > /* Restore the original MXCSR register value. >*/ > LDMXCSR ( REGOFF( -4, EBP ) ) > + > + ADD_L ( CONST( 32 ), ESP ) > > LEAVE > RET --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mesa SIGSEGV's due to broken common_x86_asm.S
Ok, I'm a bit bitter, because I just spent a long time chasing down a kernel bug that didn't turn out to be a kernel bug at all. I started seeing that strange SIGSEGV with programs that use dri, and it happened right after the SIGFPE that tested for XMM support. As it happens, I've done some signal delivery changes in the kernel lately, so I blamed myself. It wasn't my fault. That frigging Mesa assembly-code is broken. In particular, it undoes the whole stack frame _before_ it does the divide-by-zero thing, yet it still has stuff in the local frame. Signal delivery will overwrite the local frame if the stack is aligned just the right way, and as a result the LDMXCSR that follows the DIVPS will load crap into MXCSR. And the crap it loads may well cause a SIGSEGV due to a GP-fault by the CPU. Grr. Double-grr. That assembly-language is written in some unreadable syntax anyway, but here's a totally untested diff that may fix the crap by de-allocating the stack only after we're actually _done_ with it. I was too lazy to check whether the other asm routines were similarly broken. Anyway, the rule is: YOU MUST NOT USE LOCATIONS ON THE STACK UNDER THE STACK POINTER Ok, I feel better now after that rant. Sorry, Linus - Index: common_x86_asm.S === RCS file: /cvsroot/dri/xc/xc/extras/Mesa/src/X86/common_x86_asm.S,v retrieving revision 1.16 diff -u -r1.16 common_x86_asm.S --- common_x86_asm.S25 Nov 2002 19:57:08 - 1.16 +++ common_x86_asm.S8 Jan 2003 21:27:57 - @@ -225,13 +225,13 @@ MOVUPS ( REGIND( ESP ), XMM1 ) - ADD_L ( CONST( 32 ), ESP ) - DIVPS ( XMM0, XMM1 ) /* Restore the original MXCSR register value. */ LDMXCSR ( REGOFF( -4, EBP ) ) + + ADD_L ( CONST( 32 ), ESP ) LEAVE RET --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Am Mittwoch, 8. Januar 2003 16:09 schrieb Michel Dänzer: > [ Why don't you CC: dri-devel? ] Because of the included image. Sorry for the double post, forgotten dri-devel in the first one, again. > On Mit, 2003-01-08 at 02:40, Dieter Nützel wrote: > > On Die, 2003-01-07 at 22:35, Michel Daenzer wrote: > > > On Die, 2003-01-07 at 23:00, Jens Owen wrote: > > > > Michel Daenzer wrote: > > > > > CVSROOT:/cvsroot/dri > > > > > Module name:xc > > > > > Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/ > > > > > Changes by: mdaenzer@sc8-pr-cvs1. 03/01/07 13:21:52 > > > > > > > > > > Log message: > > > > > Use shadowfb instead of mi shadow to fix 2D corruption when page > > > > > flipping is enabled. > > [...] > > > Now I get a little texture corruption in the Q3A menue (see screen shot). > > That doesn't happen if you revert this change? Ugh, after switching the machine on today it is _gone_. Additional CON: The mouse _works_ again in Q3A! Found that yesterday too but have forgotten to mention. > > The intro and cinematic stuttering and then end (intro) and stop > > (cinematic). I have to press the ESC key to stop/reset the cinematic. > > I don't follow here, sorry. OK. After the stuttering in Q3A I got the below in the log file: Q3A 1.32: Sys_QueEvent: overflow And here comes the UT output: UT 436: dri-trunk/xc> ut& [1] 11085 dri-trunk/xc> r200AgeTextures 0 r200AgeTextures 1 fcntl: Invalid argument fcntl: Invalid argument [1]Fertigut What does the fcntl thing mean? Good work as far as I can see! -Dieter --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Getting current vsync rate from within libGL.so?
On Mit, 2003-01-08 at 02:24, Ian Romanick wrote: > > My next try was to use the XVidMode extension (based on xvidtune.c). > This was somewhat problematic until I realized that I had to make > libGL.so link with libXxf86vm.a. Is this a good idea? The only other > libraries that libGL is linked with are "core" libraries (libm, libX11, > libc, etc.). Is it okay for libGL to use an XFree86 extension? One potential problem I see is that libXxf86vm.a may not be built with -fPIC, and mixing code built with and without that can cause problems on most architectures except i386. But then IIRC libGL isn't built with -fPIC, and I think this is finally getting tackled in XFree86, so this may not be an issue at all. Just something to keep in mind. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Was this addressed - ATI_texture_env_combine3
FWIW, all the lack of support for this extension causes is shiny stuff being displayed incorrectly. I changed our code to disable specular if this extension isn't present so things will look better in the next patch though it were nice if the functionality made it into DRI. I doubt flickering triangles are related to this. -- Daniel, Epic Games Inc. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Frank > Jacobberger > Sent: Wednesday, January 08, 2003 1:12 AM > To: [EMAIL PROTECTED] > Subject: [Dri-devel] Was this addressed - ATI_texture_env_combine3 > > > The following is missing from the r200 driver: > > ATI_texture_env_combine3 > > Hence when trying to play ut2k3, all I see when playing is > colliding triangles?? > > When will ATI_texture_env_combine3 be added? > > Thanks, > > Frank > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Am Mittwoch, 8. Januar 2003 17:46 schrieb Keith Whitwell: > Dieter Nützel wrote: > > Am Mittwoch, 8. Januar 2003 17:04 schrieb Keith Whitwell: > >>>What "clobbering" is allowed can be inferred from the GLX specification. > >>> If you overlook DBE for a second, I believe we are meeting the > >>>requirements of the spec, so I wouldn't say we're "broken". > >> > >>This isn't true. > >> > >>Consider when a diagonal line is drawn by Xlib across the active GL > >> window, with pages flipped. > >> > >>--> Xlib draws in the "back buffer" > >>--> Shadow copies the bounding box of the line to the front buffer, > >>including *all* of the backbuffer. > >> > >>What you really want is just a line to be drawn in the front buffer, but > >> in fact you get a whole lot of garbage with it. > >> > >>A common place things like this occur is in opaque window moves -- if you > >>move the 3d window when pages are flipped, its contents are replaced with > >>whatever's in the backbuffer. > >> > >>A solution to this is to get Xlib and GL to agree which is the front > >> buffer and always have Xlib draw into that & copy to the backbuffer. > > > > Then this must be the culprit for the massive 3D window flickring (mixing > > front and back buffer, but only when textures are involved, ipers but not > > gears) when I move the window around? > > Yes, though nothing to do with textures -- gears is just too fast to see it > flickering, whereas ipers is quite slow. Gears is fast but not as fast as before on my dual Athlon SMP like several other 3D apps. Some interference with the great new native AMD 76x power management stuff. I have to disable it for further testing. U160: 2376 RPM (min = 1500 RPM, div = 4) CPU 0:4115 RPM (min = 3000 RPM, div = 2) CPU 1:4090 RPM (min = 3000 RPM, div = 2) System: +28.0°C (limit = +40°C, hysteresis = +37°C) sensor = thermistor CPU 1:+20.5°C (limit = +52°C, hysteresis = +47°C) sensor = 3904 transistor CPU 0:+23.5°C (limit = +52°C, hysteresis = +47°C) sensor = 3904 transistor -Dieter --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Dieter Nützel wrote: Am Mittwoch, 8. Januar 2003 17:04 schrieb Keith Whitwell: What "clobbering" is allowed can be inferred from the GLX specification. If you overlook DBE for a second, I believe we are meeting the requirements of the spec, so I wouldn't say we're "broken". This isn't true. Consider when a diagonal line is drawn by Xlib across the active GL window, with pages flipped. --> Xlib draws in the "back buffer" --> Shadow copies the bounding box of the line to the front buffer, including *all* of the backbuffer. What you really want is just a line to be drawn in the front buffer, but in fact you get a whole lot of garbage with it. A common place things like this occur is in opaque window moves -- if you move the 3d window when pages are flipped, its contents are replaced with whatever's in the backbuffer. A solution to this is to get Xlib and GL to agree which is the front buffer and always have Xlib draw into that & copy to the backbuffer. Then this must be the culprit for the massive 3D window flickring (mixing front and back buffer, but only when textures are involved, ipers but not gears) when I move the window around? Yes, though nothing to do with textures -- gears is just too fast to see it flickering, whereas ipers is quite slow. Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Am Mittwoch, 8. Januar 2003 17:04 schrieb Keith Whitwell: > > What "clobbering" is allowed can be inferred from the GLX specification. > > If you overlook DBE for a second, I believe we are meeting the > > requirements of the spec, so I wouldn't say we're "broken". > > This isn't true. > > Consider when a diagonal line is drawn by Xlib across the active GL window, > with pages flipped. > > --> Xlib draws in the "back buffer" > --> Shadow copies the bounding box of the line to the front buffer, > including *all* of the backbuffer. > > What you really want is just a line to be drawn in the front buffer, but in > fact you get a whole lot of garbage with it. > > A common place things like this occur is in opaque window moves -- if you > move the 3d window when pages are flipped, its contents are replaced with > whatever's in the backbuffer. > > A solution to this is to get Xlib and GL to agree which is the front buffer > and always have Xlib draw into that & copy to the backbuffer. Then this must be the culprit for the massive 3D window flickring (mixing front and back buffer, but only when textures are involved, ipers but not gears) when I move the window around? -Dieter --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Michel Dänzer wrote: On Mit, 2003-01-08 at 17:04, Keith Whitwell wrote: What "clobbering" is allowed can be inferred from the GLX specification. If you overlook DBE for a second, I believe we are meeting the requirements of the spec, so I wouldn't say we're "broken". This isn't true. Consider when a diagonal line is drawn by Xlib across the active GL window, with pages flipped. --> Xlib draws in the "back buffer" --> Shadow copies the bounding box of the line to the front buffer, including *all* of the backbuffer. What you really want is just a line to be drawn in the front buffer, but in fact you get a whole lot of garbage with it. A common place things like this occur is in opaque window moves -- if you move the 3d window when pages are flipped, its contents are replaced with whatever's in the backbuffer. That only affects the 3D window though, right? The problem I'm trying to solve here is the permanent 2D corruption outside the 3D window. It's fixed in my testing, but I may well not have tried hard enough to break it, more testing is always appreciated. As for inside the 3D window, I'd like to know if this breaks things that work without page flipping but are supposed to work. If so, I'll revert page flipping to be disabled by default. Oh, and we still don't exclude the 3D window in the shadowfb copies, do you think that would be any help? It would cover up some of the worst problems - basically the Xlib drawing to a glX window would only show up every second frame... I don't know how many apps mix xlib and glx -- probably not a huge number. Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Mit, 2003-01-08 at 17:04, Keith Whitwell wrote: > > > > What "clobbering" is allowed can be inferred from the GLX specification. > > If you overlook DBE for a second, I believe we are meeting the > > requirements of the spec, so I wouldn't say we're "broken". > > This isn't true. > > Consider when a diagonal line is drawn by Xlib across the active GL window, > with pages flipped. > > --> Xlib draws in the "back buffer" > --> Shadow copies the bounding box of the line to the front buffer, including > *all* of the backbuffer. > > What you really want is just a line to be drawn in the front buffer, but in > fact you get a whole lot of garbage with it. > > A common place things like this occur is in opaque window moves -- if you move > the 3d window when pages are flipped, its contents are replaced with > whatever's in the backbuffer. That only affects the 3D window though, right? The problem I'm trying to solve here is the permanent 2D corruption outside the 3D window. It's fixed in my testing, but I may well not have tried hard enough to break it, more testing is always appreciated. As for inside the 3D window, I'd like to know if this breaks things that work without page flipping but are supposed to work. If so, I'll revert page flipping to be disabled by default. Oh, and we still don't exclude the 3D window in the shadowfb copies, do you think that would be any help? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Is Voodoo1 supported under DRI?
On Wed, Jan 08, 2003 at 11:09:43AM +0100, Raffaele Candeliere wrote: > Does anybody know if is Voodoo1 supported under DRI? It works with Mesa + Glide, not with DRI. Please install Glide for Voodoo Graphics then compile Mesa with V1 support. -- Free Software - find interesting programs and change them NetHack - meet interesting creatures, kill them and eat their bodies Usenet - meet interesting people from all over the world and flame them Decopter - unrealistic helicopter simulator, get it from http://decopter.sf.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
What "clobbering" is allowed can be inferred from the GLX specification. If you overlook DBE for a second, I believe we are meeting the requirements of the spec, so I wouldn't say we're "broken". This isn't true. Consider when a diagonal line is drawn by Xlib across the active GL window, with pages flipped. --> Xlib draws in the "back buffer" --> Shadow copies the bounding box of the line to the front buffer, including *all* of the backbuffer. What you really want is just a line to be drawn in the front buffer, but in fact you get a whole lot of garbage with it. A common place things like this occur is in opaque window moves -- if you move the 3d window when pages are flipped, its contents are replaced with whatever's in the backbuffer. A solution to this is to get Xlib and GL to agree which is the front buffer and always have Xlib draw into that & copy to the backbuffer. Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Michel Dänzer wrote: On Die, 2003-01-07 at 23:00, Jens Owen wrote: Michel Daenzer wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/ Changes by: mdaenzer@sc8-pr-cvs1. 03/01/07 13:21:52 Log message: Use shadowfb instead of mi shadow to fix 2D corruption when page flipping is enabled. Wow, you found the source of the corruption? That's worthy of a posting to dri-devel... True, I posted about it on December 14th and asked for testing, sadly I didn't receive any reports. This doesn't help mixed OpenGL and X11 rendering in the same window, but that supposedly doesn't work with the traditional method of drawing to the back buffer and then copying it over the front buffer either, so enable page flipping by default. I'm a little confused here. By traditional method are you referring to not using page flipping? Yes. What doesn't work in that method? The X server always renders to the front buffer, so when you mix OpenGL and X11 rendering, the former clobbers the latter when rendering to the back buffer. What "clobbering" is allowed can be inferred from the GLX specification. If you overlook DBE for a second, I believe we are meeting the requirements of the spec, so I wouldn't say we're "broken". Now, if you want to include DBE, then the current "traditional" implementation is technically broken. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200 - what can I do to help?
On Wed, Jan 08, 2003 at 03:23:13PM +0100, Martin Spott wrote: > > On Tue, Jan 07, 2003 at 03:48:51PM +0100, Martin Spott wrote: > [...] > >> >> It was like the image that was supposed to be clipped because it was > >> >> hidden became visible briefly as the light went by. It just happens > >> >> briefly and then it is quickly corrected. This is probably not an > >> >> accurate description, but there it is. > >> > >> > Okay... could you set the value of testRender/capt to some directory with > >> > lots of free space and press 'k'? It'll record PPM-format screenshots... > >> > then send the appropriate frame(s) to me, preferrably as PNG or JPG. :) > >> > >> Are you still interested in these ones ? > > > Yeah. > > I put two sequences onto the web server. They are approx. 250 frames each. > Be careful - even converted to PNG these archives are still 19 MByte each. > The filenames should speak for themselves. I included a log of the terminal > output of 'Solace'. BTW, the second one ends with a crash - 'Solace' writes > something like "Radeon timed out" to the terminal: > > http://document.ihg.uni-duisburg.de/bitmap/Radeon/Solace-dlistMax0-draw_method1.tar > >http://document.ihg.uni-duisburg.de/bitmap/Radeon/Solace-dlistMax1024-draw_method1.tar Okay... even on broadband it'll take a while to download these things, but hopefully it'll be worth it. :) > >> This not only cures the artifacts I encountered, this also cures the > >> flickering torus and - as far as I can tell now - it cures the X server > >> crashes with my Radeon7500. Even with GL_draw_method set to 1, > > > Then there's a problem with glArrayElement() in the R200 driver while > > recording a displaylist. > > I'm using the 'radeon' driver for my Radeon7500, not 'r200'. Oh, my bad. Too many people to keep track of. :) It seems that Keith has already extended the isosurf demo to trigger the failure condition, though, so hopefully I can stop pretending to be someone who has any idea what's going on with this. :) -- http://trikuare.cx --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200 - what can I do to help?
On Wed, Jan 08, 2003 at 10:36:10AM +, Keith Whitwell wrote:
>
> >
> > Then there's a problem with glArrayElement() in the R200 driver while
> > recording a displaylist.
> >
> > The specific piece of code that it's running is this (while a displaylist
> > is being recorded in GL_COMPILE_AND_EXECUTE mode):
> >
> > glEnableClientState(GL_VERTEX_ARRAY);
> > glVertexPointer(3, GL_FLOAT, stride, &((*mesh)[0]->pos.x));
> > glEnableClientState(GL_NORMAL_ARRAY);
> > glNormalPointer(GL_FLOAT, stride,
> > &((*mesh)[0]->nrm.x));
> > int p = 0;
> > for (int i = 0; i < h - 1; i++)
> > {
> > glBegin(GL_TRIANGLE_STRIP);
> > for (int j = 0; j < w; j++)
> > {
> > glArrayElement(p);
> > glArrayElement(p + w);
> > p++;
> > }
> > glEnd();
> > }
> >
> > (w and h are set previously, and the nasty pointer math on 'mesh' just
> > gives pointers to the appropriate w*h arrays of vertex data.)
> >
>
>
> The isosurf demo lets you do something like this, but doesn't use
> COMPILE_AND_EXECUTE as it stands.
>
> As it stands, it works fine. If I change it to build the list with
> COMPILE_AND_EXECUTE, the first time (ie when it is being built) it works fine,
> but on subsequent calllists, nothing is rendered.
>
> Does this match what you are seeing?
If it causes a GL_INVALID_ENUM error, then yes, that matches what I see
with both my Radeon 7000 and the binary nVidia drivers (except that the
first few primitives in the displaylist do render). What other people seem
to be experiencing on the r200 driver is that it visits the vertices either
out-of-order or with huge gaps or other weird issues (like, getting offset
by sizeof(float) or whatever).
--
http://trikuare.cx
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200 notes & issues
> On Tue, Jan 07, 2003 at 03:40:09PM +0100, Martin Spott wrote: >> >> http://document.ihg.uni-duisburg.de/bitmap/Radeon/Solace-4.x.png [...] >> > Wow, that's a really cool failure mode... What's your GL_draw_method (in >> > ~/.Solace/registry) set to? Try changing it to 1 or 0... >> >> Yep, this circumvences the bug, > Which one? 1 uses vertex arrays with glArrayElement, 0 uses immediate > mode. (2 uses glDrawElements. [...] Setting GL_draw_method to 0 prevents from drawing these nice artifacts as shown in the picture. Please see my next posting in a few minutes when I managed to upload the 'Carbon Copies' of two Solace-sequences. I'll see what GL_draw_method 2 shows on my display, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200 - what can I do to help?
> On Tue, Jan 07, 2003 at 03:48:51PM +0100, Martin Spott wrote: [...] >> >> It was like the image that was supposed to be clipped because it was >> >> hidden became visible briefly as the light went by. It just happens >> >> briefly and then it is quickly corrected. This is probably not an >> >> accurate description, but there it is. >> >> > Okay... could you set the value of testRender/capt to some directory with >> > lots of free space and press 'k'? It'll record PPM-format screenshots... >> > then send the appropriate frame(s) to me, preferrably as PNG or JPG. :) >> >> Are you still interested in these ones ? > Yeah. I put two sequences onto the web server. They are approx. 250 frames each. Be careful - even converted to PNG these archives are still 19 MByte each. The filenames should speak for themselves. I included a log of the terminal output of 'Solace'. BTW, the second one ends with a crash - 'Solace' writes something like "Radeon timed out" to the terminal: http://document.ihg.uni-duisburg.de/bitmap/Radeon/Solace-dlistMax0-draw_method1.tar http://document.ihg.uni-duisburg.de/bitmap/Radeon/Solace-dlistMax1024-draw_method1.tar >> This not only cures the artifacts I encountered, this also cures the >> flickering torus and - as far as I can tell now - it cures the X server >> crashes with my Radeon7500. Even with GL_draw_method set to 1, > Then there's a problem with glArrayElement() in the R200 driver while > recording a displaylist. I'm using the 'radeon' driver for my Radeon7500, not 'r200'. > The specific piece of code that it's running is this (while a displaylist > is being recorded in GL_COMPILE_AND_EXECUTE mode): [... some code ...] This is not for me - I'm not skilled enough to deal with details of the code, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] ATI_texture_env_combine3 missing in action
The following is missing from the r200 driver: ATI_texture_env_combine3 Hence when trying to play ut2k3, all I see when playing is colliding triangles?? When will ATI_texture_env_combine3 be added? I sure hope there will be yet another r200 bleeding edge before you merge again. Thanks, Frank --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Is Voodoo1 supported under DRI?
On Wed, 2003-01-08 at 10:09, Raffaele Candeliere wrote: > Hallo everybody! > I have installed a 3DFX Voodoo1 accel in my PC with a Cirrus Logic > 5446 AGP card and i could manage to get it up and working under > Windows NT, but not under Linux (RedHat). > Does anybody know if is Voodoo1 supported under DRI? It never has been. It is supported by the full screen Mesa Glide2 drivers, or can be abused as a 2D card under XFree86. Alan --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] hull jaikbox
Dear Homeowner, Interest Rates are at their lowest point in 40 years! We help you find the best rate for your situation by matching your needs with hundreds of lenders! Home Improvement, Refinance, Second Mortgage, Home Equity Loans, and much, much more! You're eligible even with less than perfect credit! This service is 100% FREE to home owners and new home buyers without any obligation. Where others say NO, we say YES!!! Take just 2 minutes to complete the following form. There is no obligation, all information is kept strictly confidential, and you must be at least 18 years of age. Service is available within the United States only. This service is fast and free. We specialize in approving BAD CREDIT! http://realapartment.com/mtg/ This email has been screened and filtered by our in house ""OPT-OUT"" system in compliance with state laws. If you wish to "OPT-OUT" from this mailing as well as the lists of thousands of other email providers please visit http://realapartment.com/mtg/optout.html tk yknkkgik
Re: [Dri-devel] R200 - what can I do to help?
Then there's a problem with glArrayElement() in the R200 driver while
recording a displaylist.
The specific piece of code that it's running is this (while a displaylist
is being recorded in GL_COMPILE_AND_EXECUTE mode):
glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(3, GL_FLOAT, stride, &((*mesh)[0]->pos.x));
glEnableClientState(GL_NORMAL_ARRAY);
glNormalPointer(GL_FLOAT, stride,
&((*mesh)[0]->nrm.x));
int p = 0;
for (int i = 0; i < h - 1; i++)
{
glBegin(GL_TRIANGLE_STRIP);
for (int j = 0; j < w; j++)
{
glArrayElement(p);
glArrayElement(p + w);
p++;
}
glEnd();
}
(w and h are set previously, and the nasty pointer math on 'mesh' just
gives pointers to the appropriate w*h arrays of vertex data.)
The isosurf demo lets you do something like this, but doesn't use
COMPILE_AND_EXECUTE as it stands.
As it stands, it works fine. If I change it to build the list with
COMPILE_AND_EXECUTE, the first time (ie when it is being built) it works fine,
but on subsequent calllists, nothing is rendered.
Does this match what you are seeing?
Keith
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Is Voodoo1 supported under DRI?
Hallo everybody! I have installed a 3DFX Voodoo1 accel in my PC with a Cirrus Logic 5446 AGP card and i could manage to get it up and working under Windows NT, but not under Linux (RedHat). Does anybody know if is Voodoo1 supported under DRI? Thanks.
