[Bug 97273] [r600g, bisected] regression: NI/Turks WebGL (FishGL) massive speed decrease ~33%
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: dri-devel@lists.freedesktop.org Reporter: Dieter@nuetzel-hh.de QA Contact: dri-devel@lists.freedesktop.org
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).
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'.
https://bugs.freedesktop.org/show_bug.cgi?id=97273
--- Comment #1 from Dieter Nützel Dieter@nuetzel-hh.de --- Argh.
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.
https://bugs.freedesktop.org/show_bug.cgi?id=97273
--- Comment #2 from Dieter Nützel Dieter@nuetzel-hh.de --- 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'?
https://bugs.freedesktop.org/show_bug.cgi?id=97273
--- Comment #3 from Michel Dänzer michel@daenzer.net --- Does reverting / disabling Nicolai's change still increase performance?
https://bugs.freedesktop.org/show_bug.cgi?id=97273
--- Comment #4 from Dieter Nützel Dieter@nuetzel-hh.de --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=97273
Michel Dänzer michel@daenzer.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #5 from Michel Dänzer michel@daenzer.net --- Then let's call this fixed.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org