[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 #57 from Iago Toral <itoral at igalia.com> ---
(In reply to Francisco Jerez from comment #56)
(...)
> I was thinking that it wouldn't make sense to re-implement this
> madness in the SSBO handling code.  ARB_shader_image_load_store
> uses the exact same messages so we should share a common
> implementation.  Check out the for-iago branch of my mesa
> repository [1], I've ripped out everything specific to
> ARB_shader_image_load_store, what is left is the code for
> building and sending typed and untyped surface messages, along
> with some dependencies.  It should make your task considerably
> easier.  There are emit_untyped_read(), emit_untyped_write() and
> emit_untyped_atomic() functions you can call passing the surface
> index you want to access, the address and argument vectors,
> number of address dimensions (typically one for SSBOs) and number
> of 32-bit components to write or read.  It will give you the
> result (if any) in a register returned by the function.  It
> should take care of most hardware quirks for you (SIMD mode
> restrictions, differences in header and vector layout across
> generations).
> 
> [1] http://cgit.freedesktop.org/~currojerez/mesa/log/?h=for-iago

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.

-- 
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/db8454a7/attachment-0001.html>