Created attachment 113450 [details] weston-corruption.png Weston shows graphical corruption when run as regular user. Looks like old framebuffer data is getting reused (i.e. partial text and images from firefox or the desktop). Tested inside X and on console with weston-launch. Running as root shows no corruption. Bisected to mesa commit below: Mesa 10.6.0-devel (git-3f1e128) linux-3.19.0-rc7 wayland (git-52d971c) westonn (git-ad1218f) commit 0467a52dc3f7d51eeb51179ce2f9871758ecacb1 Author: Park, Jeongmin <pjm0616@gmail.com> Date: Sat Feb 7 17:53:48 2015 +0900 st/dri: Make depth buffer optional for postprocessing Since only pp_jimenezmlaa uses depth buffer, we can make it optional. Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Created attachment 113451 [details] dmesg and weston output
Have you enabled any of pp_celshade / pp_jimenezmlaa / pp_jimenezmlaa_color / pp_nored / pp_nogreen / pp_noblue in /etc/drirc or ~/.drirc or the environment?
Hi Michel, Yes, both pp_jimenezmlaa and pp_jimenezmlaa_color were set to 8. Changing pp_jimenezmlaa to zero or setting "always_have_depth_buffer=true" seems to fix the problem. Would that mean this is a bug in weston instead? Something along the lines of failing to check that a depth buffer exists before using it?
Sounds like maybe pp_jimenezmlaa gets enabled even when there's no depth buffer. Do you really want to use those post-processing effects with weston, though? :)
I moved depth buffer checks from dri*.c to pp_jimenezmlaa() per Brian's comment here: https://bugs.freedesktop.org/show_bug.cgi?id=88962 depth buffer check was added to pp_mlaa.c in 2e6ba6afdb62e80689b844c7267272d261db172c and removed from dri*.c in 0467a52dc3f7d51eeb51179ce2f9871758ecacb1 This bug seems to be caused by my patch didn't check if pp_jimenezmlaa() was failed. In pp_run.c, if there are multiple postprocess stages(ppq->n_filters > 1) so that it requires a temp buffer(ppq->tmp[]), and pp_jimenzmlaa return immediately without writing to 'out', then the temp buffer would have old data.
@Michel - well, perhaps not... :) @Park, Jeongmin - Thanks for taking the time to dig into this. I realize this bug is probably a low priority itme, but if you do find time to add a check for the failure condition it would be appreciated.
The following patch is part of mesa since 10.5.7. Feel free to reopen if it doesn't resolve the issue. commit 25e9ae2b79f32631e7255807a242e5fc4e39984c Author: Marek Olšák <marek.olsak@amd.com> Date: Tue May 26 19:32:36 2015 +0200 st/dri: fix postprocessing crash when there's no depth buffer
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.