Summary: | [bisected, cts] Regression with Assault Android Cactus | ||
---|---|---|---|
Product: | Mesa | Reporter: | Daniel Scharrer <daniel> |
Component: | Mesa core | Assignee: | Tapani Pälli <lemody> |
Status: | RESOLVED FIXED | QA Contact: | mesa-dev |
Severity: | normal | ||
Priority: | medium | CC: | Dieter, kylesiefring, lemody, sobkas |
Version: | git | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Bad rendering
Expected rendering |
Description
Daniel Scharrer
2015-09-25 22:02:23 UTC
Created attachment 118451 [details]
Expected rendering
This commit also breaks Cities: Skylines. The ground is not rendered. Tested with a AMD JUNIPER chip and LLVMpipe. > 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.
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. (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 I can confirm that your patch fixes the issue with the full game as well. *** Bug 92173 has been marked as a duplicate of this bug. *** Please commit soon! ;-) 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> The bisected commit also breaks OpenGL conformance: es2-cts.gtf.gl2tests.glgetprogramiv_2_0.glgetprogramiv *** Bug 92269 has been marked as a duplicate of this bug. *** Updating status, existing patches can be scrapped and I will send new *real* fix soon. (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? (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. (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. (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) 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 *** 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.