Comment=
# 4
on bug 98239<=
/a>
from <=
span class=3D"fn">almos
(In reply to Marek Ol=C5=A1=C3=A1k from comment #3)
> Things to try:
>=20
> 1) You can try increasing the IB size in radeon_drm_cs.h:
> struct radeon_cs_context {
> uint32_t buf[16 * 1024]; // HERE
>=20
> 2) Add buffer-wait-time to the HUD and see if it corresponds with the
> flushes.
I tried it with 4x larger buf. The flushes are reduced to 4-5 instead of ar=
ound
15, but the performance and gpu-load remained mostly the same. It feels a b=
it
smoother, and the fps seems more consistent, but I didn't compare it
thoroughly. It seems the flush count is not a cause, but a symptom.
With 8x larger buf all textures are missing.
I also tried to monitor other data sources (e.g. dma), but nothing seems to=
be
as correlated with the fps as the gpu-load is. The buffer-wait-time somewhat
resembles, but not always.
BTW sr3 produces other interesting things, for example when starting up I g=
et
15fps in the main menu, but after loading a game, and exiting to the main m=
enu
I get 120fps.
I also checked other games for gpu-load, and here are the results (none of =
them
are cpu-bound):
- furmark: 100% load, fps 105-115 sinusoid (its period is different from the
rotation of the doughnut, might be worth checking this out)
- amnesia: solid 60fps regardless of the vsync setting, load is 20-30%
- heaven 4: the load is 80-100% perfectly correlated to fps
- quake wars: base fps is 30, jumping to higher numbers with high frequency=
(on
windows I get rock solid 60fps), load is 20-30%
- doom 3: fps is usually 55-60, in some areas it drops to 40 (should be rock
solid 60), while the load is 8-11% uncorrelated to fps
- tf2: fps has huge variance between 40-140, load is 30-60% correlated to f=
ps