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. Marek On Thu, Aug 8, 2013 at 10:37 AM, Christian König <deathsim...@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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
