[Mesa-stable] [Mesa-dev] [PATCH V3] glsl: fix atomic buffer index for bindings other than 0
Timothy Arceri
t_arceri at yahoo.com.au
Tue Sep 1 20:01:17 PDT 2015
On Tue, 2015-09-01 at 14:46 +0100, Emil Velikov wrote:
> On 29 July 2015 at 13:46, Timothy Arceri <t_arceri at yahoo.com.au> wrote:
> > On Wed, 2015-07-29 at 09:57 +0200, Iago Toral wrote:
> > > On Sun, 2015-07-26 at 18:35 +1000, Timothy Arceri wrote:
> > > > Since commit c0cd5b var->data.binding was being used as a replacement
> > > > for atomic buffer index, but they don't have to be the same value they
> > > > just happen to end up the same when binding is 0.
> > > >
> > > > Now we store atomic buffer index in the unused var->data.index
> > > > to avoid the extra memory of putting back the atmoic buffer index
> > > > field.
> > >
> > > Could this be a bit too restrictive? var->data.index has only a single
> > > bit of storage, so this would limit the number of buffers we can index
> > > to 2.
> >
> > Your right I wasn't paying enough attention, the nir struct doesn't place
> > the
> > same limits on index (although maybe it should) and I didn't notice it in
> > the
> > glsl ir.
> >
> > I have a new solution on the way as part on V3 of my AoA work, however its
> > not
> > really suitable for stable.
> >
> > If we want this fix in stable maybe putting back the atomic_index struct
> > member is the best solution after all.
> >
> I guess we can/should drop this from the queue, or is it something
> still worthy for stable ?
> If so, can anyone let me know of the requirements (commit name and/or
> sha should be great).
>
Yeah drop this. Soory for the noise, I've got a better fix as part of the AoA
work but its maybe too invasive for stable.
> Thanks,
> Emil
More information about the mesa-stable
mailing list