Comment # 4
on bug 98239
from almos
(In reply to Marek Olšák from comment #3) > Things to try: > > 1) You can try increasing the IB size in radeon_drm_cs.h: > struct radeon_cs_context { > uint32_t buf[16 * 1024]; // HERE > > 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 around 15, but the performance and gpu-load remained mostly the same. It feels a bit 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 get 15fps in the main menu, but after loading a game, and exiting to the main menu 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 fps
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
