[Mesa-dev] [Mesa-stable] [PATCH 1/2] i965: Skip allocating UNIFORM file storage for uniforms of size 0.

Kenneth Graunke kenneth at whitecape.org
Fri Sep 12 08:13:09 PDT 2014


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140912/79a4c630/attachment.sig>


More information about the mesa-dev mailing list