summaryrefslogtreecommitdiffstats
path: root/src/intel/compiler
Commit message (Collapse)AuthorAgeFilesLines
* i965: Fix and enable forgotten validation testMatt Turner2017-10-041-14/+17
| | | | I seem to have forgotten I still had work to do.
* i965: Only insert error message if not already presentMatt Turner2017-10-041-5/+13
| | | | | | | Some restrictions require something like strides to match between src and dest. For multi-source instructions, I'd rather encapsulate the logic for not inserting already present errors in ERROR_IF than open-coding it multiple places.
* i965: Avoid validation error when src1 is not presentMatt Turner2017-10-041-1/+1
| | | | | There can be no violation of the restriction that source offsets are aligned if there is only one source offset.
* i965: Remove validate_reg()Matt Turner2017-10-041-80/+0
| | | | | Replaced by the assembly validator, and in fact gets in the way of writing tests for the assembly validator.
* i965: Add and use STRIDE and WIDTH macrosMatt Turner2017-10-041-18/+15
| | | | | | You'll notice there were bugs in some of the code being replaced. Reviewed-by: Iago Toral Quiroga <[email protected]>
* i965: Add GLK, CFL, CNL to test_eu_validate.cMatt Turner2017-10-041-0/+7
|
* i965: Fix support for disassembling 64-bit integer immediatesMatt Turner2017-10-041-2/+2
| | | | | | | The type suffixes were wrong, and the 16 was missing the 0 prefix. Fixes: 92f787ff86ab ("i965: Add support for disassembling 64-bit integer immediates") Reviewed-by: Iago Toral Quiroga <[email protected]>
* i965/fs: Rewrite fsign64 to skip the float -> double conversionMatt Turner2017-10-041-41/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | ... without the float -> double conversion. Low power parts have additional restrictions when it comes to operating on 64-bit types, and the instruction used to do the conversion violates one of them: specifically, the restriction that "Source and Destination horizontal stride must be aligned to the same qword". Previously we generated a float and then converted, but we can avoid the conversion by using the same extract-the-sign-bit + or-in-1.0 algorithm by directly operating on the high four bytes of each double-precision component in the result. In SIMD8 and SIMD16 this cuts one instruction from the implementation, and more importantly that instruction is the one which violated the regioning restriction. Along the way I removed some comments that I did not think helped, and some code about double comparisons which does not seem to be necessary today. This prevents validation failures caught by the new EU validation code added in later patches. Reviewed-by: Iago Toral Quiroga <[email protected]>
* i965/fs: Unpack count argument to 64-bit shift ops on AtomMatt Turner2017-10-041-6/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | 64-bit operations on Atom parts have additional restrictions over their big-core counterparts (validated by later patches). Specifically, the restriction that "Source and Destination horizontal stride must be aligned to the same qword" is violated by most shift operations since NIR uses a 32-bit value as the shift count argument, and this causes instructions like shl(8) g19<1>Q g5<4,4,1>Q g23<4,4,1>UD where src1 has a 32-bit stride, but the dest and src0 have a 64-bit stride. This caused ~4 pixels in the ARB_shader_ballot piglit test fs-readInvocation-uint.shader_test to be incorrect. Unfortunately no ARB_gpu_shader_int64 test hit this case because they operate on uniforms, and their scalar regions are an exception to the restriction. We work around this by effectively unpacking the shift count, so that we can read it with a 64-bit stride in the shift instruction. Unfortunately the unpack (a MOV with a dst stride of 2) is a partial write, and cannot be copy-propagated or CSE'd. Bugzilla: https://bugs.freedesktop.org/101984
* i965/fs: Don't apply POW/FDIV workaround on Gen10+Matt Turner2017-10-041-0/+1
| | | | | | The documentation says it applies only to Gens 8 and 9. Reviewed-by: Scott D Phillips <[email protected]>
* i965: Fix src0 vs src1 typoMatt Turner2017-10-041-1/+1
| | | | | | | | | | | | | | | | A typo caused us to copy src0's reg file to src1 rather than reading src1's as intended. This caused us to fail to compact instructions like mov(8) g4<1>D 0D { align1 1Q }; because src1 was set to immediate rather than architecture file. Fixing this reenables compaction (after the precompact() pass changes the data types): mov(8) g4<1>UD 0x00000000UD { align1 1Q compacted }; Fixes: 1cb0a7941b27 ("i965: Switch to using the logical register types") Reviewed-by: Kenneth Graunke <[email protected]>
* intel: compiler: vec4: add missing default 0 lodLionel Landwerlin2017-10-031-0/+9
| | | | | | | | | We set a similar default value for LOD in the fs backend for TXS/TXL. Without this we end up generating invalid MOV with a null src. Signed-off-by: Lionel Landwerlin <[email protected]> Cc: "17.2 17.1" <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* meson: convert gtest to an internal dependencyDylan Baker2017-10-031-3/+3
| | | | | | | | | | | | In truth gtest is an external dependency that upstream expects you to "vendor" into your own tree. As such, it makes sense to treat it more like a dependency than an internal library, and collect it's requirements together in a dependency object. v2: - include with -isystem instead of setting compiler args (Eric) Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: skip reading unused slots at the begining of the URB for the FSIago Toral Quiroga2017-10-022-4/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We can start reading the URB at the first offset that contains varyings that are actually read in the URB. We still need to make sure that we read at least one varying to honor hardware requirements. This helps alleviate a problem introduced with 99df02ca26f61 for separate shader objects: without separate shader objects we assign locations sequentially, however, since that commit we have changed the method for SSO so that the VUE slot assigned depends on the number of builtin slots plus the location assigned to the varying. This fixed layout is intended to help SSO programs by avoiding on-the-fly recompiles when swapping out shaders, however, it also means that if a varying uses a large location number close to the maximum allowed by the SF/FS units (31), then the offset introduced by the number of builtin slots can push the location outside the range and trigger an assertion. This problem is affecting at least the following CTS tests for enhanced layouts: KHR-GL45.enhanced_layouts.varying_array_components KHR-GL45.enhanced_layouts.varying_array_locations KHR-GL45.enhanced_layouts.varying_components KHR-GL45.enhanced_layouts.varying_locations which use SSO and the the location layout qualifier to select such location numbers explicitly. This change helps these tests because for SSO we always have to include things such as VARYING_SLOT_CLIP_DIST{0,1} even if the fragment shader is very unlikely to read them, so by doing this we free builtin slots from the fixed VUE layout and we avoid the tests to crash in this scenario. Of course, this is not a proper fix, we'd still run into problems if someone tries to use an explicit max location and read gl_ViewportIndex, gl_LayerID or gl_CullDistancein in the FS, but that would be a much less common bug and we can probably wait to see if anyone actually runs into that situation in a real world scenario before making the decision that more aggresive changes are required to support this without reverting 99df02ca26f61. v2: - Add a debug message when we skip clip distances (Ilia) - we also need to account for this when we compute the urb setup for the fragment shader stage, so add a compiler util to compute the first slot that we need to read from the URB instead of replicating the logic in both places. v3: - Make the util more generic so it can account for all unused slots at the beginning of the URB, that will make it more useful (Ken). - Drop the debug message, it was not what Ilia was asking for. Suggested-by: Kenneth Graunke <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Normalize types for FBL, FBH, etcMatt Turner2017-09-302-15/+11
| | | | | | | | | | | | Allows the instructions to be compacted. The documentation claims that some of these only accept UD types, even though the type doesn't change the operation performed. Just normalize the types to ensure we get instruction compaction. The only functional changes are for FBL and CBIT (always use UD types) and FBH (always use the same types). Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: force pull model for 64-bit GS inputsIago Toral Quiroga2017-09-292-7/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Triggering the push model when 64-bit inputs are involved is not easy due to the constrains on the maximum number of registers that we allow for this mode, however, for GS with 'points' primitive type and just a couple of double varyings we can trigger this and it just doesn't work because the implementation is not 64-bit aware at all. For now, let's make sure that we don't attempt this model whith 64-bit inputs and we always fall back to pull model for them. Also, don't enable the VUE handles in the thread payload on the fly when we find an input for which we need the pull model, this is not safe: if we need to resort to the pull model we need to account for that when we setup the thread payload so we compute the first non-payload register properly. If we didn't do that correctly and we enable it on-the-fly here then we will end up VUE handles on the first non-payload register which will probably lead to GPU hangs. Instead, always enable the VUE handles for the pull model so we can safely use them when needed. The GS is going to resort to pull model almost in every situation anyway, so this shouldn't make a significant difference and it makes things easier and safer. v2: Always enable the VUE handles for pull model, this is easier and safer and the GS is going to fallback to pull model almost always anyway (Ken) v3: Only clamp the URB read length if we are over the maximum reserved for push inputs as we were doing in the original code (Ken). v4: No need to clamp the urb read length if invocations > 1 Reviewed-by: Kenneth Graunke <[email protected]>
* meson: Add build Intel "anv" vulkan driverDylan Baker2017-09-271-0/+155
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows building and installing the Intel "anv" Vulkan driver using meson and ninja, the driver has been tested against the CTS and has seems to pass the same series of tests (they both segfault when the CTS tries to run wayland wsi tests). There are still a mess of TODO, XXX, and FIXME comments in here. Those are mostly for meson bugs I'm trying to fix, or for additional things to implement for other drivers/features. I have configured all intermediate libraries and optional tools to not build by default, meaning they will only be built if they're pulled in as a dependency of a target that will actually be installed) this allows us to avoid massive if chains, while ensuring that only the bits that need to be built are. v2: - enable anv, x11, and wayland by default - add configure option to disable valgrind v3: - fix typo in meson_options (Nicholas) v4: - Remove dead code (Eric) - Remove change to generator that was from v0 (Eric) - replace if chain with loop (Eric) - Fix typos (Eric) - define HAVE_DLOPEN for both libdl and builtin dl cases (Eric) v5: - rebase on util string buffer implementation Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Eric Anholt <[email protected]> (v4)
* intel: use a flag instead of setting PYTHONPATHDylan Baker2017-09-271-8/+25
| | | | | | | | | | | | Meson doesn't allow setting environment variables for custom targets, so we either need to not pass this as an environment variable or use a shell script to wrap the invocation. The chosen solution has the advantage of working for both autotools and meson. v2: - put rules back in top scope (Ken) Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Dylan Baker <[email protected]>
* i965: Support copy propagating of untyped atomic surface indexes.Kenneth Graunke2017-09-261-0/+7
| | | | | | | | In the vec4 backend, SHADER_OPCODE_UNTYPED_ATOMIC's src[1] is the surface index. We want to copy propagate so we can use an immediate message descriptor, rather than an indirect send. Reviewed-by: Ian Romanick <[email protected]>
* i965/vec4: Fix swizzles on atomic sources.Kenneth Graunke2017-09-261-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | Atomic operation sources are scalar values, but we were failing to select the .x component of the second operand. For example, atomicCounterCompSwapARB(counter, 5u, 10u) would generate mov(8) vgrf4.x:D, 5D mov(8) vgrf5.x:D, 10D mov(8) vgrf9.x:UD, vgrf4.xyzw:D mov(8) vgrf9.y:UD, vgrf5.xyzw:D which wrongly selects the .y component of vgrf5, so the actual 10u value would get dead code eliminated. The swizzle works for the other source, but both of them ought to be .xxxx. Fixes the compare and swap CTS tests in: KHR-GL45.shader_atomic_counter_ops_tests.ShaderAtomicCounterOpsExchangeTestCase Cc: "17.2 17.1 17.0 13.0" <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965/vec4: Actually handle atomic op intrinsics.Kenneth Graunke2017-09-261-2/+10
| | | | | | | | | | | | Embarassingly, someone enabled the ARB_shader_atomic_counter_ops extension for Gen7+ but never added the intrinsics to the switch statement in the vec4 backend, so they just hit an unreachable() call and died. Fixes: 40dd45d0c6aa4a9d (i965: Enable ARB_shader_atomic_counter_ops) Cc: "17.2 17.1 17.0 13.0" <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965/nir: export nir_optimizeTimothy Arceri2017-09-262-7/+11
| | | | | Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Eduardo Lima Mitev <[email protected]>
* i965: Handle unwritten PSIZ/VIEWPORT/LAYER outputs in vec4 shaders.Kenneth Graunke2017-09-211-3/+3
| | | | | | | | This can occur if the shader is capturing some of the values from the VUE header for transform feedback, but the shader hasn't written all of them. Reviewed-by: Juan A. Suarez Romero <[email protected]>
* intel/eu/validate: Look up types on demand in execution_type()Jason Ekstrand2017-09-121-4/+2
| | | | | | | | | | We are looking up the execution type prior to checking how many sources we have. This leads to looking for a type for src1 on MOV instructions which is bogus. On BDW+, the src1 register type overlaps with the 64-bit immediate and causes us problems. Reviewed-by: Matt Turner <[email protected]> Cc: [email protected]
* i965: Drop unnecessary conditionalMatt Turner2017-08-291-4/+4
| | | | | | | | Clang doesn't realize that 0 and 1 are the only possibilities, a thinks lots of variables might be uninitialized. Reviewed-by: Emil Velikov <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* intel/compiler: Cast reg types explicitlyTopi Pohjolainen2017-08-281-2/+2
| | | | | | | | | | Makes coverity happier. CID: 1416799 Fixes: c1ac1a3d25 (i965: Add a brw_hw_type_to_reg_type() function) Reviewed-by: Matt Turner <[email protected]> Signed-off-by: Topi Pohjolainen <[email protected]>
* anv,i965: Move CS shared lowering into anvJason Ekstrand2017-08-241-2/+0
| | | | | | | | | | | Right now, OpenGL uses the GLSL lowering for shared variables and anv uses NIR to lower them. For a long time, we've done this weird thing where we do the NIR lowering unconditionally and then add the SLM sizes from the two together. This works because one of them will always be 0 but it's a bit sketchy. Let's just move the NIR-based lowering into anv_pipeline and get rid of the sketch. Reviewed-by: Jordan Justen <[email protected]>
* i965: Stop using wm_prog_data->binding_table.render_target_start.Kenneth Graunke2017-08-231-2/+7
| | | | | | | | | | | | | Render target surfaces always start at binding table index 0. This is required for us to use headerless FB writes, which we really want to do. So, we'll never change that. Given that, it's not necessary to look up a wm_prog_data field which we already know contains 0. We can drop the dependency in brw_renderbuffer_surfaces (Gen4-5)...which was already confusingly missing from gen6_renderbuffer_surfaces. Reviewed-by: Topi Pohjolainen <[email protected]>
* i965: Add a brw_wm_prog_data::has_render_target_reads field.Kenneth Graunke2017-08-232-0/+3
| | | | | | | State upload code should use prog_data rather than poking at shader_info directly. Reviewed-by: Topi Pohjolainen <[email protected]>
* i965: Mark functions staticMatt Turner2017-08-213-20/+21
| | | | | | Cuts 300 bytes of .text Reviewed-by: Jordan Justen <[email protected]>
* i965/vec4: Use 'class' src_reg, rather than 'struct' src_regMatt Turner2017-08-211-1/+1
| | | | Reviewed-by: Jordan Justen <[email protected]>
* i965/vec4: Return float from spill_cost_for_type()Matt Turner2017-08-211-1/+1
| | | | | Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]>
* i965: Optimize reading the destination typeMatt Turner2017-08-211-1/+3
| | | | | | | | | | | | | brw_hw_type_to_reg_type() needs to know only whether the file is BRW_IMMEDIATE_VALUE or not, which is not a valid file for the destination. gcc and clang will evaluate __builtin_strcmp() at compile time, so we can use it to pass a constant file for the destination. text data bss dec hex filename 7816214 346248 420496 8582958 82f72e i965_dri.so before 7816070 346248 420496 8582814 82f69e i965_dri.so after Reviewed-by: Scott D Phillips <[email protected]>
* i965: Mark brw_hw_type_to_reg_type() as a pure functionMatt Turner2017-08-211-1/+7
| | | | | | | | text data bss dec hex filename 7816886 346248 420496 8583630 82f9ce i965_dri.so before 7816214 346248 420496 8582958 82f72e i965_dri.so after Reviewed-by: Scott D Phillips <[email protected]>
* i965: Hide the register type hardware encodingsMatt Turner2017-08-212-31/+31
| | | | | | So we stop mixing them with the logical enum. Reviewed-by: Scott D Phillips <[email protected]>
* i965: Stop using hardware register types directlyMatt Turner2017-08-214-158/+113
| | | | Reviewed-by: Scott D Phillips <[email protected]>
* i965: Add brw_hw_reg_type_to_letters() and use it in brw_disasm.cMatt Turner2017-08-213-39/+45
| | | | Reviewed-by: Scott D Phillips <[email protected]>
* i965: Move brw_reg_type_letters() as wellMatt Turner2017-08-216-33/+37
| | | | | | | And add "to_" to the name for consistency with the other functions in this file. Reviewed-by: Scott D Phillips <[email protected]>
* i965: Switch to using the logical register typesMatt Turner2017-08-212-21/+19
| | | | Reviewed-by: Scott D Phillips <[email protected]>
* i965: Add functions to abstract access to register typesMatt Turner2017-08-212-51/+79
| | | | | | | | | | | | | | | | | | Previously the brw_inst{,_set}_{dst,src0,src1}_reg_type() functions provided access to the hardware encodings for the register types. We often mixed these with the logical BRW_REGISTER_TYPE_* enums (which themselves used to be the hardware format!) with bad results. With that functionality now available with the hw_ versions (see previous commit), we now add functions that take the logical BRW_REGISTER_TYPE_* enums and convert into the hardware format and vice versa. To do the conversion we also have to provide the file. Note the asymmetry between the two functions: the new getter reads the file from the instruction word, and to ensure that is always set the setter writes both the file and the type. Reviewed-by: Scott D Phillips <[email protected]>
* i965: Rename brw_inst's functions that access the register typeMatt Turner2017-08-217-99/+99
| | | | | | Put hw_ in the name so that it's clear these are the hardware encodings. Reviewed-by: Scott D Phillips <[email protected]>
* i965: Index brw_hw_reg_type_to_size()'s table by logical typeMatt Turner2017-08-211-39/+19
| | | | | | I'll be transitioning everything to use the logical types. Reviewed-by: Scott D Phillips <[email protected]>
* i965: Add a brw_hw_type_to_reg_type() functionMatt Turner2017-08-212-0/+29
| | | | | | Will be used in later commits. Reviewed-by: Scott D Phillips <[email protected]>
* i965: Use a common table to translate logical to hardware typesMatt Turner2017-08-211-36/+29
| | | | Reviewed-by: Scott D Phillips <[email protected]>
* i965: Extract functions dealing with register types to separate fileMatt Turner2017-08-214-140/+207
| | | | | | | | | | I'm going to encapsulate all of the logic dealing with register types in this file. Rename the parameters for the hardware encodings from type -> hw_type at the same time. Reviewed-by: Scott D Phillips <[email protected]>
* i965: Reverse file/type arguments to register type functionsMatt Turner2017-08-214-13/+15
| | | | | | | I think of the initial arguments as "state" and the last as the actual subject. Reviewed-by: Scott D Phillips <[email protected]>
* i965: Add support for disassembling 64-bit integer immediatesMatt Turner2017-08-212-0/+13
| | | | | | | After the last patch converted things into enums, I helpfully got a compiler warning about these missing from the switch statement. Reviewed-by: Scott D Phillips <[email protected]>
* i965: Use separate enums for register vs immediate typesMatt Turner2017-08-216-129/+144
| | | | | | | The hardware encodings often mean different things depending on whether the source is an immediate. Reviewed-by: Scott D Phillips <[email protected]>
* i965: Reorder brw_reg_type enum valuesMatt Turner2017-08-215-26/+21
| | | | | | | | | | | These vaguely corresponded to the hardware encodings, but that is purely historical at this point. Reorder them so we stop making things "almost work" when mixing enums. The ordering has been closen so that no enum value is the same as a compatible hardware encoding. Reviewed-by: Scott D Phillips <[email protected]>
* i965: Validate destination restrictions with vector immediatesMatt Turner2017-08-213-12/+141
| | | | Reviewed-by: Scott D Phillips <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-22 02:59:08 +0000