Skip to content

v3d: increate max texture count, add custom for opengl

Alejandro Piñeiro requested to merge apinheiro/mesa:review/v3d-increate-max-texture-register-allocation-fix into master

As part of !6766 (merged) we increased the max count of textures available. We found that this gets some gles3 tests to regress. It seems that the nir scheduler doesn't handle really well code like this:

 void main (void)
 {
 	mediump vec4 color = vec4(0.0);
 	color += (1.0/22.0)*(vec4(texture(u_sampler0, vec2(u_trans0*vec4(v_coord, 1.0, 1.0))))*u_texScale0 + u_texBias0);
 	color += (1.0/22.0)*(vec4(texture(u_sampler1, vec2(u_trans1*vec4(v_coord, 1.0, 1.0))))*u_texScale1 + u_texBias1);
 
         ... skip ....
 
 	color += (1.0/22.0)*(vec4(texture(u_sampler20, vec2(u_trans20*vec4(v_coord, 1.0, 1.0))))*u_texScale20 + u_texBias20);
 	color += (1.0/22.0)*(vec4(texture(u_sampler21, vec2(u_trans21*vec4(v_coord, 1.0, 1.0))))*u_texScale21 + u_texBias21);
 	o_color = color;
 }

All texture accesses are affected by three different uniforms, and each texture access has their own. So they are basically free to be moved wherever to want, so in combination with setting a really big delay for texture instruction, quoting:

  /* Pick some large number to try to fetch textures early and sample them
   * late.
   */

This leads to load_uniforms being grouped on big chunks and increasing the register pressure. This affects significantly the fallback option.

I was tempted to just modify the original patch, in order to keep exposing the same value for max texture count on opengl, but the inherent problem would be still there, as it would be as easy as wrote the equivalent test on vk-gl-cts.

Edited by Alejandro Piñeiro

Merge request reports