Radeon Driver Default Display Resolution

Roland Scheidegger sroland at tungstengraphics.com
Tue Apr 1 16:00:17 PDT 2008

Hamish wrote:
> On Tuesday 01 April 2008 13:10:49 you wrote:
>> On Tue, Apr 1, 2008 at 4:41 AM, Hamish <hamish at travellingkiwi.com> wrote:
>>> On Monday 31 March 2008 23:36:15 you wrote:
>>>  > On Mon, Mar 31, 2008 at 11:07 AM, Hamish <hamish at travellingkiwi.com>
>>>  > wrote:
>>>  [deleted]
>>>  > >  On the same vein... I find my X600 to be really really slow..
>>>  > > Painfully slow. Could that be due to too a large desktop
>>>  > > (2704x1050)? Or am I doing something wrong? Is an X600 just a slow
>>>  > > card? I thought it should be good enought for compiz even... But
>>>  > > only if you're prepared for several seconds wait whenever focus
>>>  > > changes...
>>>  >
>>>  > The coordinate limits of the 3D engine are 2560x2560 and the max
>>>  > texture size is 2048x2048.  Beyond these limits you are left with
>>>  > basic 2D accel, which doesn't do much for modern desktops.  For now
>>>  > you'll probably have better luck with XAA if you were using EXA.
>>>  That 2560x2560... Is that a hardware or software limit? If I upgraded
>>> the card to a 3650 or 3850 would there still be these limits? (I tried
>>> EXA for about 10 minutes... That was unusable... You could see the window
>>> scrolling... Slower than an old XT (I mean PC-XT) with 80x25 green
>>> screen).
>> It's a HW limit.  r6xx chips support 8k surfaces, but there's no 3D support
>> yet.
>>>  However I also tried a virtual desktop of 2048x1050... And got two
>>> display of 1024 width. And the X600 was just as slow then as it was with
>>> the 2704 virtual width. (I verified the 2048 virtual width by attempting
>>> to resize the large monitor to 1680x1050, and got the xrandr error that
>>> the virtual size was only 2048).
>> When you say slow what do you mean?  compiz? something else?  I
>> regularly use large dualhead desktops and performance is fine.
> Ah. Everything basically... Exceot maybe moving static windows (e.g. xterm) 
> around and drawing text... For example compiz you can see updating the 
> windows. Moving focus with transparency changes is a couple of seconds per 
> change.
>>>  I ran up oprofile... But gentoo strips libGL and the only info it gives
>>> me at the moment is that any app spends all it's time somewhere in there.
>>> Even if it's only a 1024x768 window... (I take it the 3D engine is
>>> disabled completely is the screen area is over the limits, rather than on
>>> a per-window/GLXContext basis?
>> what sort of app are you running?  if it's libGL, presumably you are
>> using some sort of GL desktop or application.
> Ah. It's an openGL app I wrote. It displays textures (Loaded as png's) in a 4 
> sided cube (No top or bottom). The textures are rrd graphs... 
> On an nvidia 8600GTS I get > 50fps with FSAA enabled and about 2% CPU with 
> about 1100x900 window size (Without FSAA I can get the full dual display @ > 
> 50fps and a few % CPU). With X1400 (Which should be not a lot faster than the 
> X600 according to raw stats?) and fglrx drivers I can get 1680x1050 full 
> screen at > 50fps almost 0% CPU.
> But with he X600 I get 100% CPU utilisation, somewher between 0 - 1 fps (And 
> the textures all display as a grey rectangle as well, but I'll try & solve 
> the speed first since I have an older version that the textures work, but 
> just as slow).
> I ran up sysprof. And according to it I get most of the time spent between 
> radeonWriteDepthSpan_z24_s8, radeonReadDepthSpan_z24_s8, and 
> radeonReadRGBASpan_ARGB8888. Then a little bit of time (e.g about 1/20 of the 
> total) in sample_2d_linear and a couple of other routines... But the majority 
> in those 3 top routines from libGL.
> I'll have to peruse the sources from mesa to know what those all do...  AM I 
> killing things by running at a depth of 24bits? Should I bet at 32? (The 
> config was written by X -configure because of the original config I had 
> caused a blank screen).

Looks like software rasterizer fallbacks. Hard to tell without knowing
the app - you should get a warning though on stderr the first time this


More information about the xorg mailing list