<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#c59">Comment # 59</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#c58">comment #58</a>)
<span class="quote">> (In reply to Iago Toral from <a href="show_bug.cgi?id=89597#c57">comment #57</a>)
> >[...]
> > Thanks a lot Francisco, I have merged your code into our tree and reworked
> > our FS reads and writes successfully, however, I am not sure if we can use
> > emit_untyped_write() to implement ivybridge vec4 writes.
> >
> > The problem I see is that this function takes a size parameter with the
> > number of components we want to write, but it does not know which components
> > they are.
> >
> > For example, if I have something lke v.xz = vec2(1,3) there is no way for
> > the function to know that I want to write at offsets 0 and 8. If we pass a
> > size=2 it will write a value of 1 at offset 0 but instead of writing 3 at
> > offset 8 it will write garbage at offset 4. If we pass size=4 then it will
> > write 1, 3 at offsets 0 and 8 as expected, but it will also write garbage at
> > offsets 4 and 12 of course.
> >
> > Unfortunately, the PRM also says this:
> >
> > "For the Untyped Surface Write message, each channel mask cannot be 0 unless
> > all of the lower mask bits are also zero. This means that the only 4-bit
> > channel mask values allowed are 0000b, 1000b, 1100b, and 1110b. Other
> > messages allow any combination of channel masks."
> >
> > So we cannot set the channel mask to inform the message that it should only
> > write to offsets 0 and 4 even if we changed the signature of the function
> > (for example to add a writemask parameter).
> >
> > I only see two ways to fix this:
> >
> > 1) Go back to the solution I explained in <a href="show_bug.cgi?id=89597#c52">comment #52</a> (in which we only use
> > one channel and instead use the writemask to filter the components we want
> > to write). Since you made a good case for keeping the symmetry between typed
> > and untyped messages, if we go with this I guess it would mean to write a
> > new opcode specifically for vec4/ivybridge so we can keep the current
> > messages untouched.
> >
> > 2) Emit a separate write message for each component of the vector if we are
> > not writing the entire vector.
> >
> > The second option does not look like a good idea in any case though, so I'd
> > go with 1) unless you have a better idea.
>
> I doubt it's terribly important, worst-case 2) will increase the
> latency of the request if you need to emit two rather than one
> message, but they will still be pipelined so it's unlikely to
> matter much. I think I would refrain from introducing
> significant complexity for an IVB- and vec4-specific optimization
> until we have some evidence that it helps in some realistic
> scenario. We can always go back and add the new opcode if we
> find out it's helpful for some application.</span >
Ok, I'll implement 2) in that case.</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>