Bug 110872 - Shader cache gives spurious linking errors on sharing between contexts of different versions
Summary: Shader cache gives spurious linking errors on sharing between contexts of dif...
Status: RESOLVED WONTFIX
Alias: None
Product: Mesa
Classification: Unclassified
Component: glsl-compiler (show other bugs)
Version: git
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: mesa-dev
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-10 09:40 UTC by Steinar H. Gunderson
Modified: 2019-09-04 06:32 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments

Description Steinar H. Gunderson 2019-06-10 09:40:30 UTC 
Hi,

I've got an application that runs an OpenGL 4.5 core context (let's call it context A), and then due to some Qt issues, ends up creating an OpenGL 2.0 context (context B) that's sharing with A.

The bug goes about as follows, if I have my thoughts ordered correctly:

1. A compiles a vertex shader 1 (#version 150) and a fragment shader 2, and links it into a program 3. Mesa looks into its GLSL cache index, and figures that compilation succeeded once, so glCompileShader() returns true without even checking. (However, 1 and 2 have actually disappeared out of the cache already.)
2. B wants to use 3, but can't since it's in use by some other thread and that might disturb its uniforms (I can't use UBOs, since they're very slow in Mesa on Haswell), so it asks to re-link 1+2 into a new program.
3. Mesa notices that it needs to _actually_ compile 1+2, since it can't find them in the disk cache. However, it does so in the context of B, which can't handle #version 150 programs. The compilation fails with a syntax error, but nothing in Mesa actually checks the return value.
4. Mesa tries to link 1+2, even though both failed and thus are empty internally. The error it returns is

Error linking program: error: vertex shader lacks `main'

which is an obviously bogus error.

It's unclear from the spec what should happen, but given that 1 and 2 were compiled in the context of A, I would say that linking them in B should be legal, and it does work if I disable the cache (export MESA_GLSL_CACHE_DISABLE=1). At the very least, it shouldn't complain about the lack of main when main is indeed there.
Comment 1 Timothy Arceri 2019-06-10 10:04:59 UTC 
(In reply to Steinar H. Gunderson from comment #0)
> It's unclear from the spec what should happen, but given that 1 and 2 were
> compiled in the context of A, I would say that linking them in B should be
> legal

I disagree. Compiling in one context with a high GL version then linking those compiled shaders in a different context with a lower GL version is asking for trouble. The features that are missing/disabled when compiling in a lower version are likely to not be correctly handled when linking either. Just because it seems to be working with your use case when the cache is disabled doesn't mean it should or always will.

Just to add the missing details here. The reason for the version mismatch is because one context is core and the other is compat were the i965 driver has a maximum compat version of 3.0, but up to 4.5 is support in core. Most other (non-mesa) drivers have always had matched core/compat versions which is likely why the spec has never bothered to cover this mismatch case.

IMO the best solution is to add proper compat support to all drivers. We could improve the error messages but IMO that effort could be better spent working on adding support.

I don't think there is any Mesa bug here and IMO your application needs to check the context version work around the problem.
Comment 2 Steinar H. Gunderson 2019-06-10 10:29:01 UTC 
Well, at the very least, the re-linking should check the return value of the compilation. That could fail for pretty much any reason, no?
Comment 3 Timothy Arceri 2019-09-04 06:32:50 UTC 
Intels iris driver which will be the default driver in a future release now has compat profile support so this will be a non issue in future. Marking this as won't fix as it's unlikely we will update legacy drivers to handle this corner case.

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.