<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 20, 2016 at 10:47 PM, Francisco Jerez <span dir="ltr"><<a href="mailto:currojerez@riseup.net" target="_blank">currojerez@riseup.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The purpose of this series is to improve the back-end infrastructure<br>
so that lowering of most IR instructions that are too wide to execute<br>
natively (which is far more common than usual in SIMD32 dispatch mode)<br>
happens semi-automatically at the IR level.<br>
<br>
Patches 1-6 address some issues in a few optimization and lowering<br>
passes that would otherwise lead to regressions in the following<br>
changes of the series.  Patches 7-12 move the construction of several<br>
messages into lower_logical_sends() so the SIMD lowering pass can deal<br>
with them.  Patches 13-22 teach the SIMD lowering pass about a number<br>
of additional ISA restrictions that can be enforced easily by<br>
splitting SIMD instructions into smaller chunks.  Patches 23-31 are<br>
mainly about removing generator code that wouldn't have worked on<br>
SIMD32 but is no longer necessary given the infrastructure introduced<br>
in the first part of the series.<br>
<br>
Some of the changes from this series that remove SIMD workarounds<br>
currently implemented in the generator could potentially be left out<br>
at least in the initial merge at the cost of losing ARB_compute_shader<br>
support on VLV and low-end IVB which like Gen8+ don't have enough<br>
threads per subslice to reach the workgroup size requirement specified<br>
by the extension in SIMD16 mode.  Some other changes like the removal<br>
of DDY unrolling from the generator are completely optional right now<br>
although they will eventually be required for SIMD32 fragment shader<br>
support and they seemed like a nice clean-up.<br>
<br>
Expect two more series of roughly the same size coming up soon-ish,<br>
the second one will get the generator code in good shape for SIMD32,<br>
and the third one will address some of the remaining issues of the<br>
compiler back-end so we can start plumbing 32-wide compute shaders<br>
through it and turn the GL 4.3 switch.<br>
<br>
[PATCH 01/31] i965/fs: Fix byte_offset() for MRF/ARF/FIXED_GRF regs.<br>
[PATCH 02/31] i965/fs: Generalize is_uniform() to is_periodic().<br>
[PATCH 03/31] i965/fs: No need to unzip SIMD-periodic sources during SIMD lowering.<br>
[PATCH 04/31] i965/fs: Handle instruction predication in SIMD lowering pass.<br>
[PATCH 05/31] i965/fs: Fix CSE temporary copy for some LOAD_PAYLOAD corner cases.<br>
[PATCH 06/31] i965/fs: Avoid constant propagation when the type sizes don't match.<br></blockquote><div><br></div><div>5 and 6 are Reviewed-by: Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[PATCH 07/31] i965/fs: Hide varying pull constant load message setup behind logical opcode.<br>
[PATCH 08/31] i965/fs: Implement promotion of varying pull loads on Gen4 during SIMD lowering.<br>
[PATCH 09/31] i965/fs: Rename Gen4 physical varying pull constant load opcode.<br>
[PATCH 10/31] i965/fs: Add missing get_latency_gen7() cases for the Gen7 pull constant opcodes.<br>
[PATCH 11/31] i965/fs: Lower math into Gen4-5 send-like instructions in lower_logical_sends.<br>
[PATCH 12/31] i965/fs: Handle SAMPLEINFO consistently like other texturing instructions.<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[PATCH 13/31] i965/fs: Enforce extended math exec size limits during SIMD lowering.<br>
[PATCH 14/31] i965/fs: Enforce common regioning restrictions by SIMD splitting.<br>
[PATCH 15/31] i965/fs: Implement workaround for IVB CMP dependency race in the SIMD lowering pass.<br>
[PATCH 16/31] i965/fs: Implement HSW BFI exec size workarounds in the SIMD lowering pass.<br>
[PATCH 17/31] i965/fs: Assert that IF instruction with embedded compare has legal exec_size.<br>
[PATCH 18/31] i965/fs: Calculate maximum execution size of MOV_INDIRECT correctly.<br>
[PATCH 19/31] i965/fs: Apply usual FPU-like execution size restrictions to MULH.<br>
[PATCH 20/31] i965/fs: Lower DDY instructions to SIMD8 during SIMD lowering time<br></blockquote><div><br></div><div>13-20 Reviewed-by: Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[PATCH 21/31] i965/fs: Lower LOAD_PAYLOAD instructions of unsupported width.<br></blockquote><div> <br></div><div>This one is Reviewed-by: Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> with substantial reservations.  If we ever hit the asserts, we can fix the bugs then.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[PATCH 22/31] i965/fs: Limit SIMD width of various virtual opcodes to the maximum supported value.<br>
[PATCH 23/31] i965/fs: Remove handcrafted math SIMD lowering from the generator.<br>
[PATCH 24/31] i965/fs: Set default access mode to Align1 for all instructions in the generator.<br>
[PATCH 25/31] i965/fs: Drop lowering code for a few three-source instructions from the generator.<br>
[PATCH 26/31] i965/fs: Drop Gen7 CMP SIMD unrolling workaround from the generator.<br>
[PATCH 27/31] i965/fs: Remove manual unrolling of BFI instructions from the generator.<br>
[PATCH 28/31] i965/fs: Remove manual splitting of DDY ops in the generator.<br>
[PATCH 29/31] i965: Define brw_int_type() helper.<br>
[PATCH 30/31] i965/fs: Remove extract virtual opcodes.<br>
[PATCH 31/31] i965/fs: Remove FS_OPCODE_PACK_STENCIL_REF virtual instruction.<br></blockquote><div><br></div><div>22-31 are Reviewed-by: Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
_______________________________________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
</blockquote></div><br></div></div>