[Mesa-dev] [PATCH 14/20] radeonsi: reserve a parameter slot for FMASK resources in shaders

[Tom Stellard]

On Thu, Aug 08, 2013 at 01:51:39PM +0200, Marek Olšák wrote:
> Interleaving might not be a good idea, but they could be in the same
> array, like this:
> 
> 0..15: textures
> 16..31: FMASK textures
> 
> I'll test LLVM master, but we should probably bump the LLVM version
> requirement in configure.ac to prevent users from using LLVM 3.3.
> 

What is it that works with LLVM master, but doesn't work with LLVM 3.3?

-Tom

> Marek
> 
> On Thu, Aug 8, 2013 at 10:37 AM, Christian König
> <deathsimple at vodafone.de> wrote:
> > Am 08.08.2013 10:30, schrieb Michel Dänzer:
> >
> >> On Don, 2013-08-08 at 02:20 +0200, Marek Olšák wrote:
> >>>
> >>> diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c
> >>> b/src/gallium/drivers/radeonsi/si_state_draw.c
> >>> index 746ace6..4208fa7 100644
> >>> --- a/src/gallium/drivers/radeonsi/si_state_draw.c
> >>> +++ b/src/gallium/drivers/radeonsi/si_state_draw.c
> >>> @@ -241,6 +241,7 @@ static void si_pipe_shader_ps(struct pipe_context
> >>> *ctx, struct si_pipe_shader *s
> >>>                 /* Last 2 reserved SGPRs are used for VCC */
> >>>                 num_sgprs = num_user_sgprs + 2;
> >>>         }
> >>> +       num_sgprs += 1; /* XXX this fixes VM faults */
> >>>         assert(num_sgprs <= 104);
> >>
> >> You can't just increment num_sgprs unconditionally here, or the
> >> assertion will spuriously fail again when num_sgprs was 104 to begin
> >> with.
> >>
> >> More fundamentally, I'd really like us to understand why / under what
> >> circumstances the value needs to be incremented at all. You mentioned on
> >> IRC that you were using an LLVM 3.3 tree, is this change still necessary
> >> with LLVM master / trunk? If yes, it would be good to look into at least
> >> some example shaders where the change is really necessary, to try and
> >> understand the circumstances.
> >
> >
> > Additional to that I'm not sure if we should add another sgpr pointer to the
> > shader, the docs speak of quite a performance penalty for each. Since they
> > are (optional) attributes to the textures anyway they could probably be
> > interleaved with the texture resources.
> >
> > Christian.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev