No announcement yet.

Catalyst 9.1 is out

  • Filter
  • Time
  • Show
Clear All
new posts

  • Does anyone use fglrx with a Radeon 3450 in a Lenovo T400? This driver acts strange... Once i use an external monitor i am unable to switch back to LVDS only. Console switching also does not work.


    • Originally posted by bridgman View Post
      At first glance the Apocrypha issue looks like an error in the shader source code. This line :

      trace:d3d_shader:shader_addline GL HW (2, 13) : uniform vec4 VC[107];

      ... defines the VC array with 107 elements, yet :

      trace:d3d_shader:shader_addline GL HW (23, 513) : gl_Position.x = (dot(R1.xyzw, VC[224].xyzw));
      trace:d3d_shader:shader_addline GL HW (24, 559) : gl_Position.y = (dot(R1.xyzw, VC[225].xyzw));
      trace:d3d_shader:shader_addline GL HW (25, 605) : gl_Position.z = (dot(R1.xyzw, VC[226].xyzw));
      trace:d3d_shader:shader_addline GL HW (26, 651) : gl_Position.w = (dot(R1.xyzw, VC[227].xyzw));

      ... seem to use the 224th through 227th elements of that array, and then :

      trace:d3d_shader:shader_addline GL HW (36, 1156) : = ( + VC[223].xyz);

      accesses the 223rd element. Those are the 5 lines rejected by the shader compiler, but they *do* seem like they should be rejected. Anyone more familiar with GLSL want to jump in here ?
      The size of the VC array is based on the amount of available uniforms. Ie, on a card with 512 uniforms (= 128 vec4's) available, we subtract 4 for posFixup, 16 for bool constants, and 4*16 for integer constants to end up with 428 uniforms for floating point constants, which gives 107 vec4's.

      We could potentially skip subtracting the integer and bool constants if the shader doesn't use them, but that won't help much here. It looks like the shader simply expects 256 float constants to be available (which is not unreasonable for a SM3.0 shader, vs_3_0 requires 256 float constants). Iow, you'd require about 1024 uniforms to run this shader.

      I wouldn't be surprised if the number of reported uniforms is simply wrong and the driver reports the number of available vec4's rather than the number of available uniforms. The number for ARB_VERTEX_PROGRAM being larger than the one for ARB_VERTEX_SHADER is a pretty strong hint this is the case.