[Dri-devel] random(?) x death
x just died on me for some reason and i noticed this in xfree's log i dont know if this was the cause of the death (it just droped back to console btw) since there isnt a timestamp of any sort (WW) RADEON(0): [dri] RADEONDRITransitionTo2d: kernel failed to unflip buffers. i see no other errors in other logs --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] random(?) x death
On Sam, 2002-11-30 at 09:11, Bret Towe wrote: x just died on me for some reason and i noticed this in xfree's log i dont know if this was the cause of the death (it just droped back to console btw) since there isnt a timestamp of any sort (WW) RADEON(0): [dri] RADEONDRITransitionTo2d: kernel failed to unflip buffers. i see no other errors in other logs And this isn't an error but only a warning. :) Presumably there was something about 'fatal signal x caught' at the end of the log? We'd have to see a backtrace. -- 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: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Feed Birds, not Squirrels for Christmas! dri-devel sfg
Have A Ball Watching Squirrels Try To Outwit This Birdfeeder!SQUIRREL'S SURPRISE Birdfeeder MAKES A GREAT XMAS GIFT Click on the image above to see this and many other Unique Backyard Bird Products áÄ
ë^¨¥Ë)¢{(ç[Èg¶§{Údî -ztájwazWO£«
h®)Úr©iËl7¡¶Úý§l²«qç讧zßÜ&âúÞv*ÞrÚe¥©fÓM6zpëׯzYX§X¬´:âuëÞX¬¶Ë(º· ~àzwÛi³ÿåËl²«qç讧zßåËlþX¬¶)ߣ÷kׯz
Re: [Dri-devel] random(?) x death
On 30 Nov 2002 13:53:40 +0100 Michel Dänzer [EMAIL PROTECTED] wrote: On Sam, 2002-11-30 at 09:11, Bret Towe wrote: x just died on me for some reason and i noticed this in xfree's log i dont know if this was the cause of the death (it just droped back to console btw) since there isnt a timestamp of any sort (WW) RADEON(0): [dri] RADEONDRITransitionTo2d: kernel failed to unflip buffers. i see no other errors in other logs And this isn't an error but only a warning. :) Presumably there was something about 'fatal signal x caught' at the end of the log? We'd have to see a backtrace. Maybe a week agot I had such an Xserver crash once too. Unfortunately the default ulimits are set so that no core is dumped on Debian. I hacked around a bit in the gdm config, so that I'll get a core dump the next time the Xserver dies. Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Parallelizing MESA's pipeline?
Felix Kühling wrote: On Fri, 29 Nov 2002 07:55:52 -0700 Brian Paul [EMAIL PROTECTED] wrote: [snip] Implementing a true threaded pipeline could be very compilicated. State changes are the big issue. If you stall/flush the pipeline for every state change you wouldn't gain anything. The alternative is to associate the GL state with each chunk of vertex data as it passes through the pipeline AND reconfigure the pipeline in the midst of state changes. Again, I think this would be very complicated. I see the problem. On many state changes, a corresponding driver function is called. In a parallel pipeline implementation, if there is still vertex data (with associated state) pending in the pipeline, it will be rendered by the driver with the wrong state. A proper solution would be to call the state-changing driver functions (or only UpdateState?) from within the pipeline, just before a driver stage is run. The required amount of modifications to mesas driver state management seems not too big. A quick recursive grep in xc/xc/extras/Mesa for ctx-Driver\.[[:alnum:]]*[[:space:]]*( finds 63 lines in 23 files. I found many state changing callbacks in dd.h which don't seem to be used. Are they left-overs from earlier Mesa versions or did my grep miss something? Which ones? Keith --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Parallelizing MESA's pipeline?
On Fri, 29 Nov 2002 07:55:52 -0700 Brian Paul [EMAIL PROTECTED] wrote: [snip] Implementing a true threaded pipeline could be very compilicated. State changes are the big issue. If you stall/flush the pipeline for every state change you wouldn't gain anything. The alternative is to associate the GL state with each chunk of vertex data as it passes through the pipeline AND reconfigure the pipeline in the midst of state changes. Again, I think this would be very complicated. I see the problem. On many state changes, a corresponding driver function is called. In a parallel pipeline implementation, if there is still vertex data (with associated state) pending in the pipeline, it will be rendered by the driver with the wrong state. A proper solution would be to call the state-changing driver functions (or only UpdateState?) from within the pipeline, just before a driver stage is run. The required amount of modifications to mesas driver state management seems not too big. A quick recursive grep in xc/xc/extras/Mesa for ctx-Driver\.[[:alnum:]]*[[:space:]]*( finds 63 lines in 23 files. I found many state changing callbacks in dd.h which don't seem to be used. Are they left-overs from earlier Mesa versions or did my grep miss something? Regards, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] trunk (Mesa-5.0): Some preliminary results on topof 2.5.49-mm1
On Fre, 2002-11-29 at 16:27, Brian Paul wrote: Michel Dänzer wrote: On Don, 2002-11-28 at 16:51, Brian Paul wrote: Michel Dänzer wrote: Sounds like a problem I'm seeing with the amoeba demo, some faces of a spinning cube (with the observer inside) are missing. RADEON_TCL_FORCE_DISABLE=1 fixes it, which wasn't necessary before the Mesa 5.0 merge. Also, it hangs near the end with HW TCL, but this was already the case before the merge. [...] I did a spot check of some of the radeon sources but didn't find anything wrong. Me neither, unsurprisingly. Could it be caused by a Mesa change? I'm even more lost there... But if it works correctly with RADEON_TCL_FORCE_DISABLE that indicates that the Mesa code is correct. Are exactly the same code paths exercised in both cases? -- 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: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Parallelizing MESA's pipeline?
On Sat, 30 Nov 2002 16:24:59 + Keith Whitwell [EMAIL PROTECTED] wrote: Felix Kühling wrote: [snip] I found many state changing callbacks in dd.h which don't seem to be used. Are they left-overs from earlier Mesa versions or did my grep miss something? Which ones? Ok, I got the answer to my question ;) There are many calls like this one: (*ctx-Driver.Enable)( ctx, GL_TEXTURE_GEN_Q, GL_FALSE ); My grep missed them. Another grep ctx-Driver\..*( finds 162 lines in 34 files. :-/ Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] random(?) x death
On Sat, 2002-11-30 at 04:53, Michel Dänzer wrote: On Sam, 2002-11-30 at 09:11, Bret Towe wrote: x just died on me for some reason and i noticed this in xfree's log i dont know if this was the cause of the death (it just droped back to console btw) since there isnt a timestamp of any sort (WW) RADEON(0): [dri] RADEONDRITransitionTo2d: kernel failed to unflip buffers. i see no other errors in other logs And this isn't an error but only a warning. :) Presumably there was something about 'fatal signal x caught' at the end of the log? We'd have to see a backtrace. alright to bad i dont have one... -- 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: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Parallelizing MESA's pipeline?
On Sat, 30 Nov 2002 17:20:04 +0100 Felix Kühling [EMAIL PROTECTED] wrote: On Fri, 29 Nov 2002 07:55:52 -0700 Brian Paul [EMAIL PROTECTED] wrote: [snip] Implementing a true threaded pipeline could be very compilicated. State changes are the big issue. If you stall/flush the pipeline for every state change you wouldn't gain anything. The alternative is to associate the GL state with each chunk of vertex data as it passes through the pipeline AND reconfigure the pipeline in the midst of state changes. Again, I think this would be very complicated. I see the problem. On many state changes, a corresponding driver function is called. In a parallel pipeline implementation, if there is still vertex data (with associated state) pending in the pipeline, it will be rendered by the driver with the wrong state. A proper solution would be to call the state-changing driver functions (or only UpdateState?) from within the pipeline, just before a driver stage is run. The required amount of modifications to mesas driver state management seems not too big. A quick recursive grep in xc/xc/extras/Mesa for ctx-Driver\.[[:alnum:]]*[[:space:]]*( finds 63 lines in 23 files. Vertex formats are the real problem. Driver functions are called directly from the GL application and modify the driver state bypassing the pipeline. Would it be worth sacrificing for a multi-threaded pipeline on an SMP system? In the radeon driver vtxfmt seems to be only enabled with TCL. But I remember some mails about vertex formats and the mach64 driver. Are vertex formats widely used with non-TCL drivers? Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] hey
Below is the result of your feedback form. It was submitted by ([EMAIL PROTECTED]) on Saturday, November 30, 2002 at 13:47:35 --- :: As seen on NBC, CBS, and CNN, and even Oprah! The health discovery that actually :reverses aging while burning fat, without dieting or exercise! This proven discovery :has even been reported on by the New England Journal of Medicine. Forget aging and :dieting forever! a href= http://200.206.185.58/hgh/index.php?id=272 And it's :Guaranteed!/a* Reduce body fat and build lean muscle WITHOUT EXERCISE!* Enhace :sexual performance* Remove wrinkles and cellulite* Lower blood pressure and improve :cholesterol profile* Improve sleep, vision and memory* Restore hair color and growth* :Strengthen the immune system* Increase energy and cardiac output* Turn back your :body's biological time clock 10-20 years in 6 months of usage !!!a href= :http://200.206.185.58/hgh/index.php?id=272 Click here/a to view our site. --- --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Parallelizing MESA's pipeline?
On Sat, Nov 30, 2002 at 08:04:55PM +0100, Felix Kühling wrote: On Sat, 30 Nov 2002 17:20:04 +0100 Felix Kühling [EMAIL PROTECTED] wrote: I see the problem. On many state changes, a corresponding driver function is called. In a parallel pipeline implementation, if there is still vertex data (with associated state) pending in the pipeline, it will be rendered by the driver with the wrong state. A proper solution would be to call the state-changing driver functions (or only UpdateState?) from within the pipeline, just before a driver stage is run. The required amount of modifications to mesas driver state management seems not too big. A quick recursive grep in xc/xc/extras/Mesa for ctx-Driver\.[[:alnum:]]*[[:space:]]*( finds 63 lines in 23 files. Vertex formats are the real problem. Driver functions are called directly from the GL application and modify the driver state bypassing the pipeline. Could you please give an example? Would it be worth sacrificing for a multi-threaded pipeline on an SMP system? In the radeon driver vtxfmt seems to be only enabled with TCL. But I remember some mails about vertex formats and the mach64 driver. Are vertex formats widely used with non-TCL drivers? All drivers have a vertex format. One of the last stages of the Mesa pipeline on a DRI driver is to build vertex buffers, which are nothing more than a big array of vertices using that vertex format. What happens is that most drivers use the D3D vertex format. While in newer cards that format usually corresponds to the card native vertex format, on older cards (such as Mach64, and 3DFX) it doesn't. In summary, the vertex format it's like a C structure of how the card expects to see a vertex when reading the system memory by DMA. Now, returning to the main issue here, I'm not seeing what state changes happen during the vertex buffer construction... besides the vertex buffer itself, which would had to be thread specific. José Fonseca __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Parallelizing MESA's pipeline?
On Sat, 30 Nov 2002 19:52:50 + José Fonseca [EMAIL PROTECTED] wrote: On Sat, Nov 30, 2002 at 08:04:55PM +0100, Felix Kühling wrote: [snip] Vertex formats are the real problem. Driver functions are called directly from the GL application and modify the driver state bypassing the pipeline. Could you please give an example? I am referring to the GLvertexformat structure which is defined in dd.h. It contains driver callbacks which are installed directly into a glapi_table. This happens in xc/xc/extras/Mesa/src/vtxfmt.c. Reading the comments in vtxfmt.c and dd.h this really seems to be TCL related. An example is radeon_Materialfv in radeon_vtxfmt.c. A backtrace from radeon_Materialfv looks like this: #0 radeon_Materialfv (face=1032, pname=4609, params=0xb22c) at radeon_vtxfmt.c:764 #1 0x404b627c in neutral_Materialfv (face=134605728, pname=134605728, v=0x805eba0) at ../../../../extras/Mesa/src/vtxfmt_tmp.h:162 #2 0x0804ce29 in draw_stairs_internal (mi=0xb388) at stairs.c:318 #3 0x0804d580 in draw_stairs (mi=0xb388) at stairs.c:555 #4 0x0804fb19 in xlockmore_screenhack (dpy=0x80664d8, window=48234497, want_writable_colors=0, want_uniform_colors=0, want_smooth_colors=0, want_bright_colors=0, event_mask=0, hack_init=0x804d380 init_stairs, hack_draw=0x804d454 draw_stairs, hack_reshape=0x804cf9c reshape_stairs, hack_handle_events=0, hack_free=0) at xlockmore.c:385 #5 0x0804c78e in screenhack (dpy=0x80664d8, window=48234497) at ../xlockmore.h:154 #6 0x0804e6d0 in main (argc=1, argv=0xb7d4) at ./../screenhack.c:638 There is that neutral_* wrapper layer in between. So there may still be hope ;-) Would it be worth sacrificing for a multi-threaded pipeline on an SMP system? In the radeon driver vtxfmt seems to be only enabled with TCL. But I remember some mails about vertex formats and the mach64 driver. Are vertex formats widely used with non-TCL drivers? All drivers have a vertex format. One of the last stages of the Mesa pipeline on a DRI driver is to build vertex buffers, which are nothing more than a big array of vertices using that vertex format. What happens is that most drivers use the D3D vertex format. While in newer cards that format usually corresponds to the card native vertex format, on older cards (such as Mach64, and 3DFX) it doesn't. In summary, the vertex format it's like a C structure of how the card expects to see a vertex when reading the system memory by DMA. Ok. This seems to be something different from what I described above. Now, returning to the main issue here, I'm not seeing what state changes happen during the vertex buffer construction... besides the vertex buffer itself, which would had to be thread specific. José Fonseca Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 resource problems
On Thu, 28 Nov 2002, Svante Signell wrote: Leif Delgass writes: On Wed, 27 Nov 2002, Svante Signell wrote: Leif Delgass writes: Have you tried a lower resolution? Not yet. Try restarting X with 1024x768@16bpp for a while and see if you still have the same problem. I have now tested at 1024x768, and everything works OK, but I think there is memory not returned to the card in the 3D driver, see below. If it's some sort of memory leak, I'd expect that you'd run into it eventually even at a lower resolution. If it doesn't happen at lower resolutions, maybe you really just don't have enough offscreen memory at 1280x1024. What is meant with offscreen memory, main memory + card memory or smth else? free: total used free sharedbuffers cached Mem:127660 123760 3900 0 9104 44884 -/+ buffers/cache: 69772 57888 Swap: 130748 84172 46576 Offscreen memory refers to the on-card memory left over after the framebuffer allocation(s). When there are no GL contexts, the framebuffer memory is equal to display width x display height x bytes per pixel (2 for 16-bit). With GL contexts running, there is an additional back buffer (same size as the 2D front framebuffer) plus a depth buffer which is width x height x 2 (depth buffer is always 16-bit). The remaining offscreen memory is used for XAA and XVideo buffers. You can get a BadAlloc when there is not enough offscreen memory left. Doing the calculations one gets: 8Meg - 3x(1280x1024)= 8388608 - 7864320 = 524288 bytes = 512 kbytes which is close to what the log file reports: (II) ATI(0): Will use 511 kB of offscreen memory for XAA It seems that the 3D driver already has allocated the frame buffer, back buffer and depth buffer memory at startup, right. Obviously the remaining 512k of memory is sufficient for the XV driver when no 3D applications has been activated. Actually, those allocations only apply when a GL context is running. That's why the message was changed from Using to Will use -- no memory is allocated when that message is logged. When the X server actually allocates that memory for the DRI back and depth buffers (when changing from no GL contexts to one or more GL contexts -- not including the X server's context), you should see Largest offscreen area available: ... appear again at the end of the X log. Also when that happens, the XVideo memory (in use for the current frame) is freed. If the remaining offscreen memory after the DRI allocations (511 kB in this case) is not enough for subsequent video frame allocations, then you'll see the BadAlloc, which would cause mplayer to crash. Since the driver uses double-buffering for XVideo by default, this is _not_ enough for DVD and I'm pretty sure it's not enough for the video size you had the problem with in your first email (though I'd have to check the calculations for that video format). So if you have both a GL app and an XVideo app running at the same time, the XVideo app's allocations will fail unless the video size is fairly small. This is not very graceful, but it's expected with the current code and doesn't indicate a memory leak. However, if you run mplayer, exit mplayer, run a GL app, exit the GL app, and then run mplayer again, you shouldn't have a problem. If that's what's really happening, that's a bug. You can check /proc/dri/0/clients to see the pids of all the DRI clients (there will always be at least one for the X server). Note however that when I run KDE, I get a few clients listed for some processes that are linked to libGL even though they haven't created a full-fledged context and don't cause the X server to allocate any memory for 3D. Also, did you run any GL apps before starting mplayer or between attempts (or during attempts)? xscreensaver is running, so some 3D applications are possibly run when it activates. The box is usually on all day. I can now reproduce the error for 1280x1024: 1. Run mplayer using the XV driver: Everything is OK 2. Run a 3D application, such as the atlantis demo in xscreensaver 3. Run mplayer using the XV driver again: Error state occurs X11 error: BadAlloc (insufficient resources for operation) Running the xscreensaver demo again works, no problem. Conclusion: Memory available for XAA and XV before running the 3D application is not returned when the application exits!! Maybe this in not possible to do for this card without leaving X and reentering, but it is _very_ annoying. I don't really like to run the desktop at 1024x768. I will robably use another X display for 3D applications or for viewing movie clips. The best alternative though, would be if you can find a solution in the
[Dri-devel] radeonFlushVertices restores the neutral vtxfmt wrapper
Hi, while I was trying to understand the vtxfmt mesa code and poking around with gdb I noticed that the neutral vtxfmt wrapper gets restored quite often. I tracked it to radeonFlushVertices where _mesa_install_exec_vtxfmt( ctx, rmesa-vb.vtxfmt ) is called if the FLUSH_UPDATE_CURRENT flag is set. _mesa_install_exec_vtxfmt in turn sets ctx-TnlModule.Current to the new exec vertex format and calls _mesa_restore_exec_vtxfmt( ctx ) which restores the neutral wrapper. Is this really what was intended here? The only place I could find where the FLUSH_UPDATE_CURRENT flag is set in the radeon driver is in radeon_vtxfmt_c.c and there the Exec dispatch table is modified directly. So there should be no need for reinstalling the vertex format. Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] nForce and AGPGART
hi, i have the same proble that Rene Sepulveda : ati aiw 32Mo agp nidia nforce 415d, ide=ok, usb=ok, sound=ok, AGP=BAD ! the nvidia's driver agp work only with nforce 420 (nofrce415+igp) Alexander Stohr wrote: Can you please send the outputs of `lspci -v -xxx` to the list? my lspci : 00:00.0 Host bridge: nVidia Corporation: Unknown device 01a4 (rev b2) Flags: bus master, 66Mhz, fast devsel, latency 0 Memory at fc00 (32-bit, prefetchable) [size=32M] Capabilities: [40] AGP version 2.0 Capabilities: [60] #08 [2001] 00: de 10 a4 01 06 00 b0 00 b2 00 00 06 00 00 80 00 10: 08 00 00 fc 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 40: 02 60 20 00 17 02 00 1f 01 00 00 00 ff ff ff ff 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 60: 08 00 01 20 20 00 88 88 10 00 00 00 01 0f 0f 0f 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 80: 0f 01 00 00 ff ff ff 0f 00 00 00 00 12 ff fe 3f 90: 00 00 00 00 df f7 eb f9 00 00 00 00 02 00 00 00 a0: 00 00 00 00 07 41 00 00 01 00 00 00 00 00 00 00 b0: f1 ff 01 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 33 33 03 00 33 33 03 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 01 00 00 00 ff ff f0 07 02 00 00 00 e0: 0e 00 47 00 96 34 ff 01 00 00 00 00 00 00 00 00 f0: 0b 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00:00.1 RAM memory: nVidia Corporation: Unknown device 01ac (rev b2) Subsystem: nVidia Corporation: Unknown device 0c11 Flags: 66Mhz, fast devsel 00: de 10 ac 01 00 00 20 00 b2 00 00 05 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 de 10 11 0c 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 00 01 00 00 ff 44 ff 66 ff 99 11 aa ff 99 11 aa 50: ff 44 ff 66 88 ff 88 ff f0 00 e0 00 7f 3f ff 0f 60: 00 00 00 80 00 00 00 00 01 00 00 00 01 00 00 00 70: 30 00 00 00 38 00 00 00 1f 00 00 01 11 10 0f 17 80: 37 37 37 37 39 39 39 3a 0d 0d 0d 0d 0d 0d 0d 0e 90: 09 0a 23 22 30 32 43 22 3f 08 61 03 20 00 00 00 a0: 2a 00 00 00 02 00 20 00 2a 00 00 00 02 00 20 00 b0: 2a 00 00 00 02 00 20 00 2a 00 00 00 01 00 20 00 c0: 16 00 00 00 00 00 00 00 00 00 00 00 80 88 02 00 d0: 40 4c 00 00 20 22 00 00 0c 00 00 00 0e 00 00 00 e0: 0a 00 00 00 80 00 00 00 88 44 92 24 11 10 00 00 f0: 18 10 00 11 20 20 00 00 01 04 00 00 31 02 03 32 00:00.2 RAM memory: nVidia Corporation: Unknown device 01ad (rev b2) Subsystem: nVidia Corporation: Unknown device 0c11 Flags: 66Mhz, fast devsel 00: de 10 ad 01 00 00 20 00 b2 00 00 05 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 de 10 11 0c 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 01 10 21 01 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: ff ff ef 6a ff ff bf 3d ff ff fa 7f ff 7f ff 7d 80: ff ff 3c 5b ff ff bf 7f ff 3f b8 5f ff ff 9f 7c 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 fe 03 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 80 ff ff ff bf e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:00.3 RAM memory: nVidia Corporation: Unknown device 01ab (rev b2) Subsystem: nVidia Corporation: Unknown device 0c11 Flags: 66Mhz, fast devsel 00: de 10 ab 01 00 00 20 00 b2 00 00 05 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 de 10 11 0c 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 80 80 50 50 00 40 80 0f 65 65 55 66 86 77 77 86 50: 65 65 55 00 cb bb 00 00 35 33 04 00 10 10 03 00 60: 56 66 00 00 01 80 00 01 6b 00 00 00 03 03 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:01.0 ISA bridge: nVidia Corporation: Unknown device 01b2 (rev c3) Subsystem: nVidia Corporation: Unknown device 0c11 Flags: bus master, 66Mhz, fast devsel, latency 0 Capabilities: [50] #08 [01e1] 00: de 10 b2 01 0f 00 b0 00 c3 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 de 10 11 0c 30: 00 00 00 00 50 00 00 00 00 00 00 00 ff 00 00 00 40: de 10 11 0c 00 00 10 20 00 07 00 00 de fd 00 00 50: 08 00 e1 01 60 00 88 88 a0 00 00 00 00 00 00 00 60: 00 00 00 00 09 0a 0b 00 03 10 9a 35 aa a0 0b 00 70: 08 00 00 00 00 00 00 00 00
Re: [Dri-devel] radeonFlushVertices restores the neutral vtxfmt wrapper
On Sat, 30 Nov 2002 23:32:06 +0100 Felix Kühling [EMAIL PROTECTED] wrote: Hi, while I was trying to understand the vtxfmt mesa code and poking around with gdb I noticed that the neutral vtxfmt wrapper gets restored quite often. I tracked it to radeonFlushVertices where _mesa_install_exec_vtxfmt( ctx, rmesa-vb.vtxfmt ) is called if the FLUSH_UPDATE_CURRENT flag is set. _mesa_install_exec_vtxfmt in turn sets ctx-TnlModule.Current to the new exec vertex format and calls _mesa_restore_exec_vtxfmt( ctx ) which restores the neutral wrapper. Is this really what was intended here? The only place I could find where the FLUSH_UPDATE_CURRENT flag is set in the radeon driver is in radeon_vtxfmt_c.c and there the Exec dispatch table is modified directly. So there should be no need for reinstalling the vertex format. In radeon_vtxfmt_c.c (choose_* functions) state specific code is generated on the fly and plugged into the dispatch table. When the state changes the dispatch table has to be restored. But it seems that _mesa_install_exec_vtxfmt does more than necessary. Any static vtxfmt functions could remain in the dispatch table. And would it not be sufficient to put the choose_* functions back into the dispatch table instead of the neutral_* ones. Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon TCL global ambient problem solved
Hi, my digging is starting to pay off ;) I had reported that weird problem, that the global ambient light is not correct using hardware TCL if I specify anything other than 1.0 as alpha component. Now I found out that the trigger for this problem is actually to specify the default of (0.2, 0.2, 0.2, 1.0). In that case Mesa is clever enough to not call the driver's LightModelfv functions as the value doesn't change. So the real error is that the global ambient is not set to the correct default value in the TCL state after turning on the ambient light. I fixed it by adding a call to update_global_ambient in radeonColorMaterial. Here is the one-line patch for completeness ;) --- radeon_state.c.~1.24.~ 2002-11-26 02:57:38.0 +0100 +++ radeon_state.c 2002-12-01 02:43:42.0 +0100 @@ -887,6 +887,7 @@ for (p = 0 ; p MAX_LIGHTS; p++) update_light_colors( ctx, p ); +update_global_ambient( ctx ); } } Regards, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Fwd: dri-devel Automated Cash hki
dri-devel,
YOUR GUARANTEED DOWNLINE!!! Takes
10 seconds to reply! No sponsoring
req
uired!No selling required!Receive
GUAR<[EMAIL PROTECTED]" -->
ANTEED monthly checks!Use Our Explosive Online Sponsoring System to build a massive money-making machine from the convenience of your home, sitting at your computer like you are right now... Don't hesitate! Take the FR
EE TOUR at ZERO risk!!! CLICK
tuysottbgeckvykxnuixpyrmo
áÄ
ë^¨¥Ë)¢{(ç[Èg¶§{Údî -ztájwazWO£«
h®)Úr©iËl7¡¶Úý§l²«qç讧zßÜ&âúÞv*ÞrÚe¥©fÓM6zpëׯzYX§X¬´:âuëÞX¬¶Ë(º· ~àzwÛi³ÿåËl²«qç讧zßåËlþX¬¶)ߣ÷kׯz
