On Friday, September 12, 2014 07:54:38 AM Ian Romanick wrote: > On 09/11/2014 10:07 PM, Kenneth Graunke wrote: > > Samplers take up zero slots and therefore don't exist in the params > > array, nor are they included in stage_prog_data->nr_params. There's no > > need to store their size in param_size, as it's only used for dealing > > with arrays of "real" uniforms (ones uploaded as shader constants). > > > > We run into all kinds of problems trying to refer to the uniform storage > > for variables that don't have uniform storage. For one, we may use some > > other variable's index, or access out of bounds in arrays. In the FS > > backend, our extra 2 * MaxSamplerImageUnits params for texture rectangle > > rescaling paper over a lot of problems. In the VS backend, we claim > > samplers take up a slot, which also papers over problems. > > > > Instead, just skip allocating storage for variables that don't have any. > > At least until we get to bindless, this seems right. Are there any bad > interactions with ARB_gpu_shader5 dynamic index of sampler arrays?
I think this is fine for dynamic indexing of sampler arrays as well. See
brw_fs_visitor.cpp:1838 or so:
nonconst_sampler_index->accept(this);
fs_reg temp(this, glsl_type::uint_type);
emit(ADD(temp, this->result, fs_reg(sampler)))
->force_writemask_all = true;
It still uses the baked in sampler value for the base of the array, but then
adds the non-constant array index to that.
Chris, does this series seem reasonable to you as well?
--Ken
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
