Bug 89131

Summary:	[Bisected] Graphical corruption in Weston, shows old framebuffer pieces
Product:	Mesa	Reporter:	James Harvey <lothmordor>
Component:	Mesa core	Assignee:	mesa-dev
Status:	RESOLVED FIXED	QA Contact:	mesa-dev
Severity:	normal
Priority:	medium	CC:	pjm0616
Version:	git
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	weston-corruption.png dmesg and weston output

Description James Harvey 2015-02-13 06:49:35 UTC

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>

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. How we collect and use information is described in our Privacy Policy.