Bug 42117

With KMS enabled, problem does not exists.

Is there some reason why you want to use UMS?  It's not really supported any more.

Well, yes, ums is about 2x faster then kms.

I think the problem is somewhere in textures. Lowering texture quality in openarena, fps jumps from 5 to 60. The same with etracer, with low res textures copied from version 3.5, fps jumps from 3 to 30.

Some performance difference is expected due to kms not supporting tiling on r200, though I would expect a 2x difference only if you also enabled hyperz manually.
That said, if performance jumps a lot higher with lower texture settings, this looks like a problem with bo placement/migration, the old code was simple and terrible in some cases (could easily get texture thrashing) whereas the new code is different (but still not smart enough). In any case, if you don't have libtxc installed try that as openarena can use it and hence textures will use much less vram. If you have some compositing manager running try disabling it as it will also use more memory. Though if you have some terribly memory-constrained chip nothing might help much (should really have at least 64MB vram).

As for the ums problem, it looks like the driver is hitting a software fallback. RADEON_DEBUG=fall might tell you why - not that there's any chance it will get fixed...

I am leaning to believe that tiling can make such a difference.

In tests I'm using fluxbox without any compositing. My card is radeon 9100 (rebranded 8500) with 128mb vram. Libtxc library didn't change anything.

RADEON_DEBUG=fall puts in loop:
R200 begin tcl fallback Rasterization fallback
R200 begin rasterization fallback: 0x1 Texture mode
R200 end tcl fallback Rasterization fallback
R200 end tcl fallback
R200 end rasterization fallback: 0x1 Texture mode
R200 begin tcl fallback Rasterization fallback
R200 begin rasterization fallback: 0x1 Texture mode
R200 end tcl fallback Rasterization fallback
R200 end tcl fallback
R200 end rasterization fallback: 0x1 Texture mode

I forget to add. In openarena, i get about 2-4 fps in normal play but when I look down to ground, fps immediately jumps to about 80.

Yes that's a fallback. Not sure why it would trigger texture mode fallback.
You could try attaching a debugger and see where r200Fallback gets that true mode bit and work from there, could be from several functions.
But these ums pieces are going to get away very soon so chances someone going to fix it are slim.

Breakpoint 1, r200Fallback (ctx=0x8381c10, bit=1, mode=1 '\001')
    at r200_swtcl.c:678
678        r200ContextPtr rmesa = R200_CONTEXT(ctx);
(gdb) where
#0  r200Fallback (ctx=0x8381c10, bit=1, mode=1 '\001') at r200_swtcl.c:678
#1  0xb63b2dbd in r200WrapRunPipeline (ctx=0x8381c10) at r200_state.c:2449
#2  0xb648f1ee in _tnl_draw_prims (ctx=0x8381c10, arrays=0x83c5804, 
    prim=0x83c42d8, nr_prims=1, ib=0x0, min_index=0, max_index=3)
    at tnl/t_draw.c:478
#3  0xb648f4f9 in _tnl_vbo_draw_prims (ctx=0x8381c10, arrays=0x83c5804, 
    prim=0x83c42d8, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', 
    min_index=0, max_index=3) at tnl/t_draw.c:384
#4  0xb648709f in vbo_exec_vtx_flush (exec=0x83c41a8, unmap=1 '\001')
    at vbo/vbo_exec_draw.c:384
#5  0xb6484d50 in vbo_exec_FlushVertices_internal (ctx=0x8381c10, 
    unmap=1 '\001') at vbo/vbo_exec_api.c:872
#6  0xb6484f3b in vbo_exec_FlushVertices (ctx=0x8381c10, flags=1)
    at vbo/vbo_exec_api.c:906
#7  0xb646995c in _mesa_BindTexture (target=3553, texName=92)
    at main/texobj.c:1058
#8  0x080612bb in draw_sky (pos=...) at course_render.cpp:377
#9  0x0808ca8b in Racing::loop (this=0x929dde0, timeStep=9.99999982e-14)
    at racing.cpp:375
#10 0x0807592b in main_loop () at loop.cpp:178
#11 0x08095f75 in winsys_process_events () at winsys.cpp:304
#12 0x08076444 in main (argc=1, argv=0xbf845c24) at main.cpp:307

It should be much easier to add tiled support to radeon and r200 with KMS after we drop DRI1 support since we can just blit to a linear buffer if the CPU needs to access a tiled buffer.

So the fallback must come from r200ValidateState() - which in turn means r200ValidateBuffers() and that means radeon_cs_space_check_with_bo() is failing.
So seems like validation fails because it's either over the vram or gart limit. Not sure the calculation there is really fully correct for non-kms, but you could check the limit values used for these (radeonScreen->gartTextures.size and radeonScreen->texSize[0], should be the same as csm->gart_limit and csm->vram_limit in radeon_cs_do_space_check()) - both values actually come from the ddx. Maybe your gart setting is too low.

As Alex said though we should fix tiling for the kms case.

Breakpoint 1, 0xb7e07f93 in radeon_cs_set_limit () from /usr/lib/libdrm_radeon.so.1
(gdb) s
Single stepping until exit from function radeon_cs_set_limit,
which has no line number information.
rcommonInitCmdBuf (rmesa=0x837c8d8) at radeon_common.c:1297
1297                    radeon_cs_set_limit(rmesa->cmdbuf.cs, RADEON_GEM_DOMAIN_GTT, rmesa->radeonScreen->gartTextures.size);
(gdb) print rmesa->radeonScreen->texSize[0]
$7 = 109051904
(gdb) print rmesa->radeonScreen->gartTextures.size
$8 = 5111808

values equal to this from Xlog

bash-4.1$ cat /var/log/Xorg.0.log |grep textures
[    42.691] (II) RADEON(0): Using 5 MB for GART textures
[    42.691] (II) RADEON(0): Will use 106496 kb for textures at offset 0x1800000
bash-4.1$ cat /var/log/Xorg.0.log |grep GART    
[    42.691] (II) RADEON(0): Using 8 MB GART aperture
[    42.691] (II) RADEON(0): Using 5 MB for GART textures
[    42.716] (II) RADEON(0): [agp] GART texture map handle = 0xe0302000
[    42.717] (II) RADEON(0): [agp] GART Texture map mapped at 0xae7fd000
[    42.964] (II) RADEON(0): [drm] Initialized kernel GART heap manager, 5111808




radeon_cs_do_space_check() - gdb with breakpoint to it never stops/breaks

csm->gart_limit and csm->vram_limit are correct.

With GARTSize "64", openarena works great. ETRacer does not (but no fallbacks)
In ETRacer, when I disabled show fps in options, after few seconds on the map, framerate back to normal.

(In reply to comment #12)
> csm->gart_limit and csm->vram_limit are correct.
> 
> With GARTSize "64", openarena works great. ETRacer does not (but no fallbacks)
> In ETRacer, when I disabled show fps in options, after few seconds on the map,
> framerate back to normal.

I'd have thought 128MB VRAM should be enough for openarena so it wouldn't need gart for textures, especially with texture compression. So I don't know why that's really needed looks like something is wrong. You could also try FBTexPercent option though given that I think there should be plenty of vram I don't think it's going to make a difference neither.

Minimum GARTSize which don't return fallbacks is 16MB.
Now, the problem is somewhere at the kernel side.

  samples|      %|
------------------
  1295082 93.6410 vmlinux
    30154  2.1803 r200_dri.so
    19269  1.3932 etracer
    15854  1.1463 radeon

samples  %        symbol name
1261238  97.3867  __copy_from_user_ll
1495      0.1154  delay_tsc

FBTexPercent to 97
bash-4.1$ cat /var/log/Xorg.0.log|grep text
[  8077.238] (II) RADEON(0): Will use 114688 kb for textures at offset 0x00c08000

etracer runs smoothly at 40 fps(with mesa 7.5.2 60fps).

 I tried etracer also with 7.5.2 UMS and have problems with 1024x1024 textures and run in a few fps.

 But current KMS with 8.0-devel mesa haven't that problem and etracar (with defaut textures) skies smooth there.

 I have enabled ColorTiling, vblank_mode=3 in dri2 drirc, EXAVSync on, SwapbuffersWait on and with in use vsynced aiglx/composite.

xf86-video-ati 6.14.4 supposedly added KMS tiling
https://wiki.freedesktop.org/xorg/radeon/

Could this get performance back to a satisfactorily enough level that we can consider this nonetheless fixed?

Or.. Why here instead the thing is still crossed out?
https://www.x.org/wiki/RadeonFeature/