Radeon Driver Default Display Resolution

[Roland Scheidegger]

Hamish wrote:
> On Wednesday 02 April 2008 00:00:17 you wrote:
>> 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 happens.
>> 
> 
> Hm... I get one warning for software fallback of smoothed lines
> IIRC... But I ignored it because I only use lines in 2 places... I
> assumed that the textures would continue with hardware
> acceleration... Or could it be because I request max anisotropic
> filtering (16 on
16x aniso should be pretty cheap. Even fallbacks in a only a few places
can have a quite large performance impact. Use driconf or
disable_lowimpact_fallback=true to switch it off (or just don't use aa
lines).

> I tried 32bits display depth (Because I know fglrx only did 32 last
> time I tried it)... Apparently the radeon driver doesn't support 32,
> So fell back to 24 only.
It's pretty much the same anyway. One counts the alpha channel the other
doesn't.

Roland