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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #58 from Richard Thier <u9vata at gmail.com> ---
The output from gdb glxgears on the segfault:

#0  0xb75a8892 in radeon_winsys_bo_create (rws=0x45e100, size=4096,
alignment=4096, domain=RADEON_DOMAIN_GTT, flags=(unknown: 0))
    at radeon_drm_bo.c:993
#1  0xb75a972b in radeon_cs_create_fence (rcs=rcs at entry=0xb06a4010) at
radeon_drm_cs.c:753
#2  0xb75aa327 in radeon_drm_cs_flush (rcs=0xb06a4010, flags=2,
pfence=0xbffff7d8) at radeon_drm_cs.c:593
#3  0xb757845a in r300_flush_and_cleanup (r300=r300 at entry=0x446090,
flags=flags at entry=2, fence=fence at entry=0xbffff7d8) at r300_flush.c:56
#4  0xb757860f in r300_flush (pipe=0x446090, flags=2, fence=0xbffff7d8) at
r300_flush.c:82
#5  0xb731508f in st_context_flush (stctxi=0x55ed20, flags=3, fence=0xbffff7d8)
at state_tracker/st_manager.c:635
#6  0xb74511f8 in dri_flush (cPriv=0x445fd0, dPriv=0x5760d0, flags=3,
reason=__DRI2_THROTTLE_SWAPBUFFER) at dri_drawable.c:568
#7  0xb7f9dbe8 in dri2Flush (psc=psc at entry=0x4165d0, ctx=<optimized out>,
draw=draw at entry=0x5590e0, flags=3, 
    throttle_reason=__DRI2_THROTTLE_SWAPBUFFER) at dri2_glx.c:553
#8  0xb7f9e09d in dri2SwapBuffers (pdraw=0x5590e0, target_msc=0, divisor=0,
remainder=0, flush=1) at dri2_glx.c:845
#9  0xb7f73049 in glXSwapBuffers (dpy=0x407160, drawable=18874370) at
glxcmds.c:843
#10 0x00401742 in ?? ()
#11 0xb7b5c669 in __libc_start_main () from /usr/lib/libc.so.6
#12 0x00401cd5 in ?? ()

I have changed this relevant part with the added flag:

    /* Create a fence, which is a dummy BO. */
    fence = cs->ws->base.buffer_create(&cs->ws->base, 1, 1,
                                       RADEON_DOMAIN_GTT,
                                       RADEON_FLAG_NO_SUBALLOC
                                       | RADEON_FLAG_NO_INTERPROCESS_SHARING);

Currently I am testing this, in latest but the build is still going. Will
upload patch for it only if it works. I think it does not harm, but this is
happening when the bo is a "fence". I have no idea what a fence is in this
terminology, but surely it sounds some synchronization primitive so I am unsure
that I can add the flag safely, but knowing earlier it was not in the code
likely I can just add it.

Will see how this shrinks the GEM_CREATE call numbers.

-- 
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/a2447c27/attachment.html>