Bug 43332

Summary:	corrupted output in mesa-demo/fp-tri using r600g
Product:	Mesa	Reporter:	Stefano Teso <stefano.teso>
Component:	Demos	Assignee:	mesa-dev
Status:	RESOLVED MOVED	QA Contact:
Severity:	normal
Priority:	medium
Version:	git
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	screenshot showing the artifact screenshot with r600g screenshot with llvmpipe

Description Stefano Teso 2011-11-29 03:09:58 UTC

Hi,

using mesa from git master (commit 76ba431b97087e2d5ca0351e0d613f0812fd1425), the mesa demo fp-tri, when running the scs.txt shader, displays the correct output overlayed by random blue-ish blocks (perhaps alpha channel corruption?).

The bug doesn't affect llvmpipe. Only scs.txt seems to trigger the issue.

This is on evergreen hw:

01:00.0 VGA compatible controller: ATI Technologies Inc Robson CE [AMD Radeon HD 6300 Series]

on an i7 machine with i386 debian unstable.

The bug is also present in the libGL 7.11.2 shipped by debian, so I don't think it's a regression or a bug in my config.

Please let me know if you need more info.

Thanks,

Comment 1 Stefano Teso 2011-11-29 03:10:30 UTC

Created attachment 53948 [details]
screenshot showing the artifact

Comment 2 Stefano Teso 2011-12-15 09:37:46 UTC

> The bug is also present in the libGL 7.11.2 shipped by debian, so I don't think
> it's a regression or a bug in my config.

It looks like that inst->Dst[0].Register.WriteMask == 3 in tgsi_scs (), so the ZW components of the dest register are never written. Perhaps this could explain the artifact. Not that I'm a GL expert or anything ;-)

Comment 3 Stefano Teso 2011-12-15 09:53:39 UTC

(In reply to comment #2)
> > The bug is also present in the libGL 7.11.2 shipped by debian, so I don't think
> > it's a regression or a bug in my config.
> 
> It looks like that inst->Dst[0].Register.WriteMask == 3 in tgsi_scs (), so the
> ZW components of the dest register are never written. Perhaps this could
> explain the artifact. Not that I'm a GL expert or anything ;-)

Forcing the mask to 15 fixes the problem. Of course this is no solution. Likely the fragment color is not cleared properly before calling SCS?

Comment 4 Michel Dänzer 2011-12-16 02:15:25 UTC

Yeah, looks like the problem is basically that the pixel shader never writes any explicit values to the ZW components of the output register. However, I'm not sure offhand if it's the responsibility of the Gallium driver / state tracker / shader compiler / app to ensure this. Before I go wading through the various specifications, I hope someone does know offhand. :)

Also seeing it on an RS880, dropping evergreen from the title.

Comment 5 Vadim Girlin 2011-12-16 08:46:02 UTC

The shader is responsible for writing all components of the color. SCS instruction writes XY only (ARB_fragment_program spec), so it's not the driver's fault.

Comment 6 Michel Dänzer 2011-12-29 09:13:35 UTC

Reassigning to demos per comment #5.

Comment 7 Andreas Boll 2012-09-13 11:07:39 UTC

Created attachment 67099 [details]
screenshot with r600g

I get no artifacts, but the colors are not correct.
tested with mesa 8.0.4 and mesa master 28f4be9
on my rv770

Comment 8 Andreas Boll 2012-09-13 11:08:16 UTC

Created attachment 67100 [details]
screenshot with llvmpipe

Comment 9 GitLab Migration User 2019-05-14 15:37:05 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/demos/issues/6.

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.