Re: [Mesa-dev] SSBO's in UniformBlocks list?
On Thu, 2015-10-01 at 02:30 -0400, Ilia Mirkin wrote:
> On Thu, Oct 1, 2015 at 2:24 AM, Iago Toral wrote:
> > On Thu, 2015-10-01 at 02:18 -0400, Ilia Mirkin wrote:
> >> On Thu, Oct 1, 2015 at 2:12 AM, Iago Toral 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?
Ah, you meant to have a remap table for the start of each interface
block... yeah, I guess that would work, blocks in each array will be
contiguous in UniformBlocks.
Iago
>
> -ilia
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SSBO's in UniformBlocks list?
On Thu, Oct 1, 2015 at 2:24 AM, Iago Toral wrote:
> On Thu, 2015-10-01 at 02:18 -0400, Ilia Mirkin wrote:
>> On Thu, Oct 1, 2015 at 2:12 AM, Iago Toral 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
Re: [Mesa-dev] SSBO's in UniformBlocks list?
On Thu, 2015-10-01 at 02:18 -0400, Ilia Mirkin wrote:
> On Thu, Oct 1, 2015 at 2:12 AM, Iago Toral 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
Re: [Mesa-dev] SSBO's in UniformBlocks list?
On Thu, Oct 1, 2015 at 2:12 AM, Iago Toral 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. 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
Re: [Mesa-dev] SSBO's in UniformBlocks list?
On Wed, 2015-09-30 at 11:27 -0400, Ilia Mirkin wrote: > On Wed, Sep 30, 2015 at 3:18 AM, Iago Toral wrote: > > On Wed, 2015-09-30 at 02:34 -0400, Ilia Mirkin wrote: > >> On Wed, Sep 30, 2015 at 2:26 AM, Iago Toral wrote: > >> > On Tue, 2015-09-29 at 11:19 -0400, Ilia Mirkin wrote: > >> >> On Tue, Sep 29, 2015 at 4:33 AM, Iago Toral 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 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SSBO's in UniformBlocks list?
On Wed, Sep 30, 2015 at 3:18 AM, Iago Toral wrote: > On Wed, 2015-09-30 at 02:34 -0400, Ilia Mirkin wrote: >> On Wed, Sep 30, 2015 at 2:26 AM, Iago Toral wrote: >> > On Tue, 2015-09-29 at 11:19 -0400, Ilia Mirkin wrote: >> >> On Tue, Sep 29, 2015 at 4:33 AM, Iago Toral 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. 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. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SSBO's in UniformBlocks list?
On Wed, 2015-09-30 at 11:54 +0300, Francisco Jerez wrote: > Iago Toral writes: > > > On Tue, 2015-09-29 at 18:41 +0300, Francisco Jerez wrote: > >> Ilia Mirkin writes: > >> > >> > On Tue, Sep 29, 2015 at 4:33 AM, Iago Toral 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? > >> > > >> Yeah, this seems rather dubious to me too. Even if you had re-used the > >> current gl_uniform_block type for SSBOs for the sake of code-sharing I > >> think it would have made more sense to split them into a different index > >> space, because SSBOs are a different index space at the API level and > >> drivers will want them to be a different index space too. > > > > In the case of i965 at least I think having them combined makes things > > easier because from the driver perspective the only difference between > > SSBOs and UBOs is that the underlying buffer storage has different > > flags. This was the simplest implementation and in theory, translating > > from the shared space to a separate space should be very easy too, so > > drivers that need a separate space should be able to get that as well... > > That's in theory, the problem is that Ilia is saying that in his case > > the compiler backend may not have the information required to make this > > translation, and if this is true then we'll have to rethink this... > > > I think this is largely irrelevant for the i965 driver, code can be > shared either way if shader UBOs and SSBOs are represented using the > same data type: Assuming that function f() is shared among SSBOs and > UBOs, it could also have been shared with separate arrays by changing it > into f(gl_uniform_block[]) and passing the right U/SSBO array as > argument. > > Translating from a separate space to a shared index space is trivial and > has O(1) complexity (shared_ssbo_index = separate_ssbo_index + > max_ubo_index), although it's unlikely to be necessary on any HW > arrchitecture I know of. OTOH translating from the shared space to a > separatee space (as the GL API and Gallium drivers require) involves > iterating over all previous U/SSBOs of the shader and has O(n) > complexity (e.g. as you do here [1]). However, this will come at the expense of having to modify the compiler front-end since that assumes that we only have one array at the moment and all the code that deals with uniform blocks works with that assumption. Not that we can't do this of course, but I was hoping that we could avoid it since that part of the compiler is complex enough as it is... Anyway, at this point I guess the best thing I can do is to implement the separate index space and see that it looks like, hopefully it is not that bad and if gallium drivers can't translate from the shared index space we don't have an alternative anyway. Iago > [1] https://patchwork.freedesktop.org/patch/60654/ > > >> I believe that this leads to a bug the i965 implementation -- We expose > >> 12 SSBOs per stage and 12 UBOs per stage, but we only have 12 binding > >> table entries reserved for the block of the binding table currently > >> shared among UBOs and SSBOs, so you might overflow the number of > >> available surface entries if the combined number of UBOs and SSBOs is > >> greater than 12 for some stage. > > > > Yeah, we forgot to update that. I'll send a patch to fix this. Thanks > > Curro! > > > > Iago > > > >> > Thanks, > >> > > >> > -ilia > >> > ___ > >> > mesa-dev mailing list > >> > mesa-dev@lists.freedesktop.org > >> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailma
Re: [Mesa-dev] SSBO's in UniformBlocks list?
Iago Toral writes: > On Tue, 2015-09-29 at 18:41 +0300, Francisco Jerez wrote: >> Ilia Mirkin writes: >> >> > On Tue, Sep 29, 2015 at 4:33 AM, Iago Toral 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? >> > >> Yeah, this seems rather dubious to me too. Even if you had re-used the >> current gl_uniform_block type for SSBOs for the sake of code-sharing I >> think it would have made more sense to split them into a different index >> space, because SSBOs are a different index space at the API level and >> drivers will want them to be a different index space too. > > In the case of i965 at least I think having them combined makes things > easier because from the driver perspective the only difference between > SSBOs and UBOs is that the underlying buffer storage has different > flags. This was the simplest implementation and in theory, translating > from the shared space to a separate space should be very easy too, so > drivers that need a separate space should be able to get that as well... > That's in theory, the problem is that Ilia is saying that in his case > the compiler backend may not have the information required to make this > translation, and if this is true then we'll have to rethink this... > I think this is largely irrelevant for the i965 driver, code can be shared either way if shader UBOs and SSBOs are represented using the same data type: Assuming that function f() is shared among SSBOs and UBOs, it could also have been shared with separate arrays by changing it into f(gl_uniform_block[]) and passing the right U/SSBO array as argument. Translating from a separate space to a shared index space is trivial and has O(1) complexity (shared_ssbo_index = separate_ssbo_index + max_ubo_index), although it's unlikely to be necessary on any HW arrchitecture I know of. OTOH translating from the shared space to a separatee space (as the GL API and Gallium drivers require) involves iterating over all previous U/SSBOs of the shader and has O(n) complexity (e.g. as you do here [1]). [1] https://patchwork.freedesktop.org/patch/60654/ >> I believe that this leads to a bug the i965 implementation -- We expose >> 12 SSBOs per stage and 12 UBOs per stage, but we only have 12 binding >> table entries reserved for the block of the binding table currently >> shared among UBOs and SSBOs, so you might overflow the number of >> available surface entries if the combined number of UBOs and SSBOs is >> greater than 12 for some stage. > > Yeah, we forgot to update that. I'll send a patch to fix this. Thanks > Curro! > > Iago > >> > Thanks, >> > >> > -ilia >> > ___ >> > mesa-dev mailing list >> > mesa-dev@lists.freedesktop.org >> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SSBO's in UniformBlocks list?
On Tue, 2015-09-29 at 18:41 +0300, Francisco Jerez wrote: > Ilia Mirkin writes: > > > On Tue, Sep 29, 2015 at 4:33 AM, Iago Toral 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? > > > Yeah, this seems rather dubious to me too. Even if you had re-used the > current gl_uniform_block type for SSBOs for the sake of code-sharing I > think it would have made more sense to split them into a different index > space, because SSBOs are a different index space at the API level and > drivers will want them to be a different index space too. In the case of i965 at least I think having them combined makes things easier because from the driver perspective the only difference between SSBOs and UBOs is that the underlying buffer storage has different flags. This was the simplest implementation and in theory, translating from the shared space to a separate space should be very easy too, so drivers that need a separate space should be able to get that as well... That's in theory, the problem is that Ilia is saying that in his case the compiler backend may not have the information required to make this translation, and if this is true then we'll have to rethink this... > I believe that this leads to a bug the i965 implementation -- We expose > 12 SSBOs per stage and 12 UBOs per stage, but we only have 12 binding > table entries reserved for the block of the binding table currently > shared among UBOs and SSBOs, so you might overflow the number of > available surface entries if the combined number of UBOs and SSBOs is > greater than 12 for some stage. Yeah, we forgot to update that. I'll send a patch to fix this. Thanks Curro! Iago > > Thanks, > > > > -ilia > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SSBO's in UniformBlocks list?
On Wed, 2015-09-30 at 02:34 -0400, Ilia Mirkin wrote: > On Wed, Sep 30, 2015 at 2:26 AM, Iago Toral wrote: > > On Tue, 2015-09-29 at 11:19 -0400, Ilia Mirkin wrote: > >> On Tue, Sep 29, 2015 at 4:33 AM, Iago Toral 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? Iago > > We assumed that backends could work with a shared index space between > > UBOs and SSBOs. In i965 at least that is not a problem and makes things > > easy: we simply use the block index we get from the IR directly, the > > driver does not use a separate buffer space for them and handles SSBOs > > just the same as UBOs, only that the buffer has different flags. > > > > However, if we think this is not ideal we can look into having separate > > index spaces. > > Hrm that's definitely not the way I was implementing it in TGSI. I > was going to have a separate thing for buffers, to be used to > implement both ssbo and counters. Also on NVIDIA hardware, constbufs > get special binding points while shader buffers are just addresses > loaded from (ironically) a constbuf. I believe it's a similar > situation on r600-class hardware, not 100% sure about SI. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SSBO's in UniformBlocks list?
On Wed, Sep 30, 2015 at 2:26 AM, Iago Toral wrote: > On Tue, 2015-09-29 at 11:19 -0400, Ilia Mirkin wrote: >> On Tue, Sep 29, 2015 at 4:33 AM, Iago Toral 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? > > We assumed that backends could work with a shared index space between > UBOs and SSBOs. In i965 at least that is not a problem and makes things > easy: we simply use the block index we get from the IR directly, the > driver does not use a separate buffer space for them and handles SSBOs > just the same as UBOs, only that the buffer has different flags. > > However, if we think this is not ideal we can look into having separate > index spaces. Hrm that's definitely not the way I was implementing it in TGSI. I was going to have a separate thing for buffers, to be used to implement both ssbo and counters. Also on NVIDIA hardware, constbufs get special binding points while shader buffers are just addresses loaded from (ironically) a constbuf. I believe it's a similar situation on r600-class hardware, not 100% sure about SI. Cheers, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SSBO's in UniformBlocks list?
On Tue, 2015-09-29 at 11:19 -0400, Ilia Mirkin wrote: > On Tue, Sep 29, 2015 at 4:33 AM, Iago Toral 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? We assumed that backends could work with a shared index space between UBOs and SSBOs. In i965 at least that is not a problem and makes things easy: we simply use the block index we get from the IR directly, the driver does not use a separate buffer space for them and handles SSBOs just the same as UBOs, only that the buffer has different flags. However, if we think this is not ideal we can look into having separate index spaces. Iago ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SSBO's in UniformBlocks list?
Ilia Mirkin writes: > On Tue, Sep 29, 2015 at 4:33 AM, Iago Toral 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? > Yeah, this seems rather dubious to me too. Even if you had re-used the current gl_uniform_block type for SSBOs for the sake of code-sharing I think it would have made more sense to split them into a different index space, because SSBOs are a different index space at the API level and drivers will want them to be a different index space too. I believe that this leads to a bug the i965 implementation -- We expose 12 SSBOs per stage and 12 UBOs per stage, but we only have 12 binding table entries reserved for the block of the binding table currently shared among UBOs and SSBOs, so you might overflow the number of available surface entries if the combined number of UBOs and SSBOs is greater than 12 for some stage. > Thanks, > > -ilia > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SSBO's in UniformBlocks list?
On Tue, Sep 29, 2015 at 4:33 AM, Iago Toral 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? Thanks, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SSBO's in UniformBlocks list?
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. If I remember correctly, Jordan suggested that we might want to change the names of the structures/files involved so they do not refer to UBOs explicitly and use something more generic instead, but that would be a very large change affecting the compiler (and all the drivers) and we thought it would be best to do that at some other moment, after the series landed, to avoid being stuck in rebase hell for months. Iago > Thanks, > > -ilia > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
