On Tue, Feb 27, 2018 at 3:45 AM, Roland Scheidegger <srol...@vmware.com> wrote: > Am 27.02.2018 um 03:38 schrieb srol...@vmware.com: >> From: Roland Scheidegger <srol...@vmware.com> >> >> Some state trackers require 128. >> (There are no plans to increase PIPE_MAX_SAMPLERS too, since with gl >> state tracker it's unlikely more than 32 will be needed, if you need >> more use bindless.) >> --- >> src/gallium/include/pipe/p_state.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/src/gallium/include/pipe/p_state.h >> b/src/gallium/include/pipe/p_state.h >> index 2b56d60..cddb3b4 100644 >> --- a/src/gallium/include/pipe/p_state.h >> +++ b/src/gallium/include/pipe/p_state.h >> @@ -64,7 +64,7 @@ extern "C" { >> #define PIPE_MAX_SAMPLERS 32 >> #define PIPE_MAX_SHADER_INPUTS 80 /* 32 GENERIC + 32 PATCH + 16 others */ >> #define PIPE_MAX_SHADER_OUTPUTS 80 /* 32 GENERIC + 32 PATCH + 16 others */ >> -#define PIPE_MAX_SHADER_SAMPLER_VIEWS 32 >> +#define PIPE_MAX_SHADER_SAMPLER_VIEWS 128 >> #define PIPE_MAX_SHADER_BUFFERS 32 >> #define PIPE_MAX_SHADER_IMAGES 32 >> #define PIPE_MAX_TEXTURE_LEVELS 16 >> > > > FWIW if drivers are doing the right thing (so, don't blindly announce > support for PIPE_MAX_SHADER_SAMPLER_VIEWS assuming it's 32 if you can't > handle more etc.), this should just work. It will, however, make some > allocations bigger (cso context comes to mind, but there's probably > more), so I think it warrants some discussion. Apart from that I don't > think there should really be any performance degradation, since code > should not blindly iterate over max views typically (rather, only the > views up to the max number which has changed and so on). > If not everybody is happy with it, I suppose it could be made into a > define coming from the build system(s) - we'd rather avoid doing this in > just a private branch instead, to not getting it broken due to funny > ideas (e.g. 32 bit bitfields representing active units or similar > things) in shared code. > Opinions?
Sounds good to me. cso_context can be changed to save and restore the first 3 fragment sampler views only (for MLAA). st/mesa doesn't need any sampler view tracking from cso_context, because st/mesa tracks fragment sampler views too. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev