[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 #29 from Iago Toral <itoral at igalia.com> ---
(In reply to Matt Turner from comment #27)
> (In reply to Iago Toral from comment #25)
> > I think the FS bits work well now and I have switched focus to vec4. Here
> > the problem is again with non-constant offsets that are not 16-byte aligned
> > (this is actually not working in master for UBOs either). I have a working
> > solution for this, but I'd like to discuss here the details and see what you
> > think about it:
> > 
> > Instead of using scattered messages like we do for writes in the FS I am
> > experimenting with unaligned oword block reads in this case. The solution,
> > that I describe below, seems to work well but I had to work around a couple
> > of issues that maybe can be dealt with in a better way. The solution looks
> > like this (only for non-constant offsets, for constant offsets we can just
> > use dual oword read):
> > 
> > 1) Since unaligned oword messages are not "dual", we have to handle each of
> > the two SIMD4x2 vertices separately, so I emit two separate unaligned reads,
> > one from offset.0 (first vertex) and another from offset.4 (second vertex).
> > I store the results of these reads to separate virtual registers
> > read_result0 and read_result1 respectively.
> > 
> > 2) In the next step I merge both read results into a single register
> > suitable for SIMD4x2 operation. That is, if we call dst the destination of
> > the SIMD4x2 operation, I move the lower half of read_result0 to the lower
> > half of dst and the lower half of read_result1 to the higher half of dst.
> > For this part I have defined a generator opcode (let's call it
> > simd4x2_merge) that I initially implemented as two mov(4) operations, like
> > this:
> > 
> >    brw_MOV(p,
> >            brw_vec4_reg(dst.file, dst.nr, 0),
> >            brw_vec4_reg(src0.file, src0.nr, 0));
> >    brw_MOV(p,
> >            brw_vec4_reg(dst.file, dst.nr, 4),
> >            brw_vec4_reg(src0.file, src1.nr, 0));
> > 
> > The first problem I found with this solution is that in some examples it
> > would trigger the following assertion:
> > 
> > brw_vec4_generator.cpp:1927: void brw::vec4_generator::generate_code(const
> > cfg_t*): Assertion `p->nr_insn == pre_emit_nr_insn + 1 || !"conditional_mod,
> > no_dd_check, or no_dd_clear set for IR " "emitting more than 1 instruction"'
> > failed.
> > 
> > This problem comes from the fact that in these cases,
> > opt_set_dependency_control would set no_dd_clear/no_dd_check on the
> > simd4x2_merge instruction and this does not seem to like the fact that this
> > generator opcode actually expands to more than just one assembly
> > instruction. I did not see an obvious way to deal with this other than
> > skipping opt_set_dependency_control for this generator opcode, since the
> > fact that it spawns more than just one assembly instruction will inevitably
> > lead to this problem. I imagine that it could be possible to fix this more
> > generally by having the generator set dependency control flags on all the
> > instructions emitted by the opcode maybe. Anyway, since there is a 
> > is_dep_ctrl_unsafe() function that seems to be there to select situations
> > where we want to avoid opt_set_dependency_control to kick in, I just added
> > this opcode there. Is there anything else to this scenario that I am missing?
> 
> Your analysis is correct. Though it's easy to work around like we did in
> brw_fs_generator.cpp. See commit 7452f18b -- basically just add a
> 'multiple_instructions_emitted' bool and use it to skip setting the
> dependency control bits.

Ah, i see. That works, thanks!

> > With that fixed, I found another issue with the register coalesce
> > optimization pass, as it attempted to rewrite the simd4x2_merge instruction
> > to write directly to an MRF register using a writemask. As I show above, my
> > first approach to the generator opcode was to have two MOVs that would
> > always write all of the dst register (since that made sense in my context),
> > but if other optimization passes can take the liberty to rewrite the
> > instruction to introduce a writemask then that approach is no longer valid
> > and I have to honor the writemask on the dst. The (small?) problem with that
> > is that as far as I know, I cannot do mov(4) operations that honor
> > dst.dw1.bits.writemask, so I have to do that manually emitting mov(1)
> > operations for each channel enabled. Is there a better way to handle this?
> 
> With the multiple instructions thing fixed, I don't think this needs to be
> solved? I think it's simpler to emit the two MOV(4)s in the generator than
> figuring out what needs to be fixed in the vec4 optimizations to allow it.

No, this behavior is exclusively related to the doings of
opt_register_coalesce, which kicks in before code generation, so the multiple
instructions thing does not help.

In this particular case I think it is not too bad since I think I only need to
deal with the writemask and swizzles of the dst and source operands (I have it
fixed locally), but I was surprised by this effect because if this is happening
here then I guess it means that the same issue could, at least in theory,
happen to other generator opcodes that are probably not considering this
scenario.

-- 
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/20150422/a3dcba19/attachment.html>