On Tue, 2015-09-01 at 14:46 +0100, Emil Velikov wrote: > On 29 July 2015 at 13:46, Timothy Arceri <t_arc...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
