[Mesa-dev] Fwd: [PATCH] glsl: uniform sampler should occupy 1 location

[Dave Airlie]

(resend forgot the list)

On 22 Aug 2014 16:23, "Ian Romanick" <idr at freedesktop.org> wrote:
>
> I'm not sure this is correct, and I think we need a more complex fix.
> As Dave points out, bindless will make it even more complex.

I've been playing with bindless on and off over last week while on a
long plane journey,

One thing I'm not sure about is whether a shader has to even know a
uniform sampler is bindless or not.

I think the spec allows a shader to specify a uniform sampler2D
mysamp; then use glUniformHandleui64 on it.

so no explicit nomination in the shader that the sampler is bindless
then therefore needs 2 slots.

So I expect we always need to say 2 slots,


> In a non-bindless, static-sampler-array-indexing world, applications
> assume that samplers will use zero uniform locations.  The sampler
> information is baked into the instructions, and it isn't represented
> anywhere else in GPU memory.  As a result, I would not be surprised to
> see previously working applications fail to link (due to using too many
> uniforms) with this change.

The bindless extension, issue 14 might address this,

"

  (14) With this extension, GLSL sampler and image variables may be
         specified using 64-bit handles and are permitted to count as two
         components toward implementation-dependent limits on uniforms, shader
         inputs, and shader outputs.  Is there a backward compatibility
         problem here?

      RESOLVED:  If there is one, we don't expect it to be very serious.

      Prior to this extension, samplers or images could not be used as shader
      inputs or outputs, so there is no compatibility problem there.  Samplers
      and images could be used as uniforms, however.  While there is no
      explicit spec language describing the amount of storage required for
      samplers and images, one might construe this lack of language to mean
      that only a single component was previously required.  Allowing for
      64-bit handles in this extension could double the requirement and cause
      shaders that previously just barely fit to exceed implementation
      limits.

      Implementations that consider this issue serious could increase their
      uniform limit slightly to compensate.  Note that the number of sampler
      variables used prior to this extension was quite limited, so the amount
      of extra storage required for 64-bit handles should be small.


I haven't done enough on bindless to figure out how the hell to handle
all of this, I've just been playing around with hacking on
gallium/softpipe and I probably need to look into how real hw does
this.

Dave.