<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Implement SSBOs in GLSL front-end and i965" href="https://bugs.freedesktop.org/show_bug.cgi?id=89597#c29">Comment # 29</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Implement SSBOs in GLSL front-end and i965" href="https://bugs.freedesktop.org/show_bug.cgi?id=89597">bug 89597</a> from <a class="email" href="mailto:itoral@igalia.com" title="Iago Toral <itoral@igalia.com>"> Iago Toral</a> <pre>(In reply to Matt Turner from <a href="show_bug.cgi?id=89597#c27">comment #27</a>) > (In reply to Iago Toral from <a href="show_bug.cgi?id=89597#c25">comment #25</a>) > > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>