Bug 32271

It sounds like the application has a shader that uses dFdx(), dFdy(), or fwidth() GLSL functions.  These functions emit the DDX and / or DDY instructions.  Older hardware, such as r300 and i915, do not support these instructions.  The best fix is probably to add code to lower_instructions to convert the GLSL IR for these instructions to constants of 0.  This should also emit a warning to the shader's info log.

I wonder if lowering DDX/DDY to SFL makes any difference compared to using a shader that outputs (0,0,0,1).

(In reply to comment #2)
> I wonder if lowering DDX/DDY to SFL makes any difference compared to using a
> shader that outputs (0,0,0,1).

The lowering pass I was referring to would happen long before the Mesa IR level.  At that point there is no SFL instruction.  We'd just replace the ir_unop_dFdx and ir_unop_dFdy expressions with constants of 0 in the appropriate type.  Backends (e.g., ir_to_mesa) can convert these constants to whatever is appropriate.  This way backends for GPUs that can't handle these operations will never even see them.  That is, after all, the whole point of the various lowering passes in the GLSL compiler. :)

(In reply to comment #3)
> (In reply to comment #2)
> > I wonder if lowering DDX/DDY to SFL makes any difference compared to using a
> > shader that outputs (0,0,0,1).
> 
> The lowering pass I was referring to would happen long before the Mesa IR
> level.  At that point there is no SFL instruction.  We'd just replace the
> ir_unop_dFdx and ir_unop_dFdy expressions with constants of 0 in the
> appropriate type.  Backends (e.g., ir_to_mesa) can convert these constants to
> whatever is appropriate.  This way backends for GPUs that can't handle these
> operations will never even see them.  That is, after all, the whole point of
> the various lowering passes in the GLSL compiler. :)

I meant that it's no longer lowering when you replace a function that returns X with another function that returns 0. It's an incorrect transformation that changes the code to something completely different. Think of my "lowering to SFL" as a way to describe what is going on.

Closing as this is a hardware limitation, not a bug.

Álmos, feel free to contact vdrift developers that they might provide some more hw-friendly shaders if they want to support ATI R3xx/R4xx GPUs with shaders enabled. I have also noticed they use GL_ARB_shader_texture_lod (the texture2DLod function in the fragment shader) even though the extension is not advertised by Mesa and the R3xx/R4xx hardware doesn't and cannot support it anyway.

I don't think it's necessary to contact them: in this year's release there is a completely different set of shaders, and all compile fine. At least in theory, because the game doesn't start up (reported as #32320).

I revoke my last comment, as I successfully convinced vdrift2010 to use a surface format other than RGBA16F, and then it starts up, but hits this DDX problem and a too many ALU instructions problem as well, resulting in The Blackness. This is only for the record, the bugreport may remain resolved/notabug, if this opcode cannot be supported.