[Bug 32271] New: DDX opcode is not implemented in radeon shader compiler

[Bug 32271] New: DDX opcode is not implemented in radeon shader compiler

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32271

           Summary: DDX opcode is not implemented in radeon shader
                    compiler
           Product: Mesa
           Version: git
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/Gallium/r300
        AssignedTo: dri-devel@lists.freedesktop.org
        ReportedBy: aaalmosss@gmail.com


Most surfaces are black in vdrift 2009 release with shaders enabled, and this
is printed:
r300 FP: Compiler Error:
r300_fragprog_emit.c::translate_rgb_opcode(): translate_rgb_opcode: Unknown
opcode DDX
Using a dummy shader instead.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 32271] DDX opcode is not implemented in radeon shader compiler

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32271

Ian Romanick <idr@freedesktop.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Platform|Other                       |All
                 CC|                            |idr@freedesktop.org

--- Comment #1 from Ian Romanick <idr@freedesktop.org> 2010-12-09 11:24:05 PST ---
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.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 32271] DDX opcode is not implemented in radeon shader compiler

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32271

--- Comment #2 from Marek Olšák <maraeo@gmail.com> 2010-12-09 14:45:57 PST ---
I wonder if lowering DDX/DDY to SFL makes any difference compared to using a
shader that outputs (0,0,0,1).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32271] DDX opcode is not implemented in radeon shader compiler

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32271

--- Comment #3 from Ian Romanick <idr@freedesktop.org> 2010-12-10 13:42:47 PST ---
(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. :)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 32271] DDX opcode is not implemented in radeon shader compiler

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32271

--- Comment #4 from Marek Olšák <maraeo@gmail.com> 2010-12-11 01:59:58 PST ---
(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.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32271] DDX opcode is not implemented in radeon shader compiler

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32271

Marek Olšák <maraeo@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |NOTABUG

--- Comment #5 from Marek Olšák <maraeo@gmail.com> 2010-12-11 07:22:55 PST ---
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.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32271] DDX opcode is not implemented in radeon shader compiler

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32271

--- Comment #6 from Álmos <aaalmosss@gmail.com> 2010-12-11 11:23:36 PST ---
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).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32271] DDX opcode is not implemented in radeon shader compiler

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32271

--- Comment #7 from Álmos <aaalmosss@gmail.com> 2010-12-14 14:51:12 PST ---
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.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel