Bug 79293 - Number of sampler uniforms vs. texture image units limit checking woes
Summary: Number of sampler uniforms vs. texture image units limit checking woes
Status: RESOLVED NOTABUG
Alias: None
Product: Mesa
Classification: Unclassified
Component: glsl-compiler (show other bugs)
Version: git
Hardware: Other All
: medium minor
Assignee: Ian Romanick
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-27 07:59 UTC by Kenneth Graunke
Modified: 2015-05-27 04:50 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Kenneth Graunke 2014-05-27 07:59:02 UTC
Today I discovered this code in linker.cpp:

      if (sh->num_samplers > ctx->Const.Program[i].MaxTextureImageUnits) {
         linker_error(prog, "Too many %s shader texture samplers",
                      _mesa_shader_stage_to_string(i));
      }

This prevents you from using more sampler uniforms than you have texture units.  However, I'm failing to find any justification for doing that.  Why can't I create 40 sampler uniforms and bind them all to the same texture unit?

Note: I haven't seen this in a real application, just a Piglit test I was developing to try and provoke a different bug I found.

Ian, feel free to reject this bug if I'm missing something in the specs.
Comment 1 Tapani Pälli 2015-05-26 09:16:27 UTC
From OpenGL 4.5 Core (same text can be found from ES spec), last clause in 'Samplers' section 7.10 discussing about when LinkProgram fails:

"If it determines that the count of active samplers exceeds the allowable limits, then the link fails (these limits can be different for different types of shaders). Each active sampler variable counts against the limit, even if multiple samplers refer to the same texture image unit."
Comment 2 Kenneth Graunke 2015-05-27 04:50:19 UTC
Thanks Tapani, that does make sense!


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.