Radeon VRAM Optimizations Coming, But Help Is Needed

[log0]

Ah, nice. Is that custom code, or text processing via statinfo?

Hacked statinfo.

[log0]

@curaga I've just noticed multiple destroy entries for a number of buffers (tf2_1.bin). Is that expected behaviour?

[log0]

@curaga I've just noticed multiple destroy entries for a number of buffers (tf2_1.bin). Is that expected behaviour?

Here an output snippet:

create buffer 17 at 18 ms (4096 bytes, high priority)
destroy buffer 17 at 19 ms
destroy buffer 17 at 19 ms
destroy buffer 14 at 19 ms
create buffer 18 at 25 ms (16384 bytes)
create buffer 19 at 30 ms (4096 bytes, high priority)
destroy buffer 17 at 32 ms
destroy buffer 19 at 32 ms
destroy buffer 14 at 32 ms
create buffer 20 at 40 ms (16384 bytes)
create buffer 21 at 45 ms (4096 bytes, high priority)
destroy buffer 17 at 46 ms
destroy buffer 21 at 46 ms
destroy buffer 20 at 46 ms

[curaga]

The traces are correct, there really are use-after-free and destroy-more-than-once bugs.

[marek]

The traces are correct, there really are use-after-free and destroy-more-than-once bugs.

I doubt that. Your tracing code must be wrong.

[curaga]

Here is the relevant part:

--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
@@ -399,6 +400,11 @@ static void radeon_bo_destroy(struct pb_buffer *_buf)
         bo->rws->allocated_vram -= align(bo->base.size, 4096);
     else if (bo->initial_domain & RADEON_DOMAIN_GTT)
         bo->rws->allocated_gtt -= align(bo->base.size, 4096);
+
+    if (ws->bo_stats_file) {
+        fprintf(ws->bo_stats_file, "%p destroyed @%llu\n", bo, stats_time_get(ws));
+    }
+
     FREE(bo);
 }

As you can see, the destroy trace is printed immediately before the actual free(). There is no chance the file would contain the same destroy line twice without it being also freed twice.

[curaga]

Sorry, I missed that this was one of the first traces.

I checked the text trace (from this thread, post #47). It was captured with pre-jan 17 code, which was slightly buggy in that it missed one creation path. When there's a destroy for a buffer that wasn't created, the binary converter tried to do a best guess.

So for the tf2_1 trace, there are no bugs in mesa code.

[matyas]

Should we redo any of the traces captured? (Might be better to discard traces created with buggy code imho)

[curaga]

No need, they are quite usable despite the initial flaw. Only one or two buffers get created in the other path, and all other events are present for statistical purposes (so destroyed/sec is still accurate, for example).

[Adarion]

No testing from me yet. Weeks later I am still horribly busy at university (and fighting with the SuperIO of my new typing machine). Besides, my Gentoos are having a (severe) hiccup, probably python/python-exec/portage related. Also there was libpng and libjpeg-turbo updates which cause recompiles of the whole system.
I didn't manage to get Mesa 10.0.x compiled on my main box (strangely on my new E-350 acquisition though, but then the PSU of that laptop failed ... I am a real magnet for luck, right?) and I got all my humble bundle games and steam on the main box where I would do testing.

It kinda sucks since normally I only see my home for 2-3 wake hours in the late evening (due to work, f*cking PhD stress) and besides emails and newsreading all I do is a little gaming - and it would have been nice to use that opportunity at the same time to help improving the free driver stack as a normal user. (Gaming to make the driver better sounds awesome, doesn't it? )

Is there any distribution that carries all the neccessary stuff for the tracing and testing and that could be used quickly for the tests? I have several free older IDE drives with enough space to quickly put something on. I could then just boot this and do the testing.