error: no function with name 'texture2DLod'

[zephryn]

When running a Supermodel build compiled on my Linux machine, I get this error at runtime:

0:110(14): error: no function with name 'texture2DLod'
0:111(14): error: no function with name 'texture2DLod'
0:112(14): error: no function with name 'texture2DLod'
0:113(14): error: no function with name 'texture2DLod'
0:116(5): warning: `p0q0' used uninitialized
0:116(14): warning: `p1q0' used uninitialized
0:116(35): warning: `p0q0' used uninitialized
0:117(5): warning: `p0q0' used uninitialized
0:117(14): warning: `p0q1' used uninitialized
0:117(35): warning: `p0q0' used uninitialized
0:119(14): warning: `p0q0' used uninitialized
0:120(14): warning: `p1q1' used uninitialized

error: linking with uncompiled/unspecialized shader

From there, as expected, there's no 3D output but the rest of the game runs.

It seems like newer GLSL versions have this function included, and when messing with OpenGL ES porting it worked fine after changing the vertexShaderR3D and fragmentShaderR3D's versions to 300 es (not accounting for the other changes that had to be made to get that to work), but there also seem to be extensions like GL_EXT_EGL_image_storage and GL_EXT_shader_texture_lod which might work without a version change if added to fragmentShaderR3D and changing texture2DLod calls to texture2DLodEXT but I couldn't get this solution to work. I'd get this error message from attempting to use the latter extension in particular:

warning: extension `GL_EXT_shader_texture_lod' unsupported in fragment shader

The OpenGL version Supermodel is being ran with appears to be 4.6.

[dukeeeey]

The code is correct. The issue is the driver is missing functions that are part of the spec.

[zephryn]

Found out that adding #extension GL_ARB_shader_texture_lod : require to the fragment shader and not changing anything else seems to make it work again on my system, but yeah I probably didn't consider it just being a strange driver issue as much as I should have. Strange.

[trzy]

Is this something we should add to the source code? Or, will it have a potentially adverse affect on systems where texture2DLod exists by replacing it with a function that behaves slightly different?

[zephryn]

The extension's spec page has the following snippet, which makes me imagine it's at least intended to be functionally identical to machines where it compiles without the extension specified:

    The existing isotropic vertex texture functions:

        texture1DLod,   texture1DProjLod,
        texture2DLod,   texture2DProjLod,
        texture3DLod,   texture3DProjLod,
        textureCubeLod,
        shadow1DLod,    shadow1DProjLod,
        shadow2DLod,    shadow2DProjLod,

    are added to the built-in functions for fragment shaders.

The spec also states it's written for GLSL 1.1 and OpenGL 2.0, and other references to this issue on the net seem to imply that GLSL 1.0-1.1 aren't supposed to support this function in fragment shaders without an extension; I don't know how different GLSL 1.2 (which the shader that causes this issue specifies its version as) is any different in regards to this quirk though.

It might better suffice to change require to enable in the extension declaration I posted earlier so that the extension isn't absolutely necessary to compile the shader, since evidently other setups don't have an issue with how things are now.

That being said, the biggest thing for me is that I haven't tested on anything else so I don't know for certain if this change would cause oddities with other machines because of OpenGL Implementation Magic individual graphics drivers seem to possess.

[dukeeeey]

You should really file a bug report with whomever wrote the gl driver. The version is set to #120 which means a compliant driver should support it since it's part of the core spec. The function got altered and renamed slightly for gl3+ to become just texturelod if I recall. That is the version used by the quad shader. The quad shader needs gl 4.5 but the triangle version is designed to run on the minimum possible gl version.

[casasfernando]

I'm a bit late to the party. Discussing this same issue on the forums for the last couple of days: https://www.supermodel3.com/Forum/viewtopic.php?f=5&t=2231&start=20

Anyways. Looking at the specs for glsl 1.20 these functions can't be used in a fragment shader, but only in vertex shaders. The extension on the other hand allows the functions to be used in fragment shaders as well.
I found that mesa doesn't seem to allow to use extensions unless they are declared in the code or you use the force_glsl_extensions_warn=true environment variable at runtime.

Adding #extension GL_ARB_shader_texture_lod : require solves the problem but I will check later today if just using enable is enough and report back.

[casasfernando]

After testing I can also confirm that it’s enough to set the extension to ‘enable’ instead of ‘require’.

[dukeeeey]

#extension GL_ARB_shader_texture_lod : require
is the correct solution. You want it to error out if it's unsupported. This is a strange bug, it turns out every vendors implementation is technically wrong, other than MESA. They are simply too lax with the spec.

[casasfernando]

Thanks a lot for your help and patience the last few days @dukeeeey.

I can create a PR to address this one if you want, just let me know.

[trzy]

I think a PR would be nice. Feels like this comes up frequently for people.

[casasfernando]

I think a PR would be nice. Feels like this comes up frequently for people.

PR created.

Thanks!

[dukeeeey]

fixed already