[Mesa-dev] [PATCH 09/10] r300g: claim control flow support since the driver emulates it

[Marek Olšák]

Luca,

I'd rather use what the GLSL compiler provides since, as you say, the wider
community cares about it. Although the GLSL if/loop emulation hasn't been
tested on r300 yet, I think the r300 compiler will handle it just fine.

However shader compilation should not fail if it hits an unsupported
feature. Let's assume there is a GLSL shader which contains loops that
cannot be emulated and a driver doesn't support loops, the shader should be
sent to the driver anyway and be faked, or be emulated by a software
fallback.  See the comment from Ian here:
https://bugs.freedesktop.org/show_bug.cgi?id=29439#c6

NAK.

Marek

On Mon, Sep 6, 2010 at 3:30 AM, Luca Barbieri <luca at luca-barbieri.com>wrote:

> This purpose of this is so that loop/if emulation in the glsl compiler
> doesn't get enabled in the next change.
>
> Note that doing such emulation in driver-specific code is probably
> a bad idea, especially since the result won't be exposed to further
> generic optimizations, and the driver-specific code doesn't get
> improved by the wider community that cares about GLSL.
>
> Thus, it might be a good idea to revert this commit once/if r300g
> works well with the glsl compiler loop/if emulation, and possibly
> remove some of the emulation from the r300 compiler.
>
> The only part that makes sense to have in the driver is emulation of
> loops with an unknown number of iterations, since here the goal is to
> unroll
> as much as possible while staying in the instruction limits, and the glsl
> compiler cannot do this because it has no idea of how many instructions
> some IR will generate.
> ---
>  src/gallium/drivers/r300/r300_screen.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/r300/r300_screen.c
> b/src/gallium/drivers/r300/r300_screen.c
> index 7f41ff0..8deb9d9 100644
> --- a/src/gallium/drivers/r300/r300_screen.c
> +++ b/src/gallium/drivers/r300/r300_screen.c
> @@ -182,7 +182,7 @@ static int r300_get_shader_param(struct pipe_screen
> *pscreen, unsigned shader, e
>         case PIPE_SHADER_CAP_MAX_TEX_INDIRECTIONS:
>             return is_r500 ? 511 : 4;
>         case PIPE_SHADER_CAP_MAX_CONTROL_FLOW_DEPTH:
> -            return is_r500 ? 64 : 0; /* Actually unlimited on r500. */
> +            return is_r500 ? 64 : 1; /* Actually unlimited on r500. */
>             /* Fragment shader limits. */
>         case PIPE_SHADER_CAP_MAX_INPUTS:
>             /* 2 colors + 8 texcoords are always supported
> @@ -216,7 +216,7 @@ static int r300_get_shader_param(struct pipe_screen
> *pscreen, unsigned shader, e
>         case PIPE_SHADER_CAP_MAX_TEX_INDIRECTIONS:
>             return 0;
>         case PIPE_SHADER_CAP_MAX_CONTROL_FLOW_DEPTH:
> -            return is_r500 ? 4 : 0; /* For loops; not sure about
> conditionals. */
> +            return is_r500 ? 4 : 1; /* For loops; not sure about
> conditionals. */
>         case PIPE_SHADER_CAP_MAX_INPUTS:
>             return 16;
>         case PIPE_SHADER_CAP_MAX_CONSTS:
> --
> 1.7.0.4
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20100906/0ff68526/attachment.htm>