[Openchrome-devel] Another openchrome drm segfault

[Thomas Hellström]

Xavier Bachelot wrote:
> Thomas Hellstr?m wrote:
>   
>> Xavier Bachelot wrote:
>>     
>
>   
>>> Today, the issue with 3D is a bit different. glgears works (370 fps,
>>> which is about half what I have with the old unichrome_dri), but all 3D
>>> software are crashing because the openchrome driver tries to use some
>>> SSE instructions and my CPU can't do that, although the lack of SSE is
>>> correctly acknowledged in the xorg log...
>>>
>>>   
>>>       
>> OK. that gives me a place to look.
>>
>> More questions to help the performance up:
>>
>> What system is this? CPU? cache size? Chipset?
>>     
> # cat /proc/cpuinfo
> processor       : 0
> vendor_id       : AuthenticAMD
> cpu family      : 6
> model           : 4
> model name      : AMD Athlon(tm) processor
> stepping        : 2
> cpu MHz         : 1099.960
> cache size      : 256 KB
> fdiv_bug        : no
> hlt_bug         : no
> f00f_bug        : no
> coma_bug        : no
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 1
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
> cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow up
> bogomips        : 2199.92
> clflush size    : 32
> power management:
>
> Chipset is KM400A.
>
>   
>> What kind of cpu usage are you seeing with the new 3D driver and gears?
>> system / user?
>>
>>     
> 40% user / 20% system / 370 fps
>
>   
>> What happens if you issue
>> echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
>> as root, and rerun gears?
>>
>>     
> This proc doesn't support cpufreq.
>
>   
>> What happens if you load the openchrome kernel module using
>> modprobe openchrome disable_verifier=1
>> before starting X.
>>
>>     
> 35% user / 13% system / 430 fps
>
> With the via drm and regular openchrome driver, mesa, etc..., I have :
> 30% user / 70% system / 470 fps
>
> It seems I had the number wrongs, it's nowhere near half the
> performances, but it's still noticeably below. The cpu usage is way
> better though, with or w/o the command verifier.
>   
Yes. For applications that has a complex geometry, newer mesa versions 
are slower for some reason.
There is a clear difference between mesa 6.4 and mesa 6.5. Could also be 
the screen resolution consuming memory bandwidth.

In the gears case, we're seeing above, the GPU commands should be more 
or less the same, so it looks like the new 3D driver is stalled a little 
in command submission. It uses the new linux high resolution timers to 
avoid tight polling loops. The old driver always did busy waiting, hence 
the high CPU usage.

It's probably possible to tweak this a bit to get the last 40 fps, but 
usually, it's good to get the CPU usage down.

/Thomas

> Regards,
> Xavier
>
>