[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 #58 from Francisco Jerez <currojerez at riseup.net> ---
(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.

-- 
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/20150511/fcc7c529/attachment.html>