Bug 89131 - [Bisected] Graphical corruption in Weston, shows old framebuffer pieces
Summary: [Bisected] Graphical corruption in Weston, shows old framebuffer pieces
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
Depends on:
Reported: 2015-02-13 06:49 UTC by James Harvey
Modified: 2015-07-06 12:34 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

weston-corruption.png (894.97 KB, image/png)
2015-02-13 06:49 UTC, James Harvey
dmesg and weston output (60.91 KB, text/plain)
2015-02-13 06:52 UTC, James Harvey

Note You need to log in before you can comment on or make changes to this bug.
Description James Harvey 2015-02-13 06:49:35 UTC
Created attachment 113450 [details]

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)
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>
Comment 1 James Harvey 2015-02-13 06:52:27 UTC
Created attachment 113451 [details]
dmesg and weston output
Comment 2 Michel Dänzer 2015-02-14 02:42:33 UTC
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?
Comment 3 James Harvey 2015-02-14 06:47:16 UTC
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?
Comment 4 Michel Dänzer 2015-02-17 04:19:16 UTC
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? :)
Comment 5 Park, Jeongmin 2015-02-17 04:55:48 UTC
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.
Comment 6 James Harvey 2015-02-18 05:42:27 UTC
@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.
Comment 7 Emil Velikov 2015-07-06 12:34:15 UTC
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.