[Bug 89597] Implement SSBOs in GLSL front-end and i965

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed May 6 23:27:51 PDT 2015


https://bugs.freedesktop.org/show_bug.cgi?id=89597

--- Comment #50 from Iago Toral <itoral at igalia.com> ---
Francisco, your implementation of brw_untyped_surface_write in brw_eu_emit.c
fixes the mask to use for the dst, which in turn decides which channels are
effectively written to memory.

For vec4 and gen7 (except haswell) it sets the writemask to WRITEMASK_X, but I
think we want clients of this function to decide the writemask to use. For
example, if we are writing a vec4, I want to use WRITEMASK_XYZW (even if we are
using SIMD8 mode) to get all 4 components written directly. Fixing the
writemask inside this function seems a bit restrictive.

Would you be okay with the addition of a dst parameter to this function? The
clients (generator or visitor) would be responsible for setting the appropriate
writemask on that dst depending on the situation.

Since we are using WRITEMASK_XYZW for all FS invocations I think in that case
we can have the generator set the dst parameter as 
brw_writemask(brw_null_reg(), WRITEMASK_XYZW), but for vec4 the  visitor would
do the same, but injecting the writemask it needs depending on the case, then
the vec4 generator would just pass that dst to brw_untyped_surface_write. I was
also thinking about passing the writemask as a separate parameter to the
generator opcode, but it looks like generator opcodes can only take 3 src
arguments and we are already using them, so passing it as part of the dst seems
like the best way to go.

-- 
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/20150507/90a9d333/attachment.html>


More information about the intel-3d-bugs mailing list