aboutsummaryrefslogtreecommitdiffstats
path: root/src/intel/compiler/brw_eu_validate.c
Commit message (Collapse)AuthorAgeFilesLines
* remove final imports.h and imports.c bitsDylan Baker2020-04-211-0/+1
| | | | | | | | | | | This moves the fi_types to a new mesa_private.h and removes the imports.c file. The vast majority of this patch is just removing pound includes of imports.h and fixing up the recursive includes. Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Kristian H. Kristensen <[email protected]> Reviewed-by: Matt Turner <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3024>
* intel/eu/validate: Don't validate regions of sendsJason Ekstrand2020-01-311-3/+3
| | | | | | | | | | Otherwise, the validator tries to read the type of src1 of a SEND/SENDS which doesn't actually have a type field. This prevents validation issues in the next commit. Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3642>
* intel/compiler: Validate fuzzed instructionsMatt Turner2020-01-221-1/+1
| | | | | | | ... before giving them to the instruction compactor. Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2635>
* intel/compiler: Validate some instruction word encodingsMatt Turner2020-01-221-10/+84
| | | | | | | | | | | Specifically, execution size, register file, and register type. I did not add validation for vertical stride and width because I don't believe it's possible to have an otherwise valid instruction with an invalid vertical stride or width, due to all of the other regioning restrictions. Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2635>
* intel/compiler: Factor out brw_validate_instruction()Matt Turner2020-01-221-26/+35
| | | | | | | | | In order to fuzz test instructions, we first need to do some sanity checking first. Factoring out this function allows us an easy way to validate a single instruction. Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2635>
* intel/compiler: Add NF some more placesMatt Turner2020-01-221-0/+4
| | | | | | | Necessary to handle these cases when we test fuzzed instructions. Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2635>
* intel/compiler: Don't left-shift by >= the number of bits of the typeMichel Dänzer2019-10-241-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | To avoid it, use the modulo of the number of bits in the value being shifted, which is presumably what ended up happening on x86. Flagged by UBSan: ../src/intel/compiler/brw_eu_validate.c:974:33: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int' #0 0x561abb612ab3 in general_restrictions_on_region_parameters ../src/intel/compiler/brw_eu_validate.c:974 #1 0x561abb617574 in brw_validate_instructions ../src/intel/compiler/brw_eu_validate.c:1851 #2 0x561abb53bd31 in validate ../src/intel/compiler/test_eu_validate.cpp:106 #3 0x561abb555369 in validation_test_source_cannot_span_more_than_2_registers_Test::TestBody() ../src/intel/compiler/test_eu_validate.cpp:486 #4 0x561abb742651 in void testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) ../src/gtest/src/gtest.cc:2402 #5 0x561abb72e64d in void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) ../src/gtest/src/gtest.cc:2438 #6 0x561abb6d5451 in testing::Test::Run() ../src/gtest/src/gtest.cc:2474 #7 0x561abb6d7b2a in testing::TestInfo::Run() ../src/gtest/src/gtest.cc:2656 #8 0x561abb6da2b8 in testing::TestCase::Run() ../src/gtest/src/gtest.cc:2774 #9 0x561abb6f5c92 in testing::internal::UnitTestImpl::RunAllTests() ../src/gtest/src/gtest.cc:4649 #10 0x561abb74626a in bool testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) ../src/gtest/src/gtest.cc:2402 #11 0x561abb732025 in bool testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) ../src/gtest/src/gtest.cc:2438 #12 0x561abb6ed2b4 in testing::UnitTest::Run() ../src/gtest/src/gtest.cc:4257 #13 0x561abb768b3b in RUN_ALL_TESTS() ../src/gtest/include/gtest/gtest.h:2233 #14 0x561abb7689fb in main ../src/gtest/src/gtest_main.cc:37 #15 0x7f525e5a9bba in __libc_start_main ../csu/libc-start.c:308 #16 0x561abb538ed9 in _start (/home/daenzer/src/mesa-git/mesa/build-amd64-sanitize/src/intel/compiler/eu_validate+0x1b8ed9) Reviewed-by: Adam Jackson <[email protected]>
* intel/eu/validate/gen12: Don't blow up on indirect src0.Jason Ekstrand2019-10-111-1/+2
| | | | | | | They look like a NULL source if you don't look at the address mode. Reviewed-by: Francisco Jerez <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel/eu/validate/gen12: Validation fixes for SEND instruction.Francisco Jerez2019-10-111-22/+28
| | | | | | | | The following fix-up by Jordan Justen is squashed in: intel/eu/validate: gen12 send instruction doesn't have a dst type field Reviewed-by: Kenneth Graunke <[email protected]>
* intel/eu/validate/gen12: Fix validation of SYNC instruction.Francisco Jerez2019-10-111-1/+1
| | | | | | | src0 will typically be null for this instruction. Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel/eu/validate/gen12: Implement integer multiply restrictions in EU ↵Francisco Jerez2019-10-111-0/+33
| | | | | | | | validator. Due to hardware bug filed as HSDES#1604601757. Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* intel/eu: Encode and decode native instruction opcodes from/to IR opcodes.Francisco Jerez2019-10-111-1/+3
| | | | | | | | | | | | Change brw_inst_set_opcode() and brw_inst_opcode() to call brw_opcode_encode/decode() transparently in order to translate between hardware and IR opcodes, and update the EU compaction code in order to do the same as needed, so we can eventually drop the one-to-one correspondence between hardware and IR opcodes. Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel/eu: Split brw_inst ex_desc accessors for SEND(C) vs. SENDS(C).Francisco Jerez2019-10-111-1/+1
| | | | | | | | | | | | | | The brw_inst opcode accessors are going away in one of the following commits. We could potentially replace them with the new helpers that do opcode remapping, but that would lead to a circular dependency between brw_inst.h and brw_eu.h. This way we also avoid ordering issues that can cause the semantics of the ex_desc accessors to change depending on whether the ex_desc field is set after or before the opcode instruction field. Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel/compiler: don't use byte operands for src1 on ICLLionel Landwerlin2019-06-291-9/+33
| | | | | | | | | | | | | | | | | | | | | | The simulator complains about using byte operands, we also have documentation telling us. Note that add operations on bytes seems to work fine on HW (like ADD). Using dwords operands with CMP & SEL fixes the following tests : dEQP-VK.spirv_assembly.type.vec*.i8.* v2: Drop the GLK changes (Matt) Add validator tests (Matt) v3: Drop GLK ref (Matt) Don't mix float/integer in MAD (Matt) Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Rafael Antognolli <[email protected]> (v1) Reviewed-by: Matt Turner <[email protected]> BSpec: 3017 Cc: <[email protected]>
* intel/compiler: validate region restrictions for mixed float modeIago Toral Quiroga2019-04-181-0/+250
| | | | | | | | | | | | | | | | | | | | | | | | | v2: - Adapted unit tests to make them consistent with the changes done to the validation of half-float conversions. v3 (Curro): - Check all the accummulators - Constify declarations - Do not check src1 type in single-source instructions. - Check for all instructions that read accumulator (either implicitly or explicitly) - Check restrictions in src1 too. - Merge conditional block - Add invalid test case. v4 (Curro): - Assert on 3-src instructions, as they are not validated. - Get rid of types_are_mixed_float(), as we know instruction is mixed float at that point. - Remove conditions from not verified case. - Fix brackets on conditional. Reviewed-by: Francisco Jerez <[email protected]>
* intel/compiler: validate conversions between 64-bit and 8-bit typesIago Toral Quiroga2019-04-181-0/+50
| | | | | | | | | | | | | v2: - Add some tests with UB type too (Jason) v3: - consider implicit conversions from 2src instructions too (Curro). v4: - Do not check src1 type in single-source instructions (Curro). Reviewed-by: Jason Ekstrand <[email protected]> (v2)
* intel/compiler: validate region restrictions for half-float conversionsIago Toral Quiroga2019-04-181-1/+154
| | | | | | | | | | | | | | | | | | v2: - Consider implicit conversions in 2-src instructions too (Curro) - For restrictions that involve destination stride requirements only validate them for Align1, since Align16 always requires packed data. - Skip general rule for the dst/execution type size ratio for mixed float instructions on CHV and SKL+, these have their own set of rules that we'll be validated separately. v3 (Curro): - Do not check src1 type in single-source instructions. - Check restriction on src1. - Remove invalid test. Reviewed-by: Francisco Jerez <[email protected]>
* intel/compiler: also set F execution type for mixed float mode in BDWIago Toral Quiroga2019-04-181-16/+20
| | | | | | | | | | | | | | The section 'Execution Data Types' of 3D Media GPGPU volume, which describes execution types, is exactly the same in BDW and SKL+. Also, this section states that there is a single execution type, so it makes sense that this is the wider of the two floating point types involved in mixed float mode, which is what we do for SKL+ and CHV. v2: - Make sure we also account for the destination type in mixed mode (Curro). Acked-by: Francisco Jerez <[email protected]>
* intel/eu: Add support for the SENDS[C] messagesJason Ekstrand2019-01-291-2/+63
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/eu/validate: SEND restrictions also apply to SENDCJason Ekstrand2019-01-291-1/+2
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/compiler: Add a file-level description of brw_eu_validate.cMatt Turner2019-01-261-1/+13
| | | | | | Acked-by: Jose Maria Casanova Crespo <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Francisco Jerez <[email protected]>
* intel/compiler: relax brw_eu_validate for byte raw movsJose Maria Casanova Crespo2018-07-101-3/+5
| | | | | | | | | | | When the destination is a BYTE type allow raw movs even if the stride is not exact multiple of destination type and exec type, execution type is Word and its size is 2. This restriction was only allowing stride==2 destinations for 8-bit types. Reviewed-by: Jason Ekstrand <[email protected]>
* intel/compiler: grf127 can not be dest when src and dest overlap in sendJose Maria Casanova Crespo2018-07-101-0/+11
| | | | | | | | | | | | | | Implement at brw_eu_validate the restriction from Intel Broadwell PRM, vol 07, section "Instruction Set Reference", subsection "EUISA Instructions", Send Message (page 990): "r127 must not be used for return address when there is a src and dest overlap in send instruction." v2: Style fixes (Matt Turner) Reviewed-by: Matt Turner <[email protected]> Cc: 18.1 <[email protected]>
* intel/compiler: Add Gen11+ native float typeMatt Turner2018-02-281-0/+1
| | | | | | | | | | | | This new type exposes the additional precision offered by the accumulator register and will be used in the next patch to implement the functionality of the PLN instruction using a pair of MAD instructions. One weird thing to note: align1 ternary instructions may only have an accumulator in the dst or src1 normally, but when src0's type is :NF the accumulator is read. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Rewrite disassembly annotation codeMatt Turner2017-11-171-3/+3
| | | | | | | | | | | | | | | The old code used an array to store each "instruction group" (the new, better name than the old overloaded "annotation"), and required a memmove() to shift elements over in the array when we needed to split a group so that we could add an error message. This was confusing and difficult to get right, not the least of which was because the array has a tail sentinel not included in .ann_count. Instead use a linked list, a data structure made for efficient insertion. Acked-by: Samuel Iglesias Gonsálvez <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel/compiler: brw_validate_instructions to take const void* instead of void*Kevin Rogovin2017-10-261-1/+1
| | | | | | | The disassembler does not (and should not) be modifying the data. Signed-off-by: Kevin Rogovin <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Fix memmem compiler warnings.Eric Anholt2017-10-241-1/+2
| | | | | | | | | | | | | | | | | | | gcc is throwing this warning in my meson build: ../src/intel/compiler/brw_eu_validate.c:50:11: warning argument 1 null where non-null expected [-Wnonnull] return memmem(haystack.str, haystack.len, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ needle.str, needle.len) != NULL; ~~~~~~~~~~~~~~~~~~~~~~~ The first check for CONTAINS has a NULL error_msg.str and 0 len. The glibc implementation will exit without looking at any haystack bytes if haystack.len < needle.len, so this was safe, but silence the warning anyway by guarding against implementation variablility. Fixes: 122ef3799d56 ("i965: Only insert error message if not already present") Reviewed-by: Matt Turner <[email protected]>
* i965: Don't try to decode types for non-existent src1.Kenneth Graunke2017-10-101-1/+2
| | | | | | | | | | | | | | KHR-GL45.shader_ballot_tests.ShaderBallotBitmasks has a MOV that hits this validation path. MOVs don't have a src1 file, but calling brw_inst_src1_type() was tripping on src1.file being BRW_IMMEDIATE_VALUE and the hw_type being something invalid for immediates. To work around this, just pretend src1 is src0 if there isn't a src1. Fixes: 2572c2771d0cab0b9bc489d354ede44dfc88547b (i965: Validate "Special Requirements for Handling Double Precision Data Types") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102680 Reviewed-by: Alejandro Piñeiro <[email protected]>
* i965: Validate "Special Requirements for Handling Double Precision Data Types"Matt Turner2017-10-041-0/+169
| | | | | | | | | | | | | I did not implement: CNL's restriction on 64-bit int + align16, because I don't think we'll ever use this combination regardless of hardware generation. The restriction on immediate DF -> F conversions, because there's no reason to ever generate that, and I don't even know how DF -> F conversions are supposed to work in Align16 since (1) the dst stride must be 1, but (2) the dst stride would have to be 2 for src and dst strides to be aligned.
* 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: 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]>
* 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]>
* i965: Stop using hardware register types directlyMatt Turner2017-08-211-105/+91
| | | | Reviewed-by: Scott D Phillips <[email protected]>
* i965: Rename brw_inst's functions that access the register typeMatt Turner2017-08-211-14/+14
| | | | | | Put hw_ in the name so that it's clear these are the hardware encodings. Reviewed-by: Scott D Phillips <[email protected]>
* i965: Reverse file/type arguments to register type functionsMatt Turner2017-08-211-1/+1
| | | | | | | I think of the initial arguments as "state" and the last as the actual subject. Reviewed-by: Scott D Phillips <[email protected]>
* i965: Use separate enums for register vs immediate typesMatt Turner2017-08-211-30/+30
| | | | | | | The hardware encodings often mean different things depending on whether the source is an immediate. Reviewed-by: Scott D Phillips <[email protected]>
* i965: Validate destination restrictions with vector immediatesMatt Turner2017-08-211-0/+61
| | | | Reviewed-by: Scott D Phillips <[email protected]>
* i965: Don't let raw-move check be tricked by immediate vector typesMatt Turner2017-08-211-3/+10
| | | | | | | UB and B type encodings are the same as UV and VF. Noticed when writing the following patch. Reviewed-by: Scott D Phillips <[email protected]>
* i965: Allow brw_eu_validate to handle compact instructionsMatt Turner2017-05-151-2/+15
| | | | | | | | This will allow the validator to run on shader programs we find in the GPU hang error state. Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* i965: Pass pointer and end of assembly to brw_validate_instructionsMatt Turner2017-05-151-5/+4
| | | | | | | This will allow us to more easily run brw_validate_instructions() on shader programs we find in GPU hang error states. Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel: compiler: prevent integer overflowLionel Landwerlin2017-05-091-2/+2
| | | | | | | CID: 1399477, 1399478 (Integer handling issues) Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* intel: compiler: remove duplicated codeLionel Landwerlin2017-05-091-12/+0
| | | | | | | CID: 1399470: (Control flow issues) Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Handle IVB DF differences in the validator.Matt Turner2017-04-141-0/+24
| | | | | | | | | | | On IVB/BYT, region parameters and execution size for DF are in terms of 32-bit elements, so they are doubled. For evaluating the validity of an instruction, we halve them. v2 (Sam): - Add comments. Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
* i965: Move the back-end compiler to src/intel/compilerJason Ekstrand2017-03-131-0/+1051
Mostly a dummy git mv with a couple of noticable parts: - With the earlier header cleanups, nothing in src/intel depends files from src/mesa/drivers/dri/i965/ - Both Autoconf and Android builds are addressed. Thanks to Mauro and Tapani for the fixups in the latter - brw_util.[ch] is not really compiler specific, so it's moved to i965. v2: - move brw_eu_defines.h instead of brw_defines.h - remove no-longer applicable includes - add missing vulkan/ prefix in the Android build (thanks Tapani) v3: - don't list brw_defines.h in src/intel/Makefile.sources (Jason) - rebase on top of the oa patches [Emil Velikov: commit message, various small fixes througout] Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>