[Bug 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri Jun 7 19:23:35 UTC 2019


https://bugs.freedesktop.org/show_bug.cgi?id=110781

--- Comment #57 from Richard Thier <u9vata at gmail.com> ---
Hello everyone!

I have found one more place where we can end up calling extra ioctls for
GEM_CREATE. I remember telling you above after the very first proposed patch of
Marek, that "Interesting to me is that the CREATE call number is still higher
in strace output than how it was originally before the first slowdown"

I went on to find the cause because I was using his patch when bisecting the
minor issue and this makes it really hard to spot the minor issue I mentined
earlier.

So I decided to find out what causes the 600-700 CREATE calls despite the
performance seems fast.

This is what I did:

    /* Shared resources don't use cached heaps. */
    if (use_reusable_pool) {
        int heap = radeon_get_heap_index(domain, flags);
        assert(heap >= 0 && heap < RADEON_MAX_CACHED_HEAPS);
        usage = 1 << heap; /* Only set one usage bit for each heap. */

        pb_cache_bucket = radeon_get_pb_cache_bucket_index(heap);
        assert(pb_cache_bucket < ARRAY_SIZE(ws->bo_cache.buckets));

        bo = radeon_bo(pb_cache_reclaim_buffer(&ws->bo_cache, size, alignment,
                                               usage, pb_cache_bucket));
        if (bo) 
            return &bo->base;
    } else {
        // first only logs where here
        fprintf(stderr, "1 KULAKVA!!!\n");
        fprintf(stderr, "2 KULAKVA!!!\n");
        fprintf(stderr, "3 KULAKVA!!!\n");
        // this segfault got added later
        uint kula = 0; 
        int *kulakva = (int*)kula;
        *kulakva=42;
    }    

I saw that still I can get to the code path where "KULAKVA" gets printed, while
in the very original code of course this was never the case ever as the whole
if and the bool variable if using reusable pools or not was not existing yet.

I am now recompiling with debug symbols so that running glxgears with gdb will
hopefully fail at the last line of the else clause and tell me a backtrace
where I am coming from ;-)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20190607/97d7ba64/attachment.html>


More information about the dri-devel mailing list