Page 12 of 13 FirstFirst ... 210111213 LastLast
Results 111 to 120 of 130

Thread: Radeon VRAM Optimizations Coming, But Help Is Needed

  1. #111
    Join Date
    Jul 2010
    Posts
    373

    Default

    Quote Originally Posted by curaga View Post
    Ah, nice. Is that custom code, or text processing via statinfo?
    Hacked statinfo.

  2. #112
    Join Date
    Jul 2010
    Posts
    373

    Default

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

  3. #113
    Join Date
    Jul 2010
    Posts
    373

    Default

    Quote 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?
    Here an output snippet:
    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

  4. #114
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,729

    Default

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

  5. #115
    Join Date
    Jan 2009
    Posts
    598

    Default

    Quote Originally Posted by curaga View Post
    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.

  6. #116
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,729

    Default

    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);
     }
    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.

  7. #117
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,729

    Default

    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.

  8. #118
    Join Date
    Sep 2012
    Location
    London
    Posts
    28

    Default

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

  9. #119
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,729

    Default

    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).

  10. #120
    Join Date
    Mar 2009
    Location
    in front of my box :p
    Posts
    733

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •