Originally posted by curaga
View Post
Announcement
Collapse
No announcement yet.
Radeon VRAM Optimizations Coming, But Help Is Needed
Collapse
X
-
Originally posted by log0 View Post@curaga I've just noticed multiple destroy entries for a number of buffers (tf2_1.bin). Is that expected behaviour?
Code: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
Comment
-
Here is the relevant part:
Code:--- 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); }
Comment
-
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.
Comment
-
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.Stop TCPA, stupid software patents and corrupt politicians!
Comment
Comment