Radeon Driver Default Display Resolution

[Roland Scheidegger]

Hamish wrote:
> On Wednesday 02 April 2008 12:00:11 Roland Scheidegger wrote:
>> Hamish wrote:
>>> On Wednesday 02 April 2008 00:00:17 you wrote:
> 
> [deleted]
> 
>>>> 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).
>>
> 
> God-damn! It was line smoothing... Buggering up not only the speed (50fps down 
> to 0fps) but stopping the rendering of the textures properly too (Grey blobs 
> instead of the textures I'd loaded from png's). I now have 50fps at almost 0% 
> CPU again.
> 
> Funny thing is I only had 4 straight lines in the whole display... The driver 
> seems to fallback to (Broken?) software rendering of textures as well. Is 
> that an expected feature? Or a genuine bug? The message I got
> 
> *********************************WARN_ONCE*********************************
> File r300_render.c function r300Fallback line 471
> Software fallback:ctx->Line.SmoothFlag
> ***************************************************************************
> 
> I assumed meant that rendering smoothed lines would be slow... I didn't 
> anticipate that the whole acceleration would be canned and I'd get software 
> rendering for everything.

I think the problem is that the fallback doesn't actually care if you
really draw lines or not - so as long as you have smooth lines enabled
even "normal" tris which aren't affected at all by that smooth flag will
go through swrast. That's probably not an ideal solution...
Not sure though why it didn't work - swrast should be slow but correct.
But fallbacks are sometimes a bit problematic...

Roland