[Mesa-dev] [PATCH 3/3] tgsi/ureg: increase the number of immediates
Zack Rusin
zackr at vmware.com
Wed Feb 5 02:42:11 CET 2014
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 <zackr at 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
>
More information about the mesa-dev
mailing list