summaryrefslogtreecommitdiffstats
path: root/src/intel/compiler
Commit message (Collapse)AuthorAgeFilesLines
* intel/fs: shuffle_64bit_data_for_32bit_write is not used anymoreJose Maria Casanova Crespo2018-06-162-36/+0
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* intel/fs: Use new shuffle_32bit_write for all 64-bit storage writesJose Maria Casanova Crespo2018-06-161-7/+6
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* intel/fs: shuffle_32bit_load_result_to_64bit_data is not used anymoreJose Maria Casanova Crespo2018-06-162-58/+0
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* intel/fs: Use shuffle_from_32bit_read for 64-bit FS load_inputJose Maria Casanova Crespo2018-06-161-4/+4
| | | | | | | | | As the previous use of shuffle_32bit_load_result_to_64bit_data had a source/destination overlap for 64-bit. Now a temporary destination is used for 64-bit cases to use shuffle_from_32bit_read that doesn't handle src/dst overlaps. Reviewed-by: Jason Ekstrand <[email protected]>
* intel/fs: shuffle_from_32bit_read at load_per_vertex_input at TCS/TESJose Maria Casanova Crespo2018-06-161-14/+8
| | | | | | | | | | | Previously, the shuffle function had a source/destination overlap that needs to be avoided to use shuffle_from_32bit_read. As we can use for the shuffle destination the destination of removed MOVs. This change also avoids the internal MOVs done by the previous shuffle to deal with possible overlaps. Reviewed-by: Jason Ekstrand <[email protected]>
* intel/fs: Use shuffle_from_32bit_read at VS load_inputJose Maria Casanova Crespo2018-06-161-10/+5
| | | | | | | | | | shuffle_from_32bit_read manages 32-bit reads to 32-bit destination in the same way that the previous loop so now we just call the new function for all bitsizes, simplifying also the 64-bit load_input. v2: Add comment about future 16-bit support (Jason Ekstrand) Reviewed-by: Jason Ekstrand <[email protected]>
* intel/fs: Use shuffle_from_32bit_read for 64-bit gs_input_loadJose Maria Casanova Crespo2018-06-161-5/+5
| | | | | | | | | | | | | | | This implementation avoids two unneeded MOVs for each 64-bit component. One was done in the old shuffle, to avoid cases of src/dst overlap but this is not the case. And the removed MOV was already being being done in the shuffle. Copy propagation wasn't able to remove them because shuffle destination values are defined with partial writes because they have stride == 2. v2: Reword commit log summary (Jason Ekstrand) Reviewed-by: Jason Ekstrand <[email protected]>
* intel/fs: shuffle_from_32bit_read for 64-bit do_untyped_vector_readJose Maria Casanova Crespo2018-06-161-10/+2
| | | | | | | | | | do_untyped_vector_read is used at load_ssbo and load_shared. The previous MOVs are removed because shuffle_from_32bit_read can handle storing the shuffle results in the expected destination just using the proper offset. Reviewed-by: Jason Ekstrand <[email protected]>
* intel/fs: Remove old 16-bit shuffle/unshuffle functionsJose Maria Casanova Crespo2018-06-162-73/+0
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* intel/fs: Use shuffle_for_32bit_write for 16-bits store_ssboJose Maria Casanova Crespo2018-06-161-5/+2
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* intel/fs: Use shuffle_from_32bit_read to read 16-bit SSBOJose Maria Casanova Crespo2018-06-161-4/+2
| | | | | | | | Using shuffle_from_32bit_read instead of 16-bit shuffle functions avoids the need of retype. At the same time new function are ready for 8-bit type SSBO reads. Reviewed-by: Jason Ekstrand <[email protected]>
* intel/fs: Use shuffle_from_32bit_read at VARYING_PULL_CONSTANT_LOADJose Maria Casanova Crespo2018-06-161-15/+2
| | | | | | | | | | | | | | shuffle_from_32bit_read can manage the shuffle/unshuffle needed for different 8/16/32/64 bit-sizes at VARYING PULL CONSTANT LOAD. To get the specific component the first_component parameter is used. In the case of the previous 16-bit shuffle, the shuffle operation was generating not needed MOVs where its results where never used. This behaviour passed unnoticed on SIMD16 because dead_code_eliminate pass removed the generated instructions but for SIMD8 they cound't be removed because of being partial writes. Reviewed-by: Jason Ekstrand <[email protected]>
* intel/fs: New shuffle_for_32bit_write and shuffle_from_32bit_readJose Maria Casanova Crespo2018-06-162-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | These new shuffle functions deal with the shuffle/unshuffle operations needed for read/write operations using 32-bit components when the read/written components have a different bit-size (8, 16, 64-bits). Shuffle from 32-bit to 32-bit becomes a simple MOV. shuffle_src_to_dst takes care of doing a shuffle when source type is smaller than destination type and an unshuffle when source type is bigger than destination. So this new read/write functions just need to call shuffle_src_to_dst assuming that writes use a 32-bit destination and reads use a 32-bit source. As shuffle_for_32bit_write/from_32bit_read components take components in unit of source/destination types and shuffle_src_to_dst takes units of the smallest type component, we adjust components and first_component parameters. To enable this new functions it is needed than there is no source/destination overlap in the case of shuffle_from_32bit_read. That never happens on shuffle_for_32bit_write as it allocates a new destination register as it was at shuffle_64bit_data_for_32bit_write. v2: Reword commit log and add comments to explain why first_component and components parameters are adjusted. (Jason Ekstrand) Reviewed-by: Jason Ekstrand <[email protected]>
* intel/fs: general 8/16/32/64-bit shuffle_src_to_dst functionJose Maria Casanova Crespo2018-06-161-0/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This new function takes care of shuffle/unshuffle components of a particular bit-size in components with a different bit-size. If source type size is smaller than destination type size the operation needed is a component shuffle. The opposite case would be an unshuffle. Component units are measured in terms of the smaller type between source and destination. As we are un/shuffling the smaller components from/into a bigger one. The operation allows to skip first_component number of components from the source. Shuffle MOVs are retyped using integer types avoiding problems with denorms and float types if source and destination bitsize is different. This allows to simplify uses of shuffle functions that are dealing with these retypes individually. Now there is a new restriction so source and destination can not overlap anymore when calling this shuffle function. Following patches that migrate to use this new function will take care individually of avoiding source and destination overlaps. v2: (Jason Ekstrand) - Rewrite overlap asserts. - Manage type_sz(src.type) == type_sz(dst.type) case using MOVs from source to dest. This works for 64-bit to 64-bits operation that on Gen7 as it doesn't support Q registers. - Explain that components units are based in the smallest type. v3: - Fix unshuffle overlap assert (Jason Ekstrand) Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Propagate conditional modifiers from not instructionsIan Romanick2018-06-151-1/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Skylake total instructions in shared programs: 14399081 -> 14399010 (<.01%) instructions in affected programs: 26961 -> 26890 (-0.26%) helped: 57 HURT: 0 helped stats (abs) min: 1 max: 6 x̄: 1.25 x̃: 1 helped stats (rel) min: 0.16% max: 0.80% x̄: 0.30% x̃: 0.18% 95% mean confidence interval for instructions value: -1.50 -0.99 95% mean confidence interval for instructions %-change: -0.35% -0.25% Instructions are helped. total cycles in shared programs: 532978307 -> 532976050 (<.01%) cycles in affected programs: 468629 -> 466372 (-0.48%) helped: 33 HURT: 20 helped stats (abs) min: 3 max: 360 x̄: 116.52 x̃: 98 helped stats (rel) min: 0.06% max: 3.63% x̄: 1.66% x̃: 1.27% HURT stats (abs) min: 2 max: 172 x̄: 79.40 x̃: 43 HURT stats (rel) min: 0.04% max: 3.02% x̄: 1.48% x̃: 0.44% 95% mean confidence interval for cycles value: -81.29 -3.88 95% mean confidence interval for cycles %-change: -1.07% 0.12% Inconclusive result (%-change mean confidence interval includes 0). All Gen6+ platforms, except Ivy Bridge, had similar results. (Haswell shown) total instructions in shared programs: 12973897 -> 12973838 (<.01%) instructions in affected programs: 25970 -> 25911 (-0.23%) helped: 55 HURT: 0 helped stats (abs) min: 1 max: 2 x̄: 1.07 x̃: 1 helped stats (rel) min: 0.16% max: 0.62% x̄: 0.28% x̃: 0.18% 95% mean confidence interval for instructions value: -1.14 -1.00 95% mean confidence interval for instructions %-change: -0.32% -0.24% Instructions are helped. total cycles in shared programs: 410355841 -> 410352067 (<.01%) cycles in affected programs: 578454 -> 574680 (-0.65%) helped: 47 HURT: 5 helped stats (abs) min: 3 max: 360 x̄: 85.74 x̃: 18 helped stats (rel) min: 0.05% max: 3.68% x̄: 1.18% x̃: 0.38% HURT stats (abs) min: 2 max: 242 x̄: 51.20 x̃: 4 HURT stats (rel) min: <.01% max: 0.45% x̄: 0.15% x̃: 0.11% 95% mean confidence interval for cycles value: -104.89 -40.27 95% mean confidence interval for cycles %-change: -1.45% -0.66% Cycles are helped. Ivy Bridge total instructions in shared programs: 11679351 -> 11679301 (<.01%) instructions in affected programs: 28208 -> 28158 (-0.18%) helped: 50 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.12% max: 0.54% x̄: 0.23% x̃: 0.16% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -0.27% -0.19% Instructions are helped. total cycles in shared programs: 257445362 -> 257444662 (<.01%) cycles in affected programs: 419338 -> 418638 (-0.17%) helped: 40 HURT: 3 helped stats (abs) min: 1 max: 170 x̄: 65.05 x̃: 24 helped stats (rel) min: 0.02% max: 3.51% x̄: 1.26% x̃: 0.41% HURT stats (abs) min: 2 max: 1588 x̄: 634.00 x̃: 312 HURT stats (rel) min: 0.05% max: 2.97% x̄: 1.21% x̃: 0.62% 95% mean confidence interval for cycles value: -97.96 65.41 95% mean confidence interval for cycles %-change: -1.56% -0.62% Inconclusive result (value mean confidence interval includes 0). No changes on Iron Lake or GM45. v2: Move 'if (cond != BRW_CONDITIONAL_Z && cond != BRW_CONDITIONAL_NZ)' check outside the loop. Suggested by Iago. Signed-off-by: Ian Romanick <[email protected]>
* i965/fs: Rearrange code to remove most of the gotosIan Romanick2018-06-151-11/+3
| | | | Signed-off-by: Ian Romanick <[email protected]>
* i965/fs: Refactor propagation of conditional modifiers from compares to addsIan Romanick2018-06-151-57/+80
| | | | Signed-off-by: Ian Romanick <[email protected]>
* i965/vec4: Optimize OR with 0 into a MOVIan Romanick2018-06-151-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All of the affected shaders are geometry shaders... the same ones from the similar fs changes. The "No changes on any other platforms" comment below is not quite right. Without the previous change to register coalescing, this optimization caused quite a few regressions in tests that either used gl_ClipVertex or used different interpolation modes. I observed that with both patches applied, glsl-1.10/execution/interpolation/interpolation-none-gl_BackSecondaryColor-smooth-vertex.shader_test was one instruction shorter. I suspect other shaders would be similarly affected. Since this is all based on NOS, shader-db does not reflect it. Haswell total instructions in shared programs: 12954955 -> 12954918 (<.01%) instructions in affected programs: 3603 -> 3566 (-1.03%) helped: 37 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.21% max: 2.50% x̄: 1.99% x̃: 2.50% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.30% -1.69% Instructions are helped. total cycles in shared programs: 410012108 -> 410012098 (<.01%) cycles in affected programs: 3540 -> 3530 (-0.28%) helped: 5 HURT: 0 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.28% max: 0.28% x̄: 0.28% x̃: 0.28% 95% mean confidence interval for cycles value: -2.00 -2.00 95% mean confidence interval for cycles %-change: -0.28% -0.28% Cycles are helped. Ivy Bridge total instructions in shared programs: 11679387 -> 11679351 (<.01%) instructions in affected programs: 3292 -> 3256 (-1.09%) helped: 36 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.21% max: 2.50% x̄: 2.04% x̃: 2.50% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.34% -1.74% Instructions are helped. No changes on any other platforms. Signed-off-by: Ian Romanick <[email protected]>
* i965/vec4: Don't register coalesce into source of VS_OPCODE_UNPACK_FLAGS_SIMD4X2Ian Romanick2018-06-151-0/+9
| | | | | | | This prevents regressions in a bunch of clipping and interpolation tests caused by the next patch (i965/vec4: Optimize OR with 0 into a MOV). Signed-off-by: Ian Romanick <[email protected]>
* i965/fs: Optimize OR with 0 into a MOVIan Romanick2018-06-151-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fs_visitor::set_gs_stream_control_data_bits generates some code like "control_data_bits | stream_id << ((2 * (vertex_count - 1)) % 32)" as part of EmitVertex. The first time this (dynamically) occurs in the shader, control_data_bits is zero. Many times we can determine this statically and various optimizations will collaborate to make one of the OR operands literal zero. Converting the OR to a MOV usually allows it to be copy-propagated away. However, this does not happen in at least some shaders (in the assembly output of shaders/closed/UnrealEngine4/EffectsCaveDemo/301.shader_test, search for shl). All of the affected shaders are geometry shaders. Broadwell and Skylake had similar results. (Skylake shown) total instructions in shared programs: 14375452 -> 14375413 (<.01%) instructions in affected programs: 6422 -> 6383 (-0.61%) helped: 39 HURT: 0 helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 helped stats (rel) min: 0.14% max: 2.56% x̄: 1.91% x̃: 2.56% 95% mean confidence interval for instructions value: -1.00 -1.00 95% mean confidence interval for instructions %-change: -2.26% -1.57% Instructions are helped. total cycles in shared programs: 531981179 -> 531980555 (<.01%) cycles in affected programs: 27493 -> 26869 (-2.27%) helped: 39 HURT: 0 helped stats (abs) min: 16 max: 16 x̄: 16.00 x̃: 16 helped stats (rel) min: 0.60% max: 7.92% x̄: 5.94% x̃: 7.92% 95% mean confidence interval for cycles value: -16.00 -16.00 95% mean confidence interval for cycles %-change: -6.98% -4.90% Cycles are helped. No changes on earlier platforms. Signed-off-by: Ian Romanick <[email protected]>
* intel/compiler: Properly consider UBO loads that cross 32B boundaries.Kenneth Graunke2018-06-141-2/+14
| | | | | | | | | | | | | | | | | | | | | | | The UBO push analysis pass incorrectly assumed that all values would fit within a 32B chunk, and only recorded a bit for the 32B chunk containing the starting offset. For example, if a UBO contained the following, tightly packed: vec4 a; // [0, 16) float b; // [16, 20) vec4 c; // [20, 36) then, c would start at offset 20 / 32 = 0 and end at 36 / 32 = 1, which means that we ought to record two 32B chunks in the bitfield. Similarly, dvec4s would suffer from the same problem. v2: Rewrite the accounting, my calculations were wrong. v3: Write a comment about partial values (requested by Jason). Reviewed-by: Rafael Antognolli <[email protected]> [v1] Reviewed-by: Jason Ekstrand <[email protected]> [v3]
* Revert "intel/compiler: Properly consider UBO loads that cross 32B boundaries."Jason Ekstrand2018-06-131-7/+1
| | | | | | This reverts commit b8fa847c2ed9c7c743f31e57560a09fae3992f46. This broke about 30k Vulkan CTS tests.
* intel/compiler: Properly consider UBO loads that cross 32B boundaries.Kenneth Graunke2018-06-131-1/+7
| | | | | | | | | | | | | | | | | | | The UBO push analysis pass incorrectly assumed that all values would fit within a 32B chunk, and only recorded a bit for the 32B chunk containing the starting offset. For example, if a UBO contained the following, tightly packed: vec4 a; // [0, 16) float b; // [16, 20) vec4 c; // [20, 36) then, c would start at offset 20 / 32 = 0 and end at 36 / 32 = 1, which means that we ought to record two 32B chunks in the bitfield. Similarly, dvec4s would suffer from the same problem. Reviewed-by: Rafael Antognolli <[email protected]>
* intel/eu: Use a struct copy instead of a memcpyJason Ekstrand2018-06-051-1/+1
| | | | | | | | | The memcpy had the wrong size and this was causing crashes on 32-bit builds of the driver. Fixes: 6a9525bf6729a8 "intel/eu: Switch to a logical state stack" Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106830 Reviewed-by: Kenneth Graunke <[email protected]>
* intel/eu: Switch to a logical state stackJason Ekstrand2018-06-043-126/+72
| | | | | | | | Instead of the state stack that's based on copying a dummy instruction around, we start using a logical stack of brw_insn_states. This uses a bit less memory and is way less conceptually bogus. Reviewed-by: Kenneth Graunke <[email protected]>
* intel/eu: Set flag [sub]register number differently for 3srcJason Ekstrand2018-06-041-3/+10
| | | | | | | | | | | Prior to gen8, the flag [sub]register number is in a different spot on 3src instructions than on other instructions. Starting with Broadwell, they made it consistent. This commit fixes bugs that occur when a conditional modifier gets propagated into a 3src instruction such as a MAD. Cc: [email protected] Reviewed-by: Kenneth Graunke <[email protected]>
* intel/eu: Copy fields manually in brw_next_insnJason Ekstrand2018-06-041-1/+94
| | | | | | | | Instead of doing a memcpy, this moves us to start with a blank instruction (memset to zero) and copy the fields over one at a time. Cc: [email protected] Reviewed-by: Kenneth Graunke <[email protected]>
* intel/eu: Add some brw_get_default_ helpersJason Ekstrand2018-06-044-55/+79
| | | | | | | | This is much cleaner than everything that wants a default value poking at the bits of p->current directly. Cc: [email protected] Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Add ARB_fragment_shader_interlock support.Plamena Manolova2018-06-017-6/+34
| | | | | | | | | Adds suppport for ARB_fragment_shader_interlock. We achieve the interlock and fragment ordering by issuing a memory fence via sendc. Signed-off-by: Plamena Manolova <[email protected]> Reviewed-by: Francisco Jerez <[email protected]>
* intel/fs: Add explicit last_rt flag to fb writes orthogonal to eot.Francisco Jerez2018-05-294-5/+5
| | | | | | | | | | | | | | When using multiple RT write messages to the same RT such as for dual-source blending or all RT writes in SIMD32, we have to set the "Last Render Target Select" bit on all write messages that target the last RT but only set EOT on the last RT write in the shader. Special-casing for dual-source blend works today because that is the only case which requires multiple RT write messages per RT. When we start doing SIMD32, this will become much more common so we add a dedicated bit for it. Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* intel/fs: Replace the CINTERP opcode with a simple MOVFrancisco Jerez2018-05-295-12/+3
| | | | | | | | | | | | | The only reason it was it's own opcode was so that we could detect it and adjust the source register based on the payload setup. Now that we're using the ATTR file for FS inputs, there's no point in having a magic opcode for this. v2 (Jason Ekstrand): - Break the bit which removes the CINTERP opcode into its own patch Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* intel/fs: Use the ATTR file for FS inputsFrancisco Jerez2018-05-294-22/+30
| | | | | | | | | | | | This replaces the special magic opcodes which implicitly read inputs with explicit use of the ATTR file. v2 (Jason Ekstrand): - Break into multiple patches - Change the units of the FS ATTR to be in logical scalars Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* intel/fs: Rename a local variable so it doesn't shadow component()Francisco Jerez2018-05-291-4/+4
| | | | | | | | | v2 (Jason Ekstrand): - Break the refactor into its own patch Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* intel/eu: Remove brw_codegen::compressed_stack.Francisco Jerez2018-05-291-1/+0
| | | | | | Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* intel/fs: Use groups for SIMD16 LINTERP on gen11+Jason Ekstrand2018-05-291-4/+5
| | | | | | | | | | | This is better than compression control because it naturally extends to SIMD32. v2: - Push/pop instruction state around adjusted codegen (Ken) Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* intel/fs: Assert that the gen4-6 plane restrictions are followedJason Ekstrand2018-05-291-2/+8
| | | | | | | The fall-back does not work correctly in SIMD16 mode and the register allocator should ensure that we never hit this case anyway. Reviewed-by: Matt Turner <[email protected]>
* intel/eu: Set EXECUTE_1 when setting the rounding mode in cr0Jason Ekstrand2018-05-221-0/+2
| | | | | Fixes: d6cd14f2131a5b "i965/fs: Define new shader opcode to..." Reviewed-by: Jose Maria Casanova Crespo <[email protected]>
* i965/compiler: handle conversion to smaller type in the lowering pass for thatIago Toral Quiroga2018-05-052-12/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This rollbacks the revert of this same patch introduced in commit 7b9c15628aae8729118b648f5f473e6ac926b99b. And also squahes the following patch to prevent a piglit regression caused by this change: intel/compiler: Fix lower_conversions for 8-bit types. Author: Jose Maria Casanova Crespo <[email protected]> For 8-bit types the execution type is word. A byte raw MOV has 16-bit execution type and 8-bit destination and it shouldn't be considered a conversion case. So there is no need to change alignment and enter in lower_conversions for these instructions. Fixes a regresion in the piglit test "glsl-fs-shader-stencil-export" that is introduced with this patch from the Vulkan shaderInt16 series: 'i965/compiler: handle conversion to smaller type in the lowering pass for that'. The problem is caused because there is already a case in the driver that injects Byte instructions like this: mov(8) g127<1>UB g2<32,8,4>UB And the aforementioned pass was not accounting for the special handling of the execution size of Byte instructions. This patch fixes this. v2: (Jason Ekstrand) - Simplify is_byte_raw_mov, include reference to PRM and not consider B <-> UB conversions as raw movs. v3: (Matt Turner) - Indentation style fixes. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106393 Tested-by: Mark Janes <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* intel/compiler: handle 16-bit to 64-bit conversions in BSW platformsIago Toral Quiroga2018-05-051-4/+4
| | | | | | | | | | | | | | | | | These are subject to the general restriction that anything that is converted to 64-bit needs to be aligned to 64-bit. We had this already in place for 32-bit to 64-bit conversions, so this patch generalizes the implementation to take effect on any conversion to 64-bit from a source smaller than 64-bit. Fixes assembly validation errors in the following CTS tests in BSW: dEQP-VK.spirv_assembly.instruction.compute.sconvert.int16_to_int64 dEQP-VK.spirv_assembly.instruction.compute.uconvert.uint16_to_uint64 dEQP-VK.spirv_assembly.instruction.compute.sconvert.int16_to_uint64 Tested-by: Mark Janes <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* Revert "i965/compiler: handle conversion to smaller type in the lowering ↵Mark Janes2018-05-032-7/+12
| | | | | | | | | pass for that" This reverts commit 96b51537908cd2aace85f54b437eeb72e6346b7e. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106393 Reviewed-by: Scott D Phillips <[email protected]>
* intel/compiler: implement 16-bit pack/unpack opcodesIago Toral Quiroga2018-05-031-0/+10
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* compiler/lower_64bit_packing: rename the pass to be more genericIago Toral Quiroga2018-05-031-1/+1
| | | | | | It can do 32-bit packing too now. Reviewed-by: Jason Ekstrand <[email protected]>
* intel/compiler: fix 16-bit comparisonsIago Toral Quiroga2018-05-031-8/+30
| | | | | | | | | | | | | | NIR assumes that booleans are always 32-bit, but Intel hardware produces 16-bit booleans for 16-bit comparisons. This means that we need to convert the 16-bit result to 32-bit. In the future we want to add an optimization pass to clean this up and hopefully remove the conversions. v2 (Jason): use the type of the source for the temporary and use brw_reg_type_from_bit_size for the conversion to 32-bit. Reviewed-by: Jason Ekstrand <[email protected]>
* intel/compiler: lower some 16-bit integer operations to 32-bitIago Toral Quiroga2018-05-031-0/+21
| | | | | | | | | These are not supported in hardware for 16-bit integers. We do the lowering pass after the optimization loop to ensure that we lower ALU operations injected by algebraic optimizations too. Reviewed-by: Jason Ekstrand <[email protected]>
* intel/compiler: support negate and abs of half float immediatesJose Maria Casanova Crespo2018-05-031-2/+4
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* intel/compiler: fix brw_imm_w for negative 16-bit integersJose Maria Casanova Crespo2018-05-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 16-bit immediates need to replicate the 16-bit immediate value in both words of the 32-bit value. This needs to be careful to avoid sign-extension, which the previous implementation was not handling properly. For example, with the previous implementation, storing the value -3 would generate imm.d = 0xfffffffd due to signed integer sign extension, which is not correct. Instead, we should cast to uint16_t, which gives us the correct result: imm.ud = 0xfffdfffd. We only had a couple of cases hitting this path in the driver until now, one with value -1, which would work since all bits are one in this case, and another with value -2 in brw_clip_tri(), which would hit the aforementioned issue (this case only affects gen4 although we are not aware of whether this was causing an actual bug somewhere). v2: Make explicit uint32_t casting for left shift (Jason Ekstrand) Reviewed-by: Jason Ekstrand <[email protected]> Cc: "18.0 18.1" <[email protected]>
* intel/compiler: fix 16-bit int brw_negate_immediate and brw_abs_immediateJose Maria Casanova Crespo2018-05-031-4/+8
| | | | | | | | | | | | | | | | | | | | | From Intel Skylake PRM, vol 07, "Immediate" section (page 768): "For a word, unsigned word, or half-float immediate data, software must replicate the same 16-bit immediate value to both the lower word and the high word of the 32-bit immediate field in a GEN instruction." This fixes the int16/uint16 negate and abs immediates that weren't taking into account the replication in lower and upper words. v2: Integer cases are different to Float cases. (Jason Ekstrand) Included reference to PRM (Jose Maria Casanova) v3: Make explicit uint32_t casting for left shift (Jason Ekstrand) Split half float implementation. (Jason Ekstrand) Fix brw_abs_immediate (Jose Maria Casanova) Cc: "18.0 18.1" <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* intel/compiler: implement nir_instr_type_load_const for 16-bit constantsJose Maria Casanova Crespo2018-05-031-0/+5
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* intel/compiler: implement conversions from 16-bit int/float to boolIago Toral Quiroga2018-05-031-5/+11
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* intel/compiler: implement conversion between float/int 16-bit typesIago Toral Quiroga2018-05-031-0/+4
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-19 06:24:05 +0000