<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Implement SSBOs in GLSL front-end and i965"
href="https://bugs.freedesktop.org/show_bug.cgi?id=89597#c41">Comment # 41</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Implement SSBOs in GLSL front-end and i965"
href="https://bugs.freedesktop.org/show_bug.cgi?id=89597">bug 89597</a>
from <span class="vcard"><a class="email" href="mailto:itoral@igalia.com" title="Iago Toral <itoral@igalia.com>"> <span class="fn">Iago Toral</span></a>
</span></b>
<pre>(In reply to Francisco Jerez from <a href="show_bug.cgi?id=89597#c40">comment #40</a>)
<span class="quote">> (In reply to Iago Toral from <a href="show_bug.cgi?id=89597#c39">comment #39</a>)
> >[...]
> > > > 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.</span >
You are probably right. I'll use this for reads as well then. Thanks again!</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>