[Bug,97273,r600g,bisected] regression: NI/Turks WebGL (FishGL) massive speed decrease ~33%

Commit Message

[e-mail] Aug. 10, 2016, 4:12 a.m. UTC

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

            Bug ID: 97273
           Summary: [r600g, bisected] regression: NI/Turks WebGL (FishGL)
                    massive speed decrease ~33%
           Product: Mesa
           Version: git
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/Gallium/r600
          Assignee: [e-mail]
          Reporter: [e-mail]
        QA Contact: [e-mail]

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 <[e-mail]>
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 <[e-mail]> (v1)

:040000 040000 f3adb5adc43e4def32bd23896489520d8cae84c6
72b374e2221e9cc1306d7bfacf39780ec5e42d36 Msrc

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

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

    /* Reset cache after invalidation or switch of parameters. */

After that speed was 'normal'.

Comments

[e-mail] Aug. 10, 2016, 5:21 a.m. UTC | #1

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

--- Comment #1 from Dieter Nützel <[e-mail]> ---
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.

[e-mail] Aug. 31, 2016, 1:37 a.m. UTC | #2

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

--- Comment #2 from Dieter Nützel <[e-mail]> ---
SOLVED

with Mario's commit 2cc880c 

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

commit 2cc880cba54d687a122298c8187ecc31b4a0ee2d
Author: Mario Kleiner <[e-mail]>
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 <[e-mail]>
    Cc: Marek Olšák <[e-mail]>
    Signed-off-by: Marek Olšák <[e-mail]>

: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'?

[e-mail] Aug. 31, 2016, 2:34 a.m. UTC | #3

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

--- Comment #3 from Michel Dänzer <[e-mail]> ---
Does reverting / disabling Nicolai's change still increase performance?

[e-mail] Aug. 31, 2016, 3:14 a.m. UTC | #4

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

--- Comment #4 from Dieter Nützel <[e-mail]> ---
(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.

[e-mail] Aug. 31, 2016, 6:14 a.m. UTC | #5

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

Michel Dänzer <[e-mail]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #5 from Michel Dänzer <[e-mail]> ---
Then let's call this fixed.

Patch

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;