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 > <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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
