Comment # 57
on bug 110781
from Richard Thier
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.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
