Re: R300 success stories
Hi i tested nwn with latest cvs-snapshot of r300. It runs, however the screen is totally weird. I uploaded an screenshot of what the screen looks like to http://www.freephotoserver.com/files/img14048784_50868694.jpg . Neverball runs fine, the only option which slows it down is reflection (which needs an stencil buffer). I dont get any lockups since about a week (which seems to be strange as many others get lockups), however i do not use xorg-cvs, but ubuntus xorg-package (seems to be the latest 6.8.2-beta) with the ati.patch from r300. Thanks for your work cheers Jan -- Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
oops, I hit reply, not reply all.. cc-ing dri-devel this time. jan kreuzer wrote: Hi i tested nwn with latest cvs-snapshot of r300. It runs, however the screen is totally weird. I uploaded an screenshot of what the screen looks like to http://www.freephotoserver.com/files/img14048784_50868694.jpg . nwn probably uses something which requires elts to be supported (ie. glDrawElements). The latest cvs snapshot has made a start on this, but more information is needed. I've had some success with ut2004 by putting the indices into the command buffer, but ultimately this is not how we want to do it. I dont get any lockups since about a week (which seems to be strange as many others get lockups), however i do not use xorg-cvs, but ubuntus xorg-package (seems to be the latest 6.8.2-beta) with the ati.patch from r300. Is this with vertex buffers turned on? If so, can you cause a lockup by moving a window over the top of the glxgears window? This is the only way I can cause a lockup with the vertex buffer code. I'm using xorg cvs from 1-2 days before the dlloader changes. Cheers, Ben Skeggs. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
nwn probably uses something which requires elts to be supported (ie. glDrawElements). The latest cvs snapshot has made a start on this, but more information is needed. I've had some success with ut2004 by putting the indices into the command buffer, but ultimately this is not how we want to do it. As far as i could see from the cvs-logs the elts thing was added 17 hours ago, however i tested nwn earlier and the screenshots looked the same. So it seems that this change is not responsible for this weird looking. However i now can turn on reflection in neverball without an slowdown (before i had an slowdown). I dont get any lockups since about a week (which seems to be strange as many others get lockups), however i do not use xorg-cvs, but ubuntus xorg-package (seems to be the latest 6.8.2-beta) with the ati.patch from r300. Is this with vertex buffers turned on? If so, can you cause a lockup by moving a window over the top of the glxgears window? This is the only way I can cause a lockup with the vertex buffer code. I'm using xorg cvs from 1-2 days before the dlloader changes. Hmm i must test this with an earlier snapshot, then i will report back. Greetings Jan --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
Jan Kreuzer wrote: nwn probably uses something which requires elts to be supported (ie. glDrawElements). The latest cvs snapshot has made a start on this, but more information is needed. I've had some success with ut2004 by putting the indices into the command buffer, but ultimately this is not how we want to do it. As far as i could see from the cvs-logs the elts thing was added 17 hours ago, however i tested nwn earlier and the screenshots looked the same. So it seems that this change is not responsible for this weird looking. I wasn't saying that this change broke it, I meant that when completed, applications which use glDrawElements etc, should render correctly, rather than having some random polygons on the screen. I'm not even sure if this is the cause of the nwn rendering errors, it could be something else completely. But, it does look like the same type of problem which ut2004-demo has. Cheers, Ben Skeggs. However i now can turn on reflection in neverball without an slowdown (before i had an slowdown). I dont get any lockups since about a week (which seems to be strange as many others get lockups), however i do not use xorg-cvs, but ubuntus xorg-package (seems to be the latest 6.8.2-beta) with the ati.patch from r300. Is this with vertex buffers turned on? If so, can you cause a lockup by moving a window over the top of the glxgears window? This is the only way I can cause a lockup with the vertex buffer code. I'm using xorg cvs from 1-2 days before the dlloader changes. Hmm i must test this with an earlier snapshot, then i will report back. Greetings Jan --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
nwn probably uses something which requires elts to be supported (ie. glDrawElements). The latest cvs snapshot has made a start on this, but more information is needed. I've had some success with ut2004 by putting the indices into the command buffer, but ultimately this is not how we want to do it. As far as i could see from the cvs-logs the elts thing was added 17 hours ago, however i tested nwn earlier and the screenshots looked the same. So it seems that this change is not responsible for this weird looking. However i now can turn on reflection in neverball without an slowdown (before i had an slowdown). I disagree. I have done tests with glDrawElements and it gets horribly broken when more than one element buffer appears. Also in quake3(full version) menus, more random vertices appear when mouse isnt visible. Test found at: http://nu.rasterburn.org/~aet/idx_2.tar.bz2 clearly shows these problems. I dont get any lockups since about a week (which seems to be strange as many others get lockups), however i do not use xorg-cvs, but ubuntus xorg-package (seems to be the latest 6.8.2-beta) with the ati.patch from r300. Is this with vertex buffers turned on? If so, can you cause a lockup by moving a window over the top of the glxgears window? This is the only way I can cause a lockup with the vertex buffer code. I'm using xorg cvs from 1-2 days before the dlloader changes. This is the exact same bug i found before support for dma moves for vbs. I was able to reproduce one bug that might be related to this. I get lock up when starting glxgears in workspace 1 and switching to workspace 2. This also happens with DEBUG=1 unlike other bugs iv seen. Hmm i must test this with an earlier snapshot, then i will report back. Greetings Jan -- Aapo Tahkola --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
Hello, Adam K Kirchhoff wrote: These are the games I've tried with the latest CVS from this afternoon: [...] Frankly, I'm thrilled at the handful of games that are now working! Those who are looking for additional stress-test cases for OpenGL- (especially R300-, I don't have one myself) drivers, might take notice of this ready-to-run FlightGear package in: ftp://ftp.uni-duisburg.de/FlightGear/Devel/FGBenchmark-0.0.5.tar.gz (approx 76 MByte). The package includes binaries for IRIX/MIPS, Solaris/Sparc, Linux/x86 and FreeBSD-5.x/x86, a README is there as well: ftp://ftp.uni-duisburg.de/FlightGear/Devel/FGBenchmark.README This is, how the picture should look like after startup: http://document.ihg.uni-duisburg.de/bitmap/FGFS/KSFO-startup_01.jpg Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
Peter Zubaj wrote: For me looks like: If you uncoment r300 support in int radeon_do_cp_idle(drm_radeon_private_t * dev_priv) and in static void radeon_cp_dispatch_swap(drm_device_t * dev) x will work ok (no more locks or crash), but no 3d. Peter Zubaj Vsetko o SuperStar http://superstar.atlas.sk Well, X only locks up for me when using 3D. If I wanted that trade-off, I'd just disable DRI :-) Adam --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
Well, X only locks up for me when using 3D. If I wanted that trade-off, I'd just disable DRI :-) Adam Hi Adam, I forget - did I ask you to try immediate mode ? You can switch to it inside r300/r300_render.c, search for #if best Vladimir Dergachev --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
On Tue, 2005-02-15 at 02:36 -0500, Vladimir Dergachev wrote: AFAIK, the lockups are due to interference between 2d packets from Xserver and 3d packets from the driver. Somehow mouse movement provokes it, possibly when the cursor shape changes on crossing window boundaries.. It is not the mouse movement per se that induces the lockup, but the movement of the 2d cursor on a screen. Have you tried idling the engine before uploading the cursor data? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
On Tue, 15 Feb 2005, Michel [ISO-8859-1] Dnzer wrote: On Tue, 2005-02-15 at 02:36 -0500, Vladimir Dergachev wrote: AFAIK, the lockups are due to interference between 2d packets from Xserver and 3d packets from the driver. Somehow mouse movement provokes it, possibly when the cursor shape changes on crossing window boundaries.. It is not the mouse movement per se that induces the lockup, but the movement of the 2d cursor on a screen. Have you tried idling the engine before uploading the cursor data? I haven't played with that part of 2d driver, but shouldn't it do this already as all ATI cards are touchy about framebuffer access while the graphics engine is busy ? So far all we needed to get things working is the ugly hack in 2d driver that we discussed earlier plus the pacifier sequence which appears to be cache flush: reg_start(R300_RB3D_DSTCACHE_CTLSTAT,0); e32(0x000a); reg_start(0x4f18,0); e32(0x0003); best Vladimir Dergachev -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: R300 success stories
On Tue, 2005-02-15 at 11:36 -0500, Vladimir Dergachev wrote: On Tue, 15 Feb 2005, Michel [ISO-8859-1] Dnzer wrote: On Tue, 2005-02-15 at 02:36 -0500, Vladimir Dergachev wrote: AFAIK, the lockups are due to interference between 2d packets from Xserver and 3d packets from the driver. Somehow mouse movement provokes it, possibly when the cursor shape changes on crossing window boundaries.. It is not the mouse movement per se that induces the lockup, but the movement of the 2d cursor on a screen. Have you tried idling the engine before uploading the cursor data? I haven't played with that part of 2d driver, but shouldn't it do this already as all ATI cards are touchy about framebuffer access while the graphics engine is busy ? It arguably should, but it doesn't AFAICT. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
Have you tried idling the engine before uploading the cursor data? I haven't played with that part of 2d driver, but shouldn't it do this already as all ATI cards are touchy about framebuffer access while the graphics engine is busy ? It arguably should, but it doesn't AFAICT. That's what I thought when I encountered this last, however, both radeon and r200 drivers work fine and last time I had a mouse-triggerred issue it was due to some commands within R300 DRM driver lacking pacifier sequence. Once I put it back everything was stable again. So I have no idea what exactly happens when mouse cursor is updated. best Vladimir Dergachev -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
On Tue, 2005-02-15 at 12:08 -0500, Vladimir Dergachev wrote: Have you tried idling the engine before uploading the cursor data? I haven't played with that part of 2d driver, but shouldn't it do this already as all ATI cards are touchy about framebuffer access while the graphics engine is busy ? It arguably should, but it doesn't AFAICT. That's what I thought when I encountered this last, however, both radeon and r200 drivers work fine [...] There's this thing called luck... let's rule out the obvious suspects before worrying about more complex stuck. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
Ben Skeggs wrote: Hello, These are the games I've tried with the latest CVS from this afternoon: Neverputt and neverball play, but some debug output gets displayed: --snip-- :p You can get neverball working much more smootly by switching everything to low in the menu screen. Ignore the warn once messages, they're more of a reminder of what needs to be done still. Actually, I found neverputt to be quite playable at 1280x1024, even with everythying at high. With my 8500, the game was only playable at 1024x768, skipping at the next resolution up. Chromium works. UT, Marbleblast, and Orbz) die with: r300_check_render: fallback:ctx-Texture.Unit[i].Enabled I believe we're still only letting one texture pass through the pipeline, I'm not sure why the fallback is causing a segfault though. Q3A displays similar problems in the menu screen, and level loading screen, but dies once the level is loaded with the same Texture.Unit error. Quake2 is similar. You need to disable compiled vertex arrays, and multitexturing in your q3config.cfg file. Q3 should be very playable, with a couple of glitches. Hmmm... I made those changes. The game started up and loaded a level without problems. Unfortunately, within a few seconds Q3A had locked up. I could still ssh in and reboot though. I'm really quite thrilled that complete system lockups seem to be a thing of the past. Anyone want to comment on if we will see a day when an application which locks up can just be killed and X returns to normal? :-) Frankly, I'm thrilled at the handful of games that are now working! Adam Great! Thankyou for testing on some (afaik) untested programs. Cheers, Ben Skeggs. No problems. I have a few others I can try (ie. doom3, ut2004), too. Adam --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
Vladimir Dergachev wrote: UT, Marbleblast, and Orbz) die with: r300_check_render: fallback:ctx-Texture.Unit[i].Enabled Could you disable multitexturing in these games ? I see an option for MarbleBlast called disableARBMultitexture. I'll try enabling that when I get home this evening and give it another shot. Adam --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
Hello Adam, You need to disable compiled vertex arrays, and multitexturing in your q3config.cfg file. Q3 should be very playable, with a couple of glitches. Hmmm... I made those changes. The game started up and loaded a level without problems. Unfortunately, within a few seconds Q3A had locked up. I could still ssh in and reboot though. I'm really quite thrilled that complete system lockups seem to be a thing of the past. Anyone want to comment on if we will see a day when an application which locks up can just be killed and X returns to normal? :-) Is the Q3A lockup repeatable 100% of the time? I've been attempting to find the source of a lockup Vladimir reported, which seems to be related to mouse movement, but I haven't been able to reproduce it yet. No problems. I have a few others I can try (ie. doom3, ut2004), too. Adam ut2004 demo will start after messing with the config file options a bit, and disabling the multitexture fallback (ut2004-demo doesn't seem to respect it's MaxTextureUnits option). However, it seems to be horribly corrupted in game, much the same as quake3 is when r_ext_compiled_vertex_array is set. I haven't tried doom3 yet, and won't be able to now until there is a 64-bit version, or the drm has support for 32-bit clients. Thanks again! Ben Skeggs. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
Ben Skeggs wrote: Hello Adam, You need to disable compiled vertex arrays, and multitexturing in your q3config.cfg file. Q3 should be very playable, with a couple of glitches. Hmmm... I made those changes. The game started up and loaded a level without problems. Unfortunately, within a few seconds Q3A had locked up. I could still ssh in and reboot though. I'm really quite thrilled that complete system lockups seem to be a thing of the past. Anyone want to comment on if we will see a day when an application which locks up can just be killed and X returns to normal? :-) Is the Q3A lockup repeatable 100% of the time? I've been attempting to find the source of a lockup Vladimir reported, which seems to be related to mouse movement, but I haven't been able to reproduce it yet. I only tried once, last night before bed. I'll let you know if I can reproduce it this evening. No problems. I have a few others I can try (ie. doom3, ut2004), too. Adam ut2004 demo will start after messing with the config file options a bit, and disabling the multitexture fallback (ut2004-demo doesn't seem to respect it's MaxTextureUnits option). However, it seems to be horribly corrupted in game, much the same as quake3 is when r_ext_compiled_vertex_array is set. I haven't tried doom3 yet, and won't be able to now until there is a 64-bit version, or the drm has support for 32-bit clients. So at what point does it make sense move r300 development into Mesa? Adam --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
Adam K Kirchhoff wrote: Ben Skeggs wrote: Hello Adam, You need to disable compiled vertex arrays, and multitexturing in your q3config.cfg file. Q3 should be very playable, with a couple of glitches. Hmmm... I made those changes. The game started up and loaded a level without problems. Unfortunately, within a few seconds Q3A had locked up. I could still ssh in and reboot though. I'm really quite thrilled that complete system lockups seem to be a thing of the past. Anyone want to comment on if we will see a day when an application which locks up can just be killed and X returns to normal? :-) Is the Q3A lockup repeatable 100% of the time? I've been attempting to find the source of a lockup Vladimir reported, which seems to be related to mouse movement, but I haven't been able to reproduce it yet. I only tried once, last night before bed. I'll let you know if I can reproduce it this evening. It's definitely reproducable for me.And, as far as I can tell, it doesn't have anything to do with mouse movement... I kicked off a demo run (four.dm_68)... Didn't touch the mouse after it started. It ran right up till the character I was viewing as died. The scoreboard even popped up, and then I got the lockup. Adam --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
movement, but I haven't been able to reproduce it yet. I only tried once, last night before bed. I'll let you know if I can reproduce it this evening. It's definitely reproducable for me.And, as far as I can tell, it doesn't have anything to do with mouse movement... I kicked off a demo run (four.dm_68)... Didn't touch the mouse after it started. It ran right up till the character I was viewing as died. The scoreboard even popped up, and then I got the lockup. AFAIK, the lockups are due to interference between 2d packets from Xserver and 3d packets from the driver. Somehow mouse movement provokes it, possibly when the cursor shape changes on crossing window boundaries.. It is not the mouse movement per se that induces the lockup, but the movement of the 2d cursor on a screen. best Vladimir Dergachev Adam --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
For me looks like: If you uncoment r300 support in int radeon_do_cp_idle(drm_radeon_private_t * dev_priv) and in static void radeon_cp_dispatch_swap(drm_device_t * dev) x will work ok (no more locks or crash), but no 3d. Peter Zubaj Vsetko o SuperStar http://superstar.atlas.sk --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
Hello, These are the games I've tried with the latest CVS from this afternoon: Neverputt and neverball play, but some debug output gets displayed: --snip-- :p You can get neverball working much more smootly by switching everything to low in the menu screen. Ignore the warn once messages, they're more of a reminder of what needs to be done still. Chromium works. UT, Marbleblast, and Orbz) die with: r300_check_render: fallback:ctx-Texture.Unit[i].Enabled I believe we're still only letting one texture pass through the pipeline, I'm not sure why the fallback is causing a segfault though. Q3A displays similar problems in the menu screen, and level loading screen, but dies once the level is loaded with the same Texture.Unit error. Quake2 is similar. You need to disable compiled vertex arrays, and multitexturing in your q3config.cfg file. Q3 should be very playable, with a couple of glitches. Frankly, I'm thrilled at the handful of games that are now working! Adam Great! Thankyou for testing on some (afaik) untested programs. Cheers, Ben Skeggs. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
UT, Marbleblast, and Orbz) die with: r300_check_render: fallback:ctx-Texture.Unit[i].Enabled Could you disable multitexturing in these games ? GLTron and Blender die with: r300_check_render: fallback:ctx-Line.SmoothFlag Don't know about this one - see what happens when you comment out this fallback. NWN starts up, and doesn't crash, but is definitely unplayable: http://68.44.156.246/nwn.png (warning: 1 meg PNG on a slow connection). Q3A displays similar problems in the menu screen, and level loading screen, but dies once the level is loaded with the same Texture.Unit error. Quake2 is similar. Q3A works if you disable certain features in q3aconfig file - (go to .q3a/base3q/q3aconfig) - check r300_dri webpage for suggestions. best Vladimir Dergachev Frankly, I'm thrilled at the handful of games that are now working! Adam --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
