Yes, they simply always behave as if they were accessed indirectly from our
code, but llvm seems to be pretty good at moving all of those accesses to
registers (aka. eliminating alloca's) if they're not actually indirectly
indexed, so it all ends up pretty.
z
----- Original Message -----
> Am 05.02.2014 01:34, schrieb Zack Rusin:
> > ureg_program is allocated on the heap so we can just bump the
> > number of immediates that it can handle. It's needed for d3d10.
> >
> > Signed-off-by: Zack Rusin <za...@vmware.com>
> > ---
> > src/gallium/auxiliary/tgsi/tgsi_ureg.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
> > b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
> > index f06858e..f928f57 100644
> > --- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
> > +++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
> > @@ -77,7 +77,7 @@ struct ureg_tokens {
> > #define UREG_MAX_SYSTEM_VALUE PIPE_MAX_ATTRIBS
> > #define UREG_MAX_OUTPUT PIPE_MAX_SHADER_OUTPUTS
> > #define UREG_MAX_CONSTANT_RANGE 32
> > -#define UREG_MAX_IMMEDIATE 256
> > +#define UREG_MAX_IMMEDIATE 4096
> > #define UREG_MAX_ADDR 2
> > #define UREG_MAX_PRED 1
> > #define UREG_MAX_ARRAY_TEMPS 256
> >
>
> Series looks good to me. llvm can still perform all optimizations on
> such immediates right?
>
> Roland
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
