On Thu, 2015-10-01 at 02:18 -0400, Ilia Mirkin wrote:
> On Thu, Oct 1, 2015 at 2:12 AM, Iago Toral <ito...@igalia.com> wrote:
> > However, I think this can be a problem in your case, because you can't
> > remap the block index if you don't know how many blocks in UniformBlocks
> > before the one you are processing are of a different type (i.e. UBOs if
> > this is an SSBO or the other way around). And you cannot know how many
> > blocks you have to count because the index into the array instance
> > blocks is not constant... We can probably fix this by grouping UBOs and
> > SSBOS together in the array right before we flow into the backends.
>
> Slightly annoying but non-fatal. I think that just the remapping table
> is enough -- the indexing is always done relative to a base index, and
> as long as these arrays are contiguous (which they kinda have to be),
> it shouldn't matter what the offset is. i.e. if the list contains u0
> u1 s0 s1 u2 u3, and i want to index on u2/3, as long as i know that u2
> is the base, I can use its index.
But they are not contiguous, that's why I say that we would need to
group them. In shader code you can in theory have something like:
layout(std140, binding=2) buffer SSBO1 {
vec4 v0;
vec4 v1;
} ssbo1[3];
layout(std140, binding=3) uniform UBO {
vec4 v0;
vec4 v1;
} ubo[2];
layout(std140, binding=5) buffer SSBO2 {
vec4 v0;
vec4 v1;
} ssbo2[2];
and we would add them in that order to the list, which I think would be
a problem for you in the case you mention.
> At least I think that's right, haven't *fully* thought it through tbh.
> But it seems like it could work.
>
> -ilia
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
