[Mesa-dev] [PATCH] glsl: Skip invariant/precision linker checks for built-in variables.

Brian Paul brianp at vmware.com
Mon Oct 24 21:58:02 UTC 2016

On 10/19/2016 02:17 PM, Brian Paul wrote:
> On 10/19/2016 02:40 PM, Ian Romanick wrote:
>> On 10/19/2016 11:11 AM, Kenneth Graunke wrote:
>>> Brian found a bug with my "inline built-ins immediately" code for
>>> shaders
>>> which use ftransform() and declare gl_Position invariant:
>>> https://lists.freedesktop.org/archives/mesa-dev/2016-October/132452.html
>>> Before my patch, things worked due to a specific order of operations:
>>> 1. link_intrastage_varyings imported the ftransform function into the VS
>>> 2. cross_validate_uniforms() ran and signed off that everything matched
>>> 3. do_common_optimization did both inlining and invariance propagation,
>>>     making the VS/FS versions of gl_ModelViewProjectionMatrix have
>>>     different invariant qualifiers...but after the check in step 2,
>>>     so we never raised an error.
>>> After my patch, ftransform() is inlined right away, and at compile time,
>>> do_common_optimization propagates the invariant qualifier to the
>>> gl_ModelViewProjectionMatrix.  When the linker eventually happens, it
>>> detects the mismatch.
>> Why are we marking a uniform as invariant in the first place?  That
>> sounds boats.
> The shader author is marking the gl_Position VS output as invariant and
> calling ftransform():
> invariant gl_Position;
> void main()
> {
>    gl_Position = ftransform();
> }
> ftransform() expands into gl_ModelviewProjectionMatrix * gl_Vertex.
> Then, afaict, the propagation pass marks gl_ModelviewProjectionMatrix as
> invariant, but that disagrees with the original declaration of the
> matrix and linking fails.
> That's my superficial understanding of it.
> Do you want me to hold off on pushing the patch?  I'd really like to get
> this or another fix in place.

Ping.  If a more elaborate fix is a ways off, I'd like to commit Ken's 
patch ASAP.


More information about the mesa-dev mailing list