Bug 92122 - [bisected, cts] Regression with Assault Android Cactus
Summary: [bisected, cts] Regression with Assault Android Cactus
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Tapani Pälli
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
: 92173 92203 92269 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-09-25 22:02 UTC by Daniel Scharrer
Modified: 2015-10-08 16:59 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Bad rendering (152.55 KB, image/jpeg)
2015-09-25 22:02 UTC, Daniel Scharrer
Details
Expected rendering (245.60 KB, image/jpeg)
2015-09-25 22:03 UTC, Daniel Scharrer
Details

Description Daniel Scharrer 2015-09-25 22:02:23 UTC
Created attachment 118450 [details]
Bad rendering

Rendering is broken with current Mesa in Assault Android Cactus. Bisected to:

commit 266d05a3a0651ac954c91aea12c870940e8a9820
Author: Tapani Pälli <tapani.palli@intel.com>
Date:   Fri Sep 25 09:56:39 2015 +0300

    glsl: fix packed varyings interface type and add default case
    
    fixes Piglit test:
       arb_program_interface_query/linker/query-varyings.shader_test
    
    Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
    Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>


GPU; Radeon HD 7950 (TAHITI)
LLVM r247876
Linux 4.2.0-gentoo-r1

Apitrace recorded with 266d05:
http://constexpr.org/tmp/Cactus-radeonsi-bad.trace.xz

Apitrace recorded with an older commit:
http://constexpr.org/tmp/Cactus-radeonsi-good.trace.xz

It doesn't matter wich commit the apitraces are played back on, the first one is always good and the second one always bad. However, playing back the bad apitrace on good Mesa gives lots of warnings like this one:

3444 @0 glGetAttribLocationARB(programObj = 6, name = "xlv_TEXCOORD0") = 10
3444: warning: vertex attrib location mismatch 10 -> -1
Comment 1 Daniel Scharrer 2015-09-25 22:03:14 UTC
Created attachment 118451 [details]
Expected rendering
Comment 2 MWATTT 2015-09-27 00:44:43 UTC
This commit also breaks Cities: Skylines. The ground is not rendered.
Tested with a AMD JUNIPER chip and LLVMpipe.
Comment 3 Tapani Pälli 2015-09-28 04:59:25 UTC
> It doesn't matter wich commit the apitraces are played back on,
> the first one is always good and the second one always bad.

This makes it horrible to debug :/ I will try to find if I have some app/game that would reproduce this.
Comment 4 Tapani Pälli 2015-09-28 06:12:14 UTC
I was able to reproduce this with demo version. Problem seems to be that application calls glGetAttribLocation for varyings it has and gets wrong location back.
Comment 5 Tapani Pälli 2015-09-28 06:22:42 UTC
(In reply to Tapani Pälli from comment #4)
> I was able to reproduce this with demo version. Problem seems to be that
> application calls glGetAttribLocation for varyings it has and gets wrong
> location back.

and this happens because we return wrong values (varyings, not attribs) in glGetActiveAttrib .. will fix
Comment 6 Daniel Scharrer 2015-09-28 09:35:21 UTC
I can confirm that your patch fixes the issue with the full game as well.
Comment 7 Dieter Nützel 2015-09-30 21:49:46 UTC
*** Bug 92173 has been marked as a duplicate of this bug. ***
Comment 8 Dieter Nützel 2015-09-30 21:51:26 UTC
Please commit soon! ;-)
Comment 9 Dieter Nützel 2015-09-30 22:08:18 UTC
Tapani,

please attach your patch
[Mesa-dev] [PATCH] mesa: fix GetProgramiv/GetActiveAttrib regression
and you have my
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Comment 10 Mark Janes 2015-10-05 19:14:48 UTC
The bisected commit also breaks OpenGL conformance:

es2-cts.gtf.gl2tests.glgetprogramiv_2_0.glgetprogramiv
Comment 11 Krzysztof A. Sobiecki 2015-10-06 19:04:10 UTC
*** Bug 92269 has been marked as a duplicate of this bug. ***
Comment 12 Tapani Pälli 2015-10-07 06:27:37 UTC
Updating status, existing patches can be scrapped and I will send new *real* fix soon.
Comment 13 Krzysztof A. Sobiecki 2015-10-07 09:47:32 UTC
(In reply to Tapani Pälli from comment #12)
> Updating status, existing patches can be scrapped and I will send new *real*
> fix soon.

I the meantime can you revert 266d05a3a0651ac954c91aea12c870940e8a9820?
Comment 14 Tapani Pälli 2015-10-07 09:59:40 UTC
(In reply to Krzysztof A. Sobiecki from comment #13)
> (In reply to Tapani Pälli from comment #12)
> > Updating status, existing patches can be scrapped and I will send new *real*
> > fix soon.
> 
> I the meantime can you revert 266d05a3a0651ac954c91aea12c870940e8a9820?

I would not like to do that, this commit is still valid. I'm expecting the new fix to be reviewed soon.
Comment 15 Krzysztof A. Sobiecki 2015-10-07 12:00:54 UTC
(In reply to Tapani Pälli from comment #14)
> (In reply to Krzysztof A. Sobiecki from comment #13)
> > (In reply to Tapani Pälli from comment #12)
> > > Updating status, existing patches can be scrapped and I will send new *real*
> > > fix soon.
> > 
> > I the meantime can you revert 266d05a3a0651ac954c91aea12c870940e8a9820?
> 
> I would not like to do that, this commit is still valid. I'm expecting the
> new fix to be reviewed soon.

Can you post a link to that fix and how long can it take for it to be reviewed?
Because in the meantime mesa is a bit broken.
Comment 16 Tapani Pälli 2015-10-07 12:09:20 UTC
(In reply to Krzysztof A. Sobiecki from comment #15)
> (In reply to Tapani Pälli from comment #14)
> > (In reply to Krzysztof A. Sobiecki from comment #13)
> > > (In reply to Tapani Pälli from comment #12)
> > > > Updating status, existing patches can be scrapped and I will send new *real*
> > > > fix soon.
> > > 
> > > I the meantime can you revert 266d05a3a0651ac954c91aea12c870940e8a9820?
> > 
> > I would not like to do that, this commit is still valid. I'm expecting the
> > new fix to be reviewed soon.
> 
> Can you post a link to that fix and how long can it take for it to be
> reviewed?
> Because in the meantime mesa is a bit broken.

Here is the fix:
http://lists.freedesktop.org/archives/mesa-dev/2015-October/096406.html

(Note that Mesa master is unstable, there are many other things broken too. If you need quickly a stable driver, I recommend to use a recent stable release such as 11.0.2 which does not have this issue)
Comment 17 Tapani Pälli 2015-10-08 04:46:59 UTC
commit 4e7fd66cf0986a7eb58800f52d0b8709c2f997d6
Author: Tapani Pälli <tapani.palli@intel.com>
Date:   Wed Oct 7 10:04:06 2015 +0300

    glsl: add varyings to resource list only with SSO
    
    Varyings can be considered inputs or outputs of a program only when
    SSO is in use. With multi-stage programs, inputs contain only inputs
    for first stage and outputs contains outputs of the final shader stage.
    
    I've tested that fix works for Assault Android Cactus (demo version)
    and does not cause Piglit or CTS regressions in glGetProgramiv tests.
    
    Following ES 3.1 CTS separate shader tests that do query properties
    of varyings in SSO shader programs pass:
    
       ES31-CTS.program_interface_query.separate-programs-vertex
       ES31-CTS.program_interface_query.separate-programs-fragment
    
    Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
    Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92122
Comment 18 Alex Deucher 2015-10-08 16:59:10 UTC
*** Bug 92203 has been marked as a duplicate of this bug. ***


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.