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'.
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.
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'?
Does reverting / disabling Nicolai's change still increase performance?
(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.
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.