aboutsummaryrefslogtreecommitdiffstats
path: root/src/intel/compiler/brw_fs.cpp
Commit message (Collapse)AuthorAgeFilesLines
* intel/fs: Lower integer multiply correctly when destination stride equals 4.Francisco Jerez2019-02-211-4/+8
| | | | | | | | | | | | | | | | | Because the "low" temporary needs to be accessed with word type and twice the original stride, attempting to preserve the alignment of the original destination can potentially lead to instructions with illegal destination stride greater than four. Because the CHV/BXT alignment restrictions are now being enforced by the regioning lowering pass run after lower_integer_multiplication(), there is no real need to preserve the original strides anymore. Note that this bug can be reproduced on stable branches, but back-porting would be non-trivial, because the fix relies on the regioning lowering pass recently introduced. Tested-by: Anuj Phogat <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* intel/fs: Exclude control sources from execution type and region alignment ↵Francisco Jerez2019-02-211-0/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | calculations. Currently the execution type calculation will return a bogus value in cases like: mov_indirect(8) vgrf0:w, vgrf1:w, vgrf2:ud, 32u Which will be considered to have a 32-bit integer execution type even though the actual indirect move operation will be carried out with 16-bit precision. Similarly there's no need to apply the CHV/BXT double-precision region alignment restrictions to such control sources, since they aren't directly involved in the double-precision arithmetic operations emitted by these virtual instructions. Applying the CHV/BXT restrictions to control sources was expected to be harmless if mildly inefficient, but unfortunately it exposed problems at codegen level for virtual instructions (namely the SHUFFLE instruction used for the Vulkan 1.1 subgroup feature) that weren't prepared to accept control sources with an arbitrary strided region. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109328 Reported-by: Mark Janes <[email protected]> Fixes: efa4e4bc5fc "intel/fs: Introduce regioning lowering pass." Tested-by: Anuj Phogat <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* intel/fs: Implement nir_intrinsic_global_atomic_*Jason Ekstrand2019-02-011-0/+47
| | | | eviewed-by: Kenneth Graunke <[email protected]>
* intel/fs: Use SENDS for A64 writes on gen9+Jason Ekstrand2019-02-011-10/+23
| | | | eviewed-by: Kenneth Graunke <[email protected]>
* intel/fs: Implement load/store_global with A64 untyped messagesJason Ekstrand2019-02-011-0/+107
| | | | eviewed-by: Kenneth Graunke <[email protected]>
* intel/fs: Properly handle 64-bit types in LOAD_PAYLOADJason Ekstrand2019-02-011-2/+6
| | | | | | | | | By just assigning dst.type to src[i].type, we ensure that the offset at the end of the loop actually offsets it by the right number of registers. Otherwise, we'll get into a case where we copy with a Q type and then offset with a D type and things get out of sync. Reviewed-by: Kenneth Graunke <[email protected]>
* intel/fs: Use split sends for surface writes on gen9+Jason Ekstrand2019-01-291-18/+32
| | | | | | | | | | | | | Surface reads don't need them because they just have the one address payload. With surface writes, on the other hand, we can put the address and the data in the different halves and avoid building the payload all together. The decrease in register pressure and added freedom in register allocation resulting from this change reduces spilling enough to improve the performance of one customer benchmark by about 2x. Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Support SENDS in SHADER_OPCODE_SENDJason Ekstrand2019-01-291-0/+50
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Use SHADER_OPCODE_SEND for varying UBO pulls on gen7+Jason Ekstrand2019-01-291-6/+25
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Use SHADER_OPCODE_SEND for texturing on gen7+Jason Ekstrand2019-01-291-5/+133
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Use a logical opcode for IMAGE_SIZEJason Ekstrand2019-01-291-0/+10
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Use SHADER_OPCODE_SEND for surface messagesJason Ekstrand2019-01-291-53/+129
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Add a generic SEND opcodeJason Ekstrand2019-01-291-0/+13
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Handle IMAGE_SIZE in size_read() and is_send_from_grf()Jason Ekstrand2019-01-291-0/+2
| | | | | | | Like all the other sends, it's just mlen * REG_SIZE. Fixes: 3cbc02e4693 "intel: Use TXS for image_size when we have..." Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Get rid of fs_inst::equalsJason Ekstrand2019-01-291-22/+7
| | | | | | | | | | There are piles of fields that it doesn't check so using it is a lie. The only reason why it's not causing problem is because it has exactly one user which only uses it for MOV instructions (which aren't very interesting) and only on Sandy Bridge and earlier hardware. Just get rid of it and inline it in the one place that it's actually used. Reviewed-by: Iago Toral Quiroga <[email protected]>
* i965: Drop mark_surface_used mechanism.Kenneth Graunke2019-01-131-4/+0
| | | | | | | | | | | | | | | | | | | | | The original idea was that the backend compiler could eliminate surfaces, so we would have it mark which ones are actually used, then shrink the binding table accordingly. Unfortunately, it's a pretty blunt mechanism - it can only prune things from the end, not the middle - since we decide the layout before we even start the backend compiler, and only limit the size. It also basically gives up if it sees indirect array access. Besides, we do the vast majority of our surface elimination in NIR anyway, not the backend - and I don't see that trend changing any time soon. Vulkan abandoned this plan a long time ago, and I don't use it in Iris, but it's still been kicking around in i965. I hacked shader-db to print the binding table size in bytes, and observed no changes with this patch. So, this code appears to do nothing useful. Acked-by: Jason Ekstrand <[email protected]>
* intel/compiler: Prevent warnings in the following patchMatt Turner2019-01-091-9/+9
| | | | | | | | | | The next patch replaces an unsigned bitfield with a plain unsigned, which triggers gcc to begin warning on signed/unsigned comparisons. Keeping this patch separate from the actual move allows bisectablity and generates no additional warnings temporarily. Reviewed-by: Kenneth Graunke <[email protected]>
* intel/compiler: Lower 64-bit MOV/SEL operationsMatt Turner2019-01-091-1/+49
|
* intel/fs: Remove FS_OPCODE_UNPACK_HALF_2x16_SPLIT opcodes.Francisco Jerez2019-01-091-2/+0
| | | | | | | | These are broken on a future platform, but it turns out we don't need to fix them, since they're just type-converting moves with strided source. Kill them. Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Remove existing lower_conversions pass.Francisco Jerez2019-01-091-4/+1
| | | | | | It's redundant with the functionality provided by lower_regioning now. Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Introduce regioning lowering pass.Francisco Jerez2019-01-091-1/+4
| | | | | | | | | | | | | | | | | This legalization pass is meant to handle situations where the source or destination regioning controls of an instruction are unsupported by the hardware and need to be lowered away into separate instructions. This should be more reliable and future-proof than the current approach of handling CHV/BXT restrictions manually all over the visitor. The same mechanism is leveraged to lower unsupported type conversions easily, which obsoletes the lower_conversions pass. v2: Give conditional modifiers the same treatment as predicates for SEL instructions in lower_dst_modifiers() (Iago). Special-case a couple of other instructions with inconsistent conditional mod semantics in lower_dst_modifiers() (Curro). Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Constify fs_inst::can_do_source_mods().Francisco Jerez2019-01-091-1/+1
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Fix bug in lower_simd_width while splitting an instruction which ↵Francisco Jerez2019-01-091-2/+5
| | | | | | | | | | | | | was already split. This seems to be a problem in combination with the lower_regioning pass introduced by a future commit, which can modify a SIMD-split instruction causing its execution size to become illegal again. A subsequent call to lower_simd_width() would hit this bug on a future platform. Cc: [email protected] Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Implement quad swizzles on ICL+.Francisco Jerez2019-01-091-3/+26
| | | | | | | | | | | | | Align16 is no longer a thing, so a new implementation is provided using Align1 instead. Not all possible swizzles can be represented as a single Align1 region, but some fast paths are provided for frequently used swizzles that can be represented efficiently in Align1 mode. Fixes ~90 subgroup quad swap Vulkan CTS tests. Cc: [email protected] Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Handle source modifiers in lower_integer_multiplication().Francisco Jerez2019-01-091-2/+18
| | | | | | | | | | | | lower_integer_multiplication() implements 32x32-bit multiplication on some platforms by bit-casting one of the 32-bit sources into two 16-bit unsigned integer portions. This can give incorrect results if the original instruction specified a source modifier. Fix it by emitting an additional MOV instruction implementing the source modifiers where necessary. Cc: [email protected] Reviewed-by: Iago Toral Quiroga <[email protected]>
* i965/fs: Eliminate unary op on operand of compare-with-zeroIan Romanick2018-12-171-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The (-abs(x) >= 0) => (x == 0) optimization is removed from the vec4 and scalar parts. In the VS part, adding the new pattern was not helpful. The pattern that is removed is really old, and it has been handled by NIR for ages. All Gen7+ platforms had similar results. (Broadwell shown) total instructions in shared programs: 14715715 -> 14715709 (<.01%) instructions in affected programs: 474 -> 468 (-1.27%) helped: 6 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 1.12% max: 1.35% x̄: 1.28% x̃: 1.35% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -1.40% -1.15% Instructions are helped. total cycles in shared programs: 559569911 -> 559569809 (<.01%) cycles in affected programs: 5963 -> 5861 (-1.71%) helped: 6 HURT: 0 helped stats (abs) min: 16 max: 18 x̄: 17.00 x̃: 17 helped stats (rel) min: 1.45% max: 1.88% x̄: 1.73% x̃: 1.85% 95% mean confidence interval for cycles value: -18.15 -15.85 95% mean confidence interval for cycles %-change: -1.95% -1.51% Cycles are helped. Iron Lake and Sandy Bridge had similar results. (Iron Lake shown) total instructions in shared programs: 7780915 -> 7780913 (<.01%) instructions in affected programs: 246 -> 244 (-0.81%) helped: 2 HURT: 0 total cycles in shared programs: 177876108 -> 177876106 (<.01%) cycles in affected programs: 3636 -> 3634 (-0.06%) helped: 1 HURT: 0 GM45 total instructions in shared programs: 4799152 -> 4799151 (<.01%) instructions in affected programs: 126 -> 125 (-0.79%) helped: 1 HURT: 0 total cycles in shared programs: 122052654 -> 122052652 (<.01%) cycles in affected programs: 3640 -> 3638 (-0.05%) helped: 1 HURT: 0 Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]>
* intel/fs: Support min_lod parameters on texture instructionsJason Ekstrand2018-12-111-1/+21
| | | | | | | | We have to lower some shadow instructions because they don't exist in hardware and we have to lower txb+offset+clamp because the message gets too big and we run into the sampler message length limit of 11 regs. Acked-by: Ian Romanick <[email protected]>
* i965/fs: Handle V/UV immediates in dump_instructions()Matt Turner2018-12-101-0/+5
|
* intel/compiler: fix indentation style in opt_algebraic()Iago Toral Quiroga2018-11-271-10/+10
|
* i965: Do NIR shader cloning in the caller.Kenneth Graunke2018-11-201-2/+1
| | | | | | | | | | | | This moves nir_shader_clone() to the driver-specific compile function, rather than the shared src/intel/compiler code. This allows i965 to do key-specific passes before calling brw_compile_*. Vulkan should not need this cloning as it doesn't compile multiple variants. We do need to continue cloning in the compute shader code because we lower various things in NIR based on the SIMD width. Reviewed-by: Alejandro Piñeiro <[email protected]>
* intel/compiler: Stop assuming the entrypoint is called "main"Jason Ekstrand2018-10-301-3/+0
| | | | | | | | | | | This isn't true for Vulkan so we have to whack it to "main" in anv which is silly. Instead of walking the list of functions and asserting that everything is named "main" and hoping there's only one function named "main", just use the nir_shader_get_entrypoint() helper which has better assertions anyway. Reviewed-by: Lionel Landwerlin <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel/compiler/icl: Use invocation id bits 22:16 instead of 23:17Topi Pohjolainen2018-10-171-2/+6
| | | | | | | | | | | | | | Identifier bits in the dispatch header have changed. See Bspec: SINGLE_PATCH Payload: 3D Pipeline Stages - 3D Pipeline Geometry - Hull Shader (HS) Stage IVB+ - Payloads IVB+ Fixes: KHR-GL46.tessellation_shader.tessellation_shader_tc_barriers.barrier_guarded_read_write_calls Reviewed-by: Anuj Phogat <[email protected]> Signed-off-by: Topi Pohjolainen <[email protected]>
* i965/fs: Add 64-bit int immediate support to dump_instructions()Matt Turner2018-10-161-0/+6
| | | | | Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel: Don't propagate conditional modifiers if a UD source is negatedJason Ekstrand2018-10-101-0/+19
| | | | | | | | | This fixes a bug uncovered by my NIR integer division by constant optimization series. Fixes: 19f9cb72c8b "i965/fs: Add pass to propagate conditional..." Fixes: 627f94b72e0 "i965/vec4: adding vec4_cmod_propagation..." Reviewed-by: Ian Romanick <[email protected]>
* Replace uses of _mesa_bitcount with util_bitcountDylan Baker2018-09-071-1/+2
| | | | | | | | | | | | | and _mesa_bitcount_64 with util_bitcount_64. This fixes a build problem in nir for platforms that don't have popcount or popcountll, such as 32bit msvc. v2: - Fix additional uses of _mesa_bitcount added after this was originally written Acked-by: Eric Engestrom <[email protected]> (v1) Acked-by: Eric Anholt <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* anv,i965: Lower away image derefs in the driverJason Ekstrand2018-08-291-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the back-end compiler turn image access into magic uniform reads and there was a complex contract between back-end compiler and driver about setting up and filling out those params. As of this commit, both drivers now lower image_deref_load_param_intel intrinsics to load_uniform intrinsics controlled by the driver and lower the other image_deref_* intrinsics to image_* intrinsics which take an actual binding table index. There are still "magic" uniforms but they are now added and controlled entirely by the driver and that contract no longer spans components. This also has the side-effect of making most image use compile-time binding table indices. Previously, all image access pulled the binding table index from a uniform. Part of the reason for this was that the magic uniforms made it difficult to decouple binding table indices from the uniforms and, since they are indexed completely differently (especially in Vulkan), it was hard to pull them apart. Now that the driver is handling both, it's trivial to decouple the two and provide actual binding table indices. Shader-db results on Kaby Lake: total instructions in shared programs: 15166872 -> 15164293 (-0.02%) instructions in affected programs: 115834 -> 113255 (-2.23%) helped: 191 HURT: 0 total cycles in shared programs: 571311495 -> 571196465 (-0.02%) cycles in affected programs: 4757115 -> 4642085 (-2.42%) helped: 73 HURT: 67 total spills in shared programs: 10951 -> 10926 (-0.23%) spills in affected programs: 742 -> 717 (-3.37%) helped: 7 HURT: 0 total fills in shared programs: 22226 -> 22201 (-0.11%) fills in affected programs: 1146 -> 1121 (-2.18%) helped: 7 HURT: 0 Reviewed-by: Kenneth Graunke <[email protected]>
* intel/compiler: Implement untyped atomic float min, max, and compare-swap ↵Ian Romanick2018-08-221-0/+23
| | | | | | | | | | dataport messages v2: Split changes to the message type field to another patch. Suggested by Caio. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* intel: Fix SIMD16 unaligned payload GRF reads on Gen4-5.Kenneth Graunke2018-08-091-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the SIMD16 Gen4-5 fragment shader payload contains source depth (g2-3), destination stencil (g4), and destination depth (g5-6), the single register of stencil makes the destination depth unaligned. We were generating this instruction in the RT write payload setup: mov(16) m14<1>F g5<8,8,1>F { align1 compr }; which is illegal, instructions with a source region spanning more than one register need to be aligned to even registers. This is because the hardware implicitly does (nr | 1) instead of (nr + 1) when splitting the compressed instruction into two mov(8)'s. I believe this would cause the hardware to load g5 twice, replicating subspan 0-1's destination depth to subspan 2-3. This showed up as 2x2 artifact blocks in both TIS-100 and Reicast. Normally, we rely on the register allocator to even-align our virtual GRFs. But we don't control the payload, so we need to lower SIMD widths to make it work. To fix this, we teach lower_simd_width about the restriction, and then call it again after lower_load_payload (which is what generates the offending MOV). Fixes: 8aee87fe4cce0a883867df3546db0e0a36908086 (i965: Use SIMD16 instead of SIMD8 on Gen4 when possible.) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107212 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=13728 Reviewed-by: Jason Ekstrand <[email protected]> Tested-by: Diego Viola <[email protected]>
* i965/fs: Flag all slots of a flat input as flatJason Ekstrand2018-08-011-6/+9
| | | | | | | | | | | | | | | | Otherwise, only the first vec4 of a matrix or other complex type will get marked as flat and we'll interpolate the others. This was caught by a dEQP test which started failing because it did a SSO vs. non-SSO comparison. Previously, we did the interpolation wrong consistently in both versions. However, with one of Tim Arceri's NIR linkingpatches, we started splitting the matrix input into vectors at link time in the non-SSO version and it started getting correctly interpolated which didn't match the broken SSO version. As of this commit, they both get correctly interpolated. Fixes: e61cc87c757f8bc "i965/fs: Add a flat_inputs field to prog_data" Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* intel/compiler: fix -Wsign-compare warningCaio Marcelo de Oliveira Filho2018-07-181-1/+1
| | | | | | | | | | | | Explicitly convert to signed integer. Conversion is valid since is the same (implicitly) used to initialize the loop. Avoids the warning: ../../src/intel/compiler/brw_fs.cpp: In member function ‘bool fs_visitor::lower_simd_width()’: ../../src/intel/compiler/brw_fs.cpp:5761:45: warning: comparison of integer expressions of different signedness: ‘int’ and ‘unsigned int’ [-Wsign-compare] split_inst.eot = inst->eot && i == n - 1; ~~^~~~~~~~ Reviewed-by: Anuj Phogat <[email protected]>
* intel/compiler: silence -Wclass-memaccess warningsCaio Marcelo de Oliveira Filho2018-07-181-3/+3
| | | | Reviewed-by: Anuj Phogat <[email protected]>
* intel/fs: Initialize mlen for gen7 varying pull constant load messages.Francisco Jerez2018-07-091-1/+1
| | | | | | | This makes the message length available at the IR level, which should save some guesswork in a future commit. Reviewed-by: Kenneth Graunke <[email protected]>
* intel/compiler: remove unused functionIago Toral Quiroga2018-07-091-27/+0
| | | | Reviewed-by: Lionel Landwerlin <[email protected]>
* intel/compiler: Relax mixed type restriction for saturating immediatesIan Romanick2018-07-061-2/+11
| | | | | | | | | | | | | | | | | At the time of commit 7bc6e455e23 (i965: Add support for saturating immediates.) we thought mixed type saturates would be impossible. We were only thinking about type converting moves from D to F, for example. However, type converting moves w/saturate from F to DF are definitely possible. This change minimally relaxes the restriction to allow cases that I have been able trigger via piglit tests. Fixes new piglit tests: - arb_gpu_shader_fp64/execution/built-in-functions/fs-sign-sat-neg-abs.shader_test - arb_gpu_shader_fp64/execution/built-in-functions/vs-sign-sat-neg-abs.shader_test Signed-off-by: Ian Romanick <[email protected]> Cc: [email protected] Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* intel/fs: Build 32-wide FS shaders.Francisco Jerez2018-06-281-11/+43
| | | | Co-authored-by: Jason Ekstrand <[email protected]>
* intel/fs: Get rid of MOV_DISPATCH_TO_FLAGSJason Ekstrand2018-06-281-3/+5
| | | | | | We can just emit the MOV in the two places where we use this. Reviewed-by: Matt Turner <[email protected]>
* intel/fs: Emit MOV_DISPATCH_TO_FLAGS once for the centroid workaroundJason Ekstrand2018-06-281-39/+0
| | | | | | | There's no reason for us to emit it a pile of times and then have a whole pass to clean it up. Just emit it once like we really want. Reviewed-by: Matt Turner <[email protected]>
* intel/fs: Fix sample id setup for SIMD32.Francisco Jerez2018-06-281-9/+25
| | | | | | | | v2 (Jason Ekstrand): - Disallow gl_SampleId in SIMD32 on gen7 Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* intel/fs: Fix Gen7 compressed source region alignment restriction for SIMD32Francisco Jerez2018-06-281-1/+7
| | | | | Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* intel/fs: Implement 32-wide FS payload setup on Gen6+Francisco Jerez2018-06-281-67/+57
| | | | | Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Matt Turner <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-02 21:01:47 +0000