On Thu, Oct 1, 2015 at 2:24 AM, Iago Toral <ito...@igalia.com> wrote:
> 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.
Wouldn't ubo[0] and ubo[1] get sequential entries in that list? So
when accessing ubo[n], if I look up the remapping of ubo[0] in that
table, I should be sure that ubo[1] is adjacent to it, no?
-ilia
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
