Bug 29537

Summary:	[glsl2] texture2DLod() should not be accepted by fragment programs
Product:	Mesa	Reporter:	Brian Paul <brian.e.paul>
Component:	Mesa core	Assignee:	Kenneth Graunke <kenneth>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	medium	CC:	vlee
Version:	git
Hardware:	All
OS:	All
Whiteboard:
i915 platform:		i915 features:
Bug Depends on:
Bug Blocks:	29044

Description Brian Paul 2010-08-12 12:50:06 UTC

Per the GLSL 1.10 and 1.20 specs:

"""
Section 8.7 Texture Lookup Functions

The built-ins suffixed with “Lod” are allowed only in a vertex shader. For the “Lod” functions, lod is directly used as the level of detail.
"""

The glsl2 compiler errantly accepts fragment shaders that use the texture2DLod() function.  This function was added as a frag shader feature through the GL_ATI_shader_texture_lod extension (undocumented?  google it) but it's not standard GLSL.

There are some built-in functions that only apply to vertex shaders or fragment shaders but I don't see how/where the glsl2 compiler makes any distinction.

I'm attaching a piglit shaderrunner test for this but I don't see a way to indicate to shaderrunner that a shader should NOT compile.

VMware Workstation checks to see if a shader using GL_ATI_shader_texture_lod and texture2DLod() compiles and tries to use it if successful.  The glsl compiler allows it but we blow-up/fail later when we try to actually run the shader.

Comment 1 Ian Romanick 2010-08-12 14:21:56 UTC

It is also added by GL_ARB_shader_texture_lod and by some later GLSL version.  Ken is doing some work in this area, so I'm reassigning this to him.

Comment 2 Ian Romanick 2010-08-12 14:23:41 UTC

(In reply to comment #0)
> I'm attaching a piglit shaderrunner test for this but I don't see a way to
> indicate to shaderrunner that a shader should NOT compile.

This sounds like it should be a glslparsertest test.  shaderrunner expects the tests to correctly compile and link, glslparsertest can be told whether to expect successful or failing compilation.

Comment 3 Ian Romanick 2010-08-13 19:28:51 UTC

There are now piglit tests tex_rect-*.frag.  Fixed by:

commit 9364ad8528b8482afd01aab9b5ebe8c9176883df
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Fri Aug 13 17:46:25 2010 -0700

    glsl2/Makefile: Add a 'make builtins' target.
    
    This copies over a dummy builtin_functions.cpp and rebuilds a
    bootstrapped version of the compiler, then uses that to generate the
    proper list of builtins.  Finally, it rebuilds the compiler with the new
    list.
    
    Unfortunately, it's no longer automatic, but at least it works.

commit 43ff8f1a4b90554eae489cebb7e05f983dd9ad66
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Wed Aug 11 16:53:52 2010 -0700

    glsl2: Rework builtin function generation.
    
    Each language version/extension and target now has a "profile" containing
    all of the available builtin function prototypes.  These are written in
    GLSL, and come directly out of the GLSL spec (except for expanding genType).
    
    A new builtins/ir/ folder contains the hand-written IR for each builtin,
    regardless of what version includes it.  Only those definitions that have
    prototypes in the profile will be included.
    
    The autogenerated IR for texture builtins is no longer written to disk,
    so there's no longer any confusion as to what's hand-written or
    generated.
    
    All scripts are now in python instead of perl.

commit d802ba110f78c3eee9541867cde819ada1b2c449
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Thu Aug 12 13:17:53 2010 -0700

    ir_reader: Don't mark functions as defined if their body is empty.

Comment 4 Ian Romanick 2010-08-13 19:30:05 UTC

(In reply to comment #3)
> There are now piglit tests tex_rect-*.frag.  Fixed by:

That should have been tex_lod-*.frag, of course.

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.