Bug 97273

Summary: [r600g, bisected] regression: NI/Turks WebGL (FishGL) massive speed decrease ~33%
Product: Mesa Reporter: Dieter Nützel <Dieter>
Component: Drivers/Gallium/r600Assignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact: Default DRI bug account <dri-devel>
Severity: normal    
Priority: medium CC: maraeo, mario.kleiner, nhaehnle
Version: git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Dieter Nützel 2016-08-10 04:12:46 UTC 
Current Mesa (git-3f100b7) and some stable versions show massive speed decrease on FishGL (WebGL) demo with konqueror 4.14.8 (KDE 4.14.9).

http://www.fishgl.com/

look at the aquarium: ~60 fps -> ~40 fps
look from inside (diver): ~30 fps -> ~20 fps

I've bisected it to:

/opt/mesa> git bisect good                                                                        3735a925ef5692c836c4d26d6adee370dae1c2b0 is the first bad commit
commit 3735a925ef5692c836c4d26d6adee370dae1c2b0
Author: Nicolai Hähnle <nicolai.haehnle@amd.com>
Date:   Wed Jun 8 13:24:14 2016 +0200

    st/mesa: cache staging texture for glReadPixels
    
    v2: add ST_DEBUG flag for disabling (suggested by Ilia)
    
    Reviewed-by: Marek Olšák <marek.olsak@amd.com> (v1)

:040000 040000 f3adb5adc43e4def32bd23896489520d8cae84c6 72b374e2221e9cc1306d7bfacf39780ec5e42d36 Msrc

https://cgit.freedesktop.org/mesa/mesa/log/?ofs=1150

Revert didn't went smooth, so I've commented:

diff --git a/src/mesa/state_tracker/st_cb_readpixels.c b/src/mesa/state_tracker/st_cb_readpixels.c
index 8eb839d..3af9530 100644
--- a/src/mesa/state_tracker/st_cb_readpixels.c
+++ b/src/mesa/state_tracker/st_cb_readpixels.c
@@ -329,7 +329,7 @@ try_cached_readpixels(struct st_context *st, struct st_renderbuffer *strb,
    struct pipe_resource *src = strb->texture;
    struct pipe_resource *dst = NULL;
 
-   if (ST_DEBUG & DEBUG_NOREADPIXCACHE)
+ /*  if (ST_DEBUG & DEBUG_NOREADPIXCACHE) */
       return NULL;
 
    /* Reset cache after invalidation or switch of parameters. */

After that speed was 'normal'.
Comment 1 Dieter Nützel 2016-08-10 05:21:02 UTC 
Argh.

http://www.fishgl.com/

Should read (the other way around):

look at the aquarium: ~30 fps -> ~20 fps and below
look from inside (diver): ~60 fps -> ~40 fps

All the other stuff stays.
Comment 2 Dieter Nützel 2016-08-31 01:37:46 UTC 
SOLVED

with Mario's commit 2cc880c 

If I revert this speed is BAD as with Nicolai's
3735a925ef5692c836c4d26d6adee370dae1c2b0
commit.

commit 2cc880cba54d687a122298c8187ecc31b4a0ee2d
Author: Mario Kleiner <mario.kleiner.de@gmail.com>
Date:   Fri Aug 26 18:59:05 2016 +0200

    r600: increase performance for DRI PRIME offloading if 2nd GPU is Evergreen+
    
    This is a direct port of Marek Olšáks patch
    "radeonsi: increase performance for DRI PRIME
    offloading if 2nd GPU is CIK or VI" to r600.
    
    It uses SDMA for the detiling blit from renderoffload VRAM
    to GTT, as SDMA is much faster for tiled->linear blits from
    VRAM to GTT.
    
    Testing on a dual Radeon HD-5770 setup reduced the time
    for the render offload gpu to get its rendering into
    system RAM from approximately 16 msecs for simple rendering
    at 1920x1080 pixel 32 bpp to 5 msecs, a > 3x speedup!
    
    This was measured using ftrace to trace the time the radeon kms
    driver waited on the dmabuf fence of the renderoffload gpu to
    complete.
    
    All in all this brought the time for a flip down from 20 msecs
    to 9 msecs, so the prime setup can display at full 60 fps instead
    of barely 30 fps vsync'ed.
    
    The current r600 implementation supports SDMA on Evergreen and
    later, but not R600/R700 due to some bugs apparently present
    in their SDMA implementation.
    
    Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
    Cc: Marek Olšák <marek.olsak@amd.com>
    Signed-off-by: Marek Olšák <marek.olsak@amd.com>

:040000 040000 16967e652cc0708f670ab8b6d63e5eb629fbd6a0 e62fa916bd1706eb1d61975765d77d76cfae0fd2 Msrc

So I'm somewhat unsure if I should close this.

Mario, Marek, Nicolai could it be that we get another boost if both patches
'work together'?
Comment 3 Michel Dänzer 2016-08-31 02:34:59 UTC 
Does reverting / disabling Nicolai's change still increase performance?
Comment 4 Dieter Nützel 2016-08-31 03:14:33 UTC 
(In reply to Michel Dänzer from comment #3)

Hello Michel,

sorry that I haven't had you on my radar...,-)

> Does reverting / disabling Nicolai's change still increase performance?

I've checked. (Only disabled like above 'cause it do not revert clean.)

No, not that I can measure (with fishgl / digikam / Blender / FreeCAD).
So I tend to say really NO.

But the whole system feels snappier than ever since Mario's commit.
Writing this with Nicolai's change disabled...

I need some sleep.
Comment 5 Michel Dänzer 2016-08-31 06:14:00 UTC 
Then let's call this fixed.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.