[Mesa-dev] SSBO's in UniformBlocks list?

[Iago Toral]

On Wed, 2015-09-30 at 11:27 -0400, Ilia Mirkin wrote:
> On Wed, Sep 30, 2015 at 3:18 AM, Iago Toral <itoral at igalia.com> wrote:
> > On Wed, 2015-09-30 at 02:34 -0400, Ilia Mirkin wrote:
> >> On Wed, Sep 30, 2015 at 2:26 AM, Iago Toral <itoral at igalia.com> wrote:
> >> > On Tue, 2015-09-29 at 11:19 -0400, Ilia Mirkin wrote:
> >> >> On Tue, Sep 29, 2015 at 4:33 AM, Iago Toral <itoral at igalia.com> wrote:
> >> >> > Hi ilia,
> >> >> >
> >> >> > On Tue, 2015-09-29 at 03:53 -0400, Ilia Mirkin wrote:
> >> >> >> Hi Samuel, and any other onlookers,
> >> >> >>
> >> >> >> I was wondering why the decision was made to stick SSBO's onto the
> >> >> >> same list as constbufs. Seems like they're entirely separate entities,
> >> >> >> no? Perhaps I'm missing something?
> >> >> >
> >> >> > The reason for this was that there is a lot of code in the compiler to
> >> >> > handle uniform blocks and all the rules for them and we needed the same
> >> >> > treatment for SSBOs, so that seemed like a reasonable way forward to
> >> >> > reuse a lot of the code in the compiler front end. I think the only
> >> >> > place where we needed to make explicit distinctions is when we check for
> >> >> > resource limits, since these are different for UBOs and SSBOs of course.
> >> >> > Although UBOs and SSBOs are separate entities they have a lot of
> >> >> > similarities too, so that did not look like a terrible idea, considering
> >> >> > the benefits.
> >> >>
> >> >> My concern is around indexing... now the per-stage indices are in the
> >> >> combined UBO/SSBO space -- how do I tease out the individual ones?
> >> >> Easy enough when you can loop over NumUniformBlocks and just count the
> >> >> right type, but what about in the shader, where I get the buffer index
> >> >> in a ir_rvalue?
> >
> > By the way, in i965 this is not a problem either, we have access to the
> > gl_shader struct from the compiler backend, so if we need to translate
> > from the shared index space to a separate space we have NumUniformBlocks
> > available to do that. From your words I get that you can't access this
> > information from the compiler backend, right? In that case, wouldn't it
> > be possible to translate the index during the GLSL IR -> TGSI
> > conversion?
> 
> Actually a shader should be available at GLSL -> TGSI translation time
> as well. Somehow I didn't connect that in my mind with the relevant
> info being available. So I guess this moves from "impossible" to
> "annoying", since we have to do a list scan and fix up all the UBO
> logic as well.

I wanted to try and rewrite the compiler bits to have separate index
spaces for UBOs and SSBOs so we can see what that actually involves and
decide what is better. My idea was to send a RFC patch as soon as I get
"something" working, it is probably going to take a few days though.

>  Probably easiest to just compute a remapping table and
> stick it somewhere that will last at link time. I'm wondering if this
> will affect indirect array accesses (ARB_gs5 ubo indexing -- does that
> exist on ssbo btw?), but I think that should be fine.

I haven't seen anything in the specs that prevents this, we support that
in i965.

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.

I was actually wondering if we could also split SSBOs/UBOs into separate
arrays only at that point, I might give this a try before I try to
rewrite most of the uniform linking code to deal with two arrays since
the beginning.

Iago