radeon 9600se?
I have xorg.conf set up to use radeon driver with big desktop mode and xinerama. It works fine, but I want acceleration. So am I correct in saying all I need to do is # Load dri Load glx uncomment the dri load, and make install your modules? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon 9600se?
Hi, No, you are not correct. You need cvs version of xorg, cvs version of mesa and cvs version of r300 driver from r300.sf.net. r300 driver is still in alpha stage (it can lock or crash your computer). Peter Zubaj Najdi svojich spoluziakov! http://www.spoluziak.sk --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Radeon 9600se mostly working..
On Monday 21 February 2005 17:40, John Clemens wrote: On Mon, 21 Feb 2005, John Clemens wrote: give it a go on my fanless 9600se (RV350 AP). How much memory do you have ? What kind of CPU and motherboard ? Duron 1.8G, 256MB ddr, old(ish) via km266 motherboard in a shuttle sk41g. Gentoo. The card has 128Mb ram. - glxinfo states r300 DRI is enabled. (AGP4x, NO-TCL) - glxgears gives me about 250fps with drm debug=1, ~625fps without debug on. should I be concerned that these fps are too low? others seem to be reporting around 1000.. Well, I'm not sure about the value with debug off, it does seem rather low, but perhaps reasonable if you are using immediate mode (which is still the default in CVS, I believe - check r300_run_render in r300_render.c). Your debug FPS is rather high, actually - I only get around 50fps in glxgears with enabled DRM debugging (even less if I also enable debug messages from the userspace driver). - tuxracer runs ok at 640x480 fullscreen - ice textures look psychadelicly blue - at 1280x1024, (and somewhat at 800x600 windowed), i get these errors: [drm:radeon_cp_dispatch_swap] *ERROR* Engine timed out before swap buffer blit ... The swap buffer blit is just a copy - for example a copy from back buffer to front buffer. Since the engine timed out before swap buffer blit it means that the commands before it were at fault. Which is puzzling as you point out that everything works in 640x480. Just to elaborate: 640x480 runs fine. at 800x600 windowed, it plays fine, but if a scene gets more complicated i see some jerkyness.. i.e., the scene freezes for a second or two and then jumps ahead, and i get a few messages in the log. At 1280x1024, this happens all the time, so it appears the game is locked, and I get a stream of those messages in the log file. alt-F switching to the console works, and switching back i get about 2 seconds more of movement, and then soft-lock again (persumably because the card re-inits on VC switch). I can switch to the VC and kill it and all's fine. Judging from what you're saying, the card isn't locked, it just isn't able to draw a full scene before it times out. Well, this is certainly interesting, and it does sound like userspace is generating so many drawing commands that the card is simply too slow to process them all. My guess is that the one-two second freezes are causes by the X server when it, too, thinks that the engine has timed out and initiates a reset sequence. This is actually an interesting problem. Here are some issues to think about: 1) The SWAP ioctl should really report an error to userspace when the engine has timed out. 2) I agree that it would make sense to monitor the ring buffer somehow. Perhaps a wait_for_ringbuffer that is called at the top of wait_for_fifo? In the fast path, this costs an additional I/O read operation, otherwise it should be essentially be no different performance-wise. 3) Come to think of it, couldn't the card just issue an IRQ when it's done? 4) If a drawing command takes very long, can we identify the userspace process that is responsible for sending the command buffer that caused the delay, and can we deal with this process somehow? Perhaps we could insert an age marker before and after the processing in the command buffer ioctl. The last point actually touches on a bigger subject: scheduling access to the graphics card. To get an idea of what I'm talking about, launch a terminal emulator and glxgears side by side. Then run yes in the terminal emulator. glxgears will essentially lock up. cu, Nicolai pgpRFAJMWkcWT.pgp Description: PGP signature
Re: [r300] Radeon 9600se mostly working..
Hi John, Thank you for testing :)) More below. On Mon, 21 Feb 2005, John Clemens wrote: So I've been lurking for a while following the r300 work and decided to give it a go on my fanless 9600se (RV350 AP). How much memory do you have ? What kind of CPU and motherboard ? - glxinfo states r300 DRI is enabled. (AGP4x, NO-TCL) - glxgears gives me about 250fps with drm debug=1, ~625fps without debug on. - tuxracer runs ok at 640x480 fullscreen - ice textures look psychadelicly blue - at 1280x1024, (and somewhat at 800x600 windowed), i get these errors: [drm:radeon_cp_dispatch_swap] *ERROR* Engine timed out before swap buffer blit Any pointers on what causes that? This is with Xorg cvs, Mesa cvs, r300 cvs, as of 4 hours ago. I'm guessing the X server or mesa isn't filling the buffer up fast enough at higher resolutions...but I'm new to devlopment so i don't know which buffer that would be.. The swap buffer blit is just a copy - for example a copy from back buffer to front buffer. Since the engine timed out before swap buffer blit it means that the commands before it were at fault. Which is puzzling as you point out that everything works in 640x480. I wonder whether the lockup detection logic is at fault - we simply wait a fixed amount of time for the engine to become idle. Perhaps it would be better to actually monitor the CP engine progress, for example by looking for changes in current ring pointer (i.e. wait and check whether the value changed). If the ring pointer does not change declare a lockup. What does everyone think ? thank you Vladimir Dergachev thanks, john.c -- John Clemens http://www.deater.net/john john at deater.net I Hate Quotes -- Samuel L. Clemens --- 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] Radeon 9600se mostly working..
Hi Vladimir, On Mon, 21 Feb 2005, John Clemens wrote: give it a go on my fanless 9600se (RV350 AP). How much memory do you have ? What kind of CPU and motherboard ? Duron 1.8G, 256MB ddr, old(ish) via km266 motherboard in a shuttle sk41g. Gentoo. The card has 128Mb ram. - glxinfo states r300 DRI is enabled. (AGP4x, NO-TCL) - glxgears gives me about 250fps with drm debug=1, ~625fps without debug on. should I be concerned that these fps are too low? others seem to be reporting around 1000.. - tuxracer runs ok at 640x480 fullscreen - ice textures look psychadelicly blue - at 1280x1024, (and somewhat at 800x600 windowed), i get these errors: [drm:radeon_cp_dispatch_swap] *ERROR* Engine timed out before swap buffer blit ... The swap buffer blit is just a copy - for example a copy from back buffer to front buffer. Since the engine timed out before swap buffer blit it means that the commands before it were at fault. Which is puzzling as you point out that everything works in 640x480. Just to elaborate: 640x480 runs fine. at 800x600 windowed, it plays fine, but if a scene gets more complicated i see some jerkyness.. i.e., the scene freezes for a second or two and then jumps ahead, and i get a few messages in the log. At 1280x1024, this happens all the time, so it appears the game is locked, and I get a stream of those messages in the log file. alt-F switching to the console works, and switching back i get about 2 seconds more of movement, and then soft-lock again (persumably because the card re-inits on VC switch). I can switch to the VC and kill it and all's fine. Judging from what you're saying, the card isn't locked, it just isn't able to draw a full scene before it times out. Who is responsible for drawing to this buffer? r300, mesa or x? I just grabbed the CVS trees and did a make, I think mesa by default might be compiled with -O -g, would it be better to recomile it with just -O2? I wonder whether the lockup detection logic is at fault - we simply wait a fixed amount of time for the engine to become idle. Perhaps it would be better to actually monitor the CP engine progress, for example by looking for changes in current ring pointer (i.e. wait and check whether the value changed). If the ring pointer does not change declare a lockup. What does everyone think ? Seems reasonable. What's the downside if you if you swap a half-draw buffer to the fore and then start drawing a new one? tearing? john.c -- John Clemens http://www.deater.net/john john at deater.net I Hate Quotes -- Samuel L. Clemens --- 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
[r300] Radeon 9600se mostly working..
So I've been lurking for a while following the r300 work and decided to give it a go on my fanless 9600se (RV350 AP). - glxinfo states r300 DRI is enabled. (AGP4x, NO-TCL) - glxgears gives me about 250fps with drm debug=1, ~625fps without debug on. - tuxracer runs ok at 640x480 fullscreen - ice textures look psychadelicly blue - at 1280x1024, (and somewhat at 800x600 windowed), i get these errors: [drm:radeon_cp_dispatch_swap] *ERROR* Engine timed out before swap buffer blit Any pointers on what causes that? This is with Xorg cvs, Mesa cvs, r300 cvs, as of 4 hours ago. I'm guessing the X server or mesa isn't filling the buffer up fast enough at higher resolutions...but I'm new to devlopment so i don't know which buffer that would be.. thanks, john.c -- John Clemens http://www.deater.net/john john at deater.net I Hate Quotes -- Samuel L. Clemens --- 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
