[Bug 97532] Regression: GLB 2.7 segfaults due to bogus linker precision error (259fc505) on dead variable

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=97532

--- Comment #14 from Eero Tamminen <eero.t.tamminen at intel.com> ---
(In reply to Kenneth Graunke from comment #12)
> That's not true at all...we run dEQP and the ES conformance suite on every
> commit.  That's something like 90,000 GLES-only tests, which is definitely
> tests than we run for GL.

Sorry, I was unclear.  I wasn't thinking of API & unit test-cases. Such tests
are naturally maintained & fixed (Mesa commit breaking GLB was done to fix
conformance test).

By "use-cases" I meant real world GLES apps, games and benchmarks, things that
users may be using years after buying them and their maintenance having
stopped. E.g. stuff in Android & ChromeOS app stores that's still sold but not
anymore maintained, or something like GLB 2.7.


(In reply to Kenneth Graunke from comment #13)
> Eero is right, the GLES version of GLBenchmark breaks.  The GL version works
> fine.
> 
> I double checked the rules and Ian's patch is absolutely correct - the ES
> 3.2 spec says:
> 
> "Uniforms in shaders all share a single global name space when
>  linked into a program or separable program. Hence, the types,
>  precisions and any location specifiers of all declared uniform
>  variables with the same name must match across shaders that
>  are linked into a single program."

3.1 & 3.2 specs are explicit that declarations must match.  3.0 was a bit more
vague whether this applies to non-active uniform declarations.  2.0 spec
doesn't say anything about matching, just a bit about whether uniforms are
active or not.


[...]
> - it seems surprising that this app has been out for 3 years and no
> other ES vendor has hit this bug...)

GLB is GLES 2.x, and the matching requirement is only in GLES 3.x spec.


> Or perhaps we just need to add a driconf option to either resort to "take
> the max" or just force everything to highp (like in desktop GL).

Or give warnings for apps requesting GLES 2.x context, when both of the
compared stage's uniforms aren't used, and error only when both are in use, or
context is GLES 3.x+?

Tricky thing here is that AFAIK Mesa gives GLES 3.x context also for apps
requesting 2.x one (which also causes them to be much slower when they use 1x1
cube maps, due to GLES 3.x sampling rule about cube map corners).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20160907/7b14ba21/attachment.html>