[Mesa-dev] [PATCH 1/6] mesa, gallium: renumber shader indices according to their placement in pipeline

Jose Fonseca jfonseca at vmware.com
Fri Jun 28 07:53:46 PDT 2013



----- Original Message -----
> See my explanation in mtypes.h.
> ---
>  src/gallium/include/pipe/p_defines.h       |    7 ++++---
>  src/glsl/linker.cpp                        |   16 ++++++++--------
>  src/mesa/drivers/dri/i965/brw_shader.cpp   |    8 ++------
>  src/mesa/main/mtypes.h                     |    8 ++++++--
>  src/mesa/main/shaderobj.h                  |    4 ++--
>  src/mesa/main/uniform_query.cpp            |    2 +-
>  src/mesa/program/ir_to_mesa.cpp            |   10 +++-------
>  src/mesa/program/program.h                 |    2 +-
>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp |   10 +++-------
>  9 files changed, 30 insertions(+), 37 deletions(-)
> 
> diff --git a/src/gallium/include/pipe/p_defines.h
> b/src/gallium/include/pipe/p_defines.h
> index 8af1a84..216cd2f 100644
> --- a/src/gallium/include/pipe/p_defines.h
> +++ b/src/gallium/include/pipe/p_defines.h
> @@ -352,11 +352,12 @@ enum pipe_flush_flags {
>  
>  
>  /**
> - * Shaders
> + * Shaders.
> + * These must have the same values as Mesa's MESA_SHADER_*.

Sorry for not noticing this earlier -- I haven't been able to keep up with email traffic lately.

I'm afraid I can't agree with this.  Gallium needs to be API agnostic -- it doesn't make sense to have gallium go at the whims of particular state tracker implementation details.

There is a lot of code out there that relies on this ordering. And unfortunately reordering will cause it to fail, often in a silent manner (with no compiler errors or warnings).

----- Original Message -----
> The renumbering only makes sense for the GLSL linker and the only
> reason for doing that in gallium too is that PIPE_SHADER_x must be
> equal to MESA_SHADER_x.

This is an implementation detail.

PIPE_SHADER_x may have been paired with MESA_SHADER_x till now as convenience, but now they are what they are.

Jose


More information about the mesa-dev mailing list