[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 #59 from Iago Toral <itoral at igalia.com> ---
(In reply to Francisco Jerez from comment #58)
> (In reply to Iago Toral from comment #57)
> >[...]
> > 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 comment #52 (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.

Ok, I'll implement 2) in that case.

-- 
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/20150512/bb696f28/attachment.html>