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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #40 from Francisco Jerez <currojerez at riseup.net> ---
(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 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/87ccaa55/attachment.html>