Re: [Dri-devel] XFree-4.1.0 and Rage128Pro: glxgears quit with drmR128SwapBuffers = -14
Take your kernel upto 2.4.10 and you'll be o.k. Alan. On Thu, Oct 04, 2001 at 04:28:33PM +0200, Huber, Matthias 6667 SFA-31 wrote: Hi, the subject says it: glxgears (and all other OpenGL-based programs) abort with the message: drmR128SwapBuffers = -14 My configuration: Kernel 2.4.6 XFree86 4.1.0 ATI AIW 128 Pro newly compiled drm kernel modules, r128 XFree86 driver, r128_dri.so, etc. glxinfo works fine, showing direct rendering enabled. I tracked the problem to the r128_dri.so. There is an ioctl to the dri device with DRM_R128_SWAP_BUFFERS (or so), this ioctl return -14 and that's it. But I can't see anywhere in the kernel driver (r128.o), that it could return -14 (-EFAULT) for this ioctl. Any ideas are really wellcome. Thanks, Matthias Huber ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] XFree-4.1.0 and Rage128Pro: glxgears quit withdrmR128SwapBuffers = -14
On Thu, 2001-10-04 at 16:28, Huber, Matthias 6667 SFA-31 wrote: the subject says it: glxgears (and all other OpenGL-based programs) abort with the message: drmR128SwapBuffers = -14 My configuration: Kernel 2.4.6 XFree86 4.1.0 ATI AIW 128 Pro newly compiled drm kernel modules, r128 XFree86 driver, r128_dri.so, etc. Do you have the DRM from kernel 2.4.9 or later or built from XFree86 4.1.0 source? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] gears problem
On Thursday 04 October 2001 07:06, Michel Dänzer wrote: On Thu, 2001-10-04 at 03:56, Steven P. Lilly wrote: Everything else seems to work fine, which points at a glxgears bug? I encountered something very similar with glxgears when I was attempting to get RagePRO DMA operation working for Utah-GLX under PPC. Manually sending the registers from the DMA buffer (psuedo-DMA) would work completely fine for glxgears, but bus-mastering mode would hang the box after about 5-10 frames. More interesting was the fact that if I prevented the blue gear from being rotated (simple comment out of one line...) the bus-mastering mode worked fine. At the time, I hadn't the time to pursue it, but it's been lingering in my mind since then because as soon as we get it working for x86, we're going to want to make it happen on PPC. I know, it's not the same chip, but someone could check and see if it's the same problem. -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] gears problem
On Thu, 2001-10-04 at 17:58, Frank Earl wrote: On Thursday 04 October 2001 07:06, Michel Dänzer wrote: On Thu, 2001-10-04 at 03:56, Steven P. Lilly wrote: Everything else seems to work fine, which points at a glxgears bug? I encountered something very similar with glxgears when I was attempting to get RagePRO DMA operation working for Utah-GLX under PPC. Manually sending the registers from the DMA buffer (psuedo-DMA) would work completely fine for glxgears, but bus-mastering mode would hang the box after about 5-10 frames. More interesting was the fact that if I prevented the blue gear from being rotated (simple comment out of one line...) the bus-mastering mode worked fine. At the time, I hadn't the time to pursue it, but it's been lingering in my mind since then because as soon as we get it working for x86, we're going to want to make it happen on PPC. I know, it's not the same chip, but someone could check and see if it's the same problem. Hardly, as this thread is about incorrect rendering, not lockups. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] tdfx mesa-3-5-branch fix.
On Wed, 3 Oct 2001 19:19, Zephaniah E\. Hull wrote: The current mesa-3-5-branch code has a bug dealing with GL_QUADS, suffice it to say that it results in some, interesting, rendering bugs. Looks like a cutpaste bug. I'll commit the fix. Keith _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] tdfx mesa-3-5-branch fix.
On Thu, 4 Oct 2001 12:55, Zephaniah E\. Hull wrote:
On Thu, Oct 04, 2001 at 10:32:15AM -0600, Keith Whitwell wrote:
On Wed, 3 Oct 2001 19:19, Zephaniah E\. Hull wrote:
The current mesa-3-5-branch code has a bug dealing with GL_QUADS,
suffice it to say that it results in some, interesting, rendering bugs.
Actually I think the loop should read
for (i = start; i count - 4; i+=4) {
ie. a less-than rather than less-equal. The difference isn't noticable
unless you emit groups of quads with 4n+1 vertices, in which case you'll
get one bogus quad at the end.
Actually, it is very specificly = instead of , otherwise you simply
don't draw the last quad, and if you are only drawing a single quad,
well, it never gets drawn. (I made it the first time, then corrected)
Yes, you're right.
Keith
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] gears problem
On Thu, 2001-10-04 at 21:57, Steven P. Lilly wrote: Sorry to have bothered everyone. I downloaded the source to glxgears and found the problem. It wasn't setting up the viewport properly until the reshape function got called. With a window manager it gets called right away when the window is created without one it doesn't ever get called. If you have a fix, please submit it to the appropriate place, probably XFree86 or Mesa. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] glDrawPixels on i810
On Fri, 2001-10-05 at 00:08, Nathan Hand wrote: XV is completely independent of V4L and the DRI. This is true conceptually and was true implementation-wise until recently. However, the r128 driver uses the DRM to transfer the XvImage data now when possible, and Peter Surda has been bug^Wasking us for some time to provide facilities to do the same for grabbing... -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] gears problem
On Thursday 04 October 2001 12:30, you wrote: Hardly, as this thread is about incorrect rendering, not lockups. Ooops... Could have sworn that it was about lockups (since I get that with my wife's machine with gears...)- that's what I get for trying to pass the time during compiles, etc. up at work... :-) -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] tdfx mesa-3-5-branch fix. / status / Glide3 / 3DNow!
On Thu, 4 Oct 2001 19:40, Dieter Nützel wrote: Hello all, after your latest fixes I've to report the following issues together with my Voodoo5 5500 AGP. First of all: Do I have to use the Mesa-4.0 CVS tree? Keith what was the name of the path variable, again? No. 1. UT 436 show a mirror hall effect (it seems to me that there are some redraw/flush events missing). First I can stop it with the ESC key but later it crash and hang the whole X server. 2. Parsec show some texture corruption. 3. Triangle calculation is much slower. For example ipers goes down to ~11 fps where the trunk gave me 15~16 fps on my 1 GHz Athlon II SlotA (with Glide3 _WITH_ 3DNow! optimizations on). --- Yes, I got it working, again. Later more on this topic. Second example, VTK (sphere-bench.tcl-2.1, stripper mode) goes down to ~1450kpolys/s where as the trunk gave ~1640kpolys/s. Interesting. In many other examples the -3-5 code is faster or the same. Keith _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] tdfx mesa-3-5-branch fix. / status / Glide3 / 3DNow!
Hello all, after your latest fixes I've to report the following issues together with my Voodoo5 5500 AGP. First of all: Do I have to use the Mesa-4.0 CVS tree? Keith what was the name of the path variable, again? 1. UT 436 show a mirror hall effect (it seems to me that there are some redraw/flush events missing). First I can stop it with the ESC key but later it crash and hang the whole X server. 2. Parsec show some texture corruption. 3. Triangle calculation is much slower. For example ipers goes down to ~11 fps where the trunk gave me 15~16 fps on my 1 GHz Athlon II SlotA (with Glide3 _WITH_ 3DNow! optimizations on). --- Yes, I got it working, again. Later more on this topic. Second example, VTK (sphere-bench.tcl-2.1, stripper mode) goes down to ~1450kpolys/s where as the trunk gave ~1640kpolys/s. mesa-3.5: VTK Simple Sphere Benchmark 2.1 - Robert Riviere (results) : [EMAIL PROTECTED] www.inria.fr/caiman/personnel/Robert.Riviere/vtk/sphere-bench.html - Sebastien Barre (script) : [EMAIL PROTECTED] www.hds.utc.fr/~barre/vtk/sphere-bench.html Find the best sphere resolutions for your card, launch *bench combinations* and send us your results (copy the session with Control /) along with a complete description of your system (VTK/OS version, hardware description). System : - i686 running Linux 2.4.11-pre2-preempt - VTK 3.2.0 (rev: 1.995, 2001/10/04 00:04:14) - OpenGL - Visual is 1280x1024, truecolor/truecolor/24 - Tcl/Tk 8.3.2 Defaults : WARNING : $active_camera GetClippingRange was 2.45199 4.78654 , should be 0.348564 17.4282 - VTK : wrong, please report us your values... - Rotation limit, increment, number : (300 by 30) x 3 - Sphere opacity (if transparency activated) : 0.3 - Sphere radius and small radius (if small_sphere activated) : 0.9, 0.5 - Combinations : [stripper] [small_sphere] [] [transparency] [wireframe] [texture] [texture, transparency] NOTE : the 512x512 and above sphere resolutions are *really* high, use them carefully, as it might hang your system for a while. Moreover, they have no real signification in 400x400 or less window. IMPORTANT : move the camera a little to interact with the sphere before playing with this bench... Benching for sphere resolutions : 32, 64, 128, 256, 512 Setting(s) : window is 400 x 400, sphere radius is 0.9 Option(s) : [stripper] 32x32 : 174.6 kpolys/s 64x64 : 974.4 kpolys/s 128x128 : 1156.0 kpolys/s 256x256 : 1228.6 kpolys/s 512x512 : 1452.4 kpolys/s *** I get one segmentation fault with the 3DNow! accelerated Glide3 lib: SunWave1nm /usr/lib/libglide3.so.3.1 |grep 3DNow 00035d00 T _grDrawTriangles_3DNow 000367fd T _grDrawVertexList_3DNow_Clip 00036440 T _grDrawVertexList_3DNow_Window 000351c0 T _grTexDownload_3DNow_MMX 00035300 T _trisetup_3DNow_clip_cull_invalid 00035300 T _trisetup_3DNow_clip_cull_valid 00035300 T _trisetup_3DNow_clip_nocull_invalid 00035300 T _trisetup_3DNow_clip_nocull_valid 00035540 T _trisetup_3DNow_win_cull_invalid 00035800 T _trisetup_3DNow_win_cull_valid 00035300 T _trisetup_3DNow_win_nocull_invalid 00035ac0 T _trisetup_3DNow_win_nocull_valid SunWave1gdb geartrain core GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-suse-linux...(no debugging symbols found)... Core was generated by `geartrain'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/X11R6/lib/libglut.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/X11R6/lib/libglut.so.3 Reading symbols from /usr/lib/libGLU.so.1...done. Loaded symbols for /usr/lib/libGLU.so.1 Reading symbols from /usr/lib/libGL.so.1...done. Loaded symbols for /usr/lib/libGL.so.1 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Loaded symbols for /usr/X11R6/lib/libX11.so.6 Reading symbols from /usr/X11R6/lib/libXmu.so.6...done. Loaded symbols for /usr/X11R6/lib/libXmu.so.6 Reading symbols from /usr/X11R6/lib/libXt.so.6...done. Loaded symbols for /usr/X11R6/lib/libXt.so.6 Reading symbols from /usr/X11R6/lib/libXi.so.6...done. Loaded symbols for /usr/X11R6/lib/libXi.so.6 Reading symbols from /lib/libpthread.so.0...done. rw_common (): write: Success. warning: unable to set global thread event mask [New Thread 1024 (LWP 9422)] rw_common (): write: Success. warning: stop_or_attach_thread: generic error Loaded symbols for /lib/libpthread.so.0 Reading symbols from /usr/X11R6/lib/libXext.so.6...done. Loaded symbols for /usr/X11R6/lib/libXext.so.6
