[Bug 89597] Implement SSBOs in GLSL front-end and i965

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon May 4 06:43:58 PDT 2015


https://bugs.freedesktop.org/show_bug.cgi?id=89597

--- Comment #41 from Iago Toral <itoral at igalia.com> ---
(In reply to Francisco Jerez from comment #40)
> (In reply to Iago Toral from comment #39)
> >[...]
> > > > Would this be an option?
> > > >
> > > > If that is not a good idea, then I guess the alternative would be to do it
> > > > the other way around: fix the dispatch mask in the read/write messages to be
> > > > like the pixel mask we use in atomic operations, but I don't know if that is
> > > > possible.
> > > 
> > > AFAIK scattered DWORD read and write messages don't to take a
> > > sample mask independent from the execution mask.  It seems to me
> > > that they aren't particularly well-suited for this extension.
> > > Is there any reason you aren't using untyped surface reads and
> > > writes instead?  That would allow you to provide an explicit
> > > sample mask, share some code with ARB_shader_image_load_store by
> > > using the same instructions (I'll land my patches adding support
> > > for untyped surface writes shortly), and access up to 128 bits of
> > > data per channel and message, likely giving better performance in
> > > the long run.
> > 
> > Not really, I started this using oword writes, but that had some issues with
> > unaligned offsets so Jason suggested using scattered writes instead. At that
> > moment it seemed like that was a good fit for fragment shaders: it would
> > allow us to write up to 8/16 dwords at random dword offsets and that seemed
> > to work great in all scenarios... until I played with some more elaborate
> > tests that combined atomics and writes in the fragment shader and noticed
> > this problem with the pixel mask included with atomic messages.
> > 
> > So unless someone else has a clever idea to respect the pixel mask with
> > scattered write messages I guess I should at least look into untyped write
> > messages. I imagine that reads are fine with scattered messages since
> > channels that are not in the pixel mask will be ignored at write time.
> 
> I doubt there is much benefit from using scattered dword messages even if
> they would work for reads, untyped surface messages can do a superset of
> what the scatter messages do, and they might save bandwidth in cases where
> contiguous dwords are read sequentially, as they can read up to four dwords
> at once.  Aside from that you would avoid the hassle of defining and
> implementing new opcodes.

You are probably right. I'll use this for reads as well then. Thanks again!

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20150504/207cb698/attachment.html>


More information about the intel-3d-bugs mailing list