E-450 graphics performance issues

[agd5f]

What are they written in?

GPU shader assembly.

[curaga]

http://cgit.freedesktop.org/xorg/dri.../r600_shader.c

Yay. Is there no way to dump that from mesa?

[curaga]

Re the static thing, there were a total of ~90 functions and structs that should've been static and weren't, yikes Let's see if this becomes one's first kernel code.

[agd5f]

http://cgit.freedesktop.org/xorg/dri.../r600_shader.c

Yay. Is there no way to dump that from mesa?

If you mean integrate the shader compiler from mesa into the ddx, that is a lot of work. If you mean use the 3D driver to generate the GPU asm, that should be possible. You'll have to write the program in either GLSL or TGSI, then you can dump the shaders. Afterwards they may require a bit of tweaking to handle differences in pipeline state between the 3D driver and the ddx.

[curaga]

If you mean integrate the shader compiler from mesa into the ddx, that is a lot of work. If you mean use the 3D driver to generate the GPU asm, that should be possible. You'll have to write the program in either GLSL or TGSI, then you can dump the shaders. Afterwards they may require a bit of tweaking to handle differences in pipeline state between the 3D driver and the ddx.

The latter, yes.

[ssvb]

It's not really an issue with 2D vs. 3D engines. 2D engines suck for RENDER too. The reason vesa or old drivers seem faster for certain things is because they use shadowfb or XAA (which ends up being shadowfb because offscreen acceleration has been disabled for years due to bit rot in XAA). Shadowfb is pure software rendering. Pure CPU rendering is almost always faster than mixed CPU/GPU rendering since there is no ping-ponging between GPU and CPU rendering.

You can enable shadowfb in the radeon driver if you want to compare by setting Option "NoAccel" "True" in the device section of your xorg config.

Option "NoAccel" "True" also disables Xv acceleration, rendering this driver configuration not very useful in practice. But indeed it performs roughly the same as xf86-video-fbdev.

Option "RenderAccel" "False" could be potentially interesting, except that it makes xf86-video-ati-6.14.6 slower than xf86-video-fbdev for me (unfortunately no E-450 here, just Intel Core i7 860 + Radeon HD 6770):

old: fbdev
new: ati-norenderaccel
Speedups
========
 xlib          xfce4-terminal-a1  3418.55 (3418.83 0.78%) -> 2878.58 (2893.62 0.72%):  1.19x speedup
▎
Slowdowns
=========
 xlib          firefox-asteroids  4320.09 (4324.56 1.87%) -> 4587.17 (4597.68 1.00%):  1.06x slowdown

 xlib              chromium-tabs  145.03 (145.58 8.13%) -> 161.65 (162.10 3.91%):  1.11x slowdown
▏
 xlib          firefox-particles  67684.50 (67720.43 0.05%) -> 78508.14 (78510.06 0.05%):  1.16x slowdown
▏
 xlib             grads-heat-map  175.32 (175.54 6.12%) -> 211.18 (211.68 4.02%):  1.20x slowdown
▎
 xlib       firefox-planet-gnome  6715.22 (6726.93 1.44%) -> 8711.32 (8755.91 0.66%):  1.30x slowdown
▎
 xlib          firefox-talos-gfx  15171.14 (15172.71 0.35%) -> 22849.30 (22902.49 0.19%):  1.51x slowdown
▌
 xlib                  evolution  1378.87 (1382.31 6.99%) -> 2249.10 (2250.09 2.28%):  1.63x slowdown
▋
 xlib                    poppler  1524.61 (1559.51 9.64%) -> 2549.49 (2576.42 1.60%):  1.67x slowdown
▋
 xlib             poppler-reseau  460.96 (461.49 1.55%) -> 899.66 (900.38 0.89%):  1.95x slowdown
█
 xlib         gnome-terminal-vim  2255.49 (2260.89 1.33%) -> 5221.35 (5224.08 0.53%):  2.31x slowdown
█▍
 xlib                  ocitysmap  1198.46 (1199.31 1.59%) -> 2847.14 (2848.15 1.12%):  2.38x slowdown
█▍