summaryrefslogtreecommitdiffstats
path: root/src/intel
Commit message (Collapse)AuthorAgeFilesLines
* anv/cmd_buffer: Take bo_offset into account in fast clear state addressesJason Ekstrand2017-11-171-1/+1
| | | | | | | | | Otherwise, if the image is not bound to the start of the buffer, we're going to be reading and writing its fast clear state in the wrong spot. Reviewed-by: Lionel Landwerlin <[email protected]> Cc: [email protected] (cherry picked from commit a07f7b26198ce0f5c8799481a673754968ac5daf)
* anv/cmd_buffer: Advance the address when initializing clear colorsJason Ekstrand2017-11-171-3/+6
| | | | | | | | | Found by inspection Reviewed-by: Lionel Landwerlin <[email protected]> Reviewed-by: Nanley Chery <[email protected]> Cc: [email protected] (cherry picked from commit a6cc361e5fd2450249847d5ee8093d26ed7ff545)
* Revert "intel/fs: Use a pure vertical stride for large register strides"Matt Turner2017-11-171-13/+3
| | | | | | | | | This reverts commit e8c9e65185de3e821e1e482e77906d1d51efa3ec. With the actual bug fixed (by commit 6ac2d1690192), this is not necessary. I'm doubtful of its correctness in any case. (cherry picked from commit a31d0382084c8aa860ffcef9b12592c5c44e192f)
* i965/fs: Split all 32->64-bit MOVs on CHV, BXT, GLKMatt Turner2017-11-171-4/+4
| | | | | | | | | Fixes the following tests on CHV, BXT, and GLK: KHR-GL46.shader_ballot_tests.ShaderBallotFunctionBallot dEQP-VK.spirv_assembly.instruction.compute.uconvert.uint32_to_int64 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103115 (cherry picked from commit cfcfa0b9cd1b1d563a988b1250950057c4612ac9)
* i965/fs: Fix extract_i8/u8 to a 64-bit destinationMatt Turner2017-11-171-2/+23
| | | | | | | | | | | | | | | | | The MOV instruction can extract bytes to words/double words, and words/double words to quadwords, but not byte to quadwords. For unsigned byte to quadword, we can read them as words and AND off the high byte and extract to quadword in one instruction. For signed bytes, we need to first sign extend to word and the sign extend that word to a quadword. Fixes the following test on CHV, BXT, and GLK: KHR-GL46.shader_ballot_tests.ShaderBallotBitmasks Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103628 Reviewed-by: Jason Ekstrand <[email protected]> (cherry picked from commit 6ac2d16901927013393f873a34c717ece5014c1a)
* intel/tools: Fix detection of enabled shader stages.Kenneth Graunke2017-11-171-1/+1
| | | | | | | | | | | We renamed "Function Enable" to "Enable", which broke our detection of whether shaders are enabled or not. So, we'd see a bunch of HS/DS packets with program offsets of 0, and think that was a valid TCS/TES. Fixes: c032cae9ff77e (genxml: Rename "Function Enable" to "Enable".) Reviewed-by: Lionel Landwerlin <[email protected]> (cherry picked from commit 9a0465b3a3a1a6e8beda7a59506c2e1a1aae776f)
* intel/blorp: Make the MOCS setting part of blorp_addressJason Ekstrand2017-11-174-18/+18
| | | | | | | | | This makes our MOCS settings significantly more flexible. Cc: "17.3" <[email protected]> Tested-by: Lyude Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> (cherry picked from commit bc933d0e8462871e19328f66182c35543e334013)
* anv/blorp: Add a device parameter to blorp_surf_for_anv_imageJason Ekstrand2017-11-171-22/+34
| | | | | | | Cc: "17.3" <[email protected]> Tested-by: Lyude Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> (cherry picked from commit deec84fd771876b5c0755293376df11bc95b473b)
* intel/blorp: Use mocs.tex for depth stencilJason Ekstrand2017-11-171-5/+1
| | | | | | | Cc: "17.3" <[email protected]> Tested-by: Lyude Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> (cherry picked from commit 4639cc716e89c69da41c7b54fa938457000fbd4c)
* autotools: Set C++ visibility flags on IntelDylan Baker2017-11-131-0/+3
| | | | | | | | | | These flags are set for C sources, but not C++. This causes symbol visibility leaks from the C++ parts of the Intel compiler. Fixes: 700bebb958e93f4d ("i965: Move the back-end compiler to src/intel/compiler") Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Matt Turner <[email protected]> (cherry picked from commit 854455498c0370e959c0bb25680641e05faea3e2)
* automake: intel: correctly append to the LIBADD variableEmil Velikov2017-11-131-1/+1
| | | | | | | | | | | | | | | Commit 05fc62d89f5 sets the variable, yet it forgot the update the existing reference to append (instead of assign). Thus as-is the expat library was discarded from the link chain when building with Android. Fixes: 05fc62d89f5 ("automake: intel: move expat handling where it's used") Cc: Hongxu Jia <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Eric Engestrom <[email protected]> (cherry picked from commit ba414dba4f1bf354cc9494fd76e3e28b489f13a1)
* intel/nir: Use the correct indirect lowering masks in link_shadersJason Ekstrand2017-11-101-6/+4
| | | | | | | | | | Previously, if we were linking a vec4 VS with a SIMD8/16 FS, we wouldn't lower indirects on the fragment shader which is wrong. Instead of using a single indirect mask, take advantage of our new little helper. Reviewed-by: Timothy Arceri <tarceri at itsqueeze.com> Cc: [email protected] (cherry picked from commit 951a5dc4cc29da996b54ae63eeba1915a3a65b4a)
* intel/nir: Break the linking code into a helper in brw_nir.cJason Ekstrand2017-11-102-0/+36
| | | | | | Reviewed-by: Timothy Arceri <tarceri at itsqueeze.com> Cc: [email protected] (cherry picked from commit 3e63cf893f096a7263eb1856d58417dd2d170d4b)
* intel/nir: Add a helper for getting the NoIndirect maskJason Ekstrand2017-11-101-14/+19
| | | | | | Reviewed-by: Timothy Arceri <tarceri at itsqueeze.com> Cc: [email protected] (cherry picked from commit 7364f080f9a272323ed3491f278a1eed3eb9b1a7)
* intel/fs: Rework zero-length URB write handlingJason Ekstrand2017-11-101-29/+31
| | | | | | | | | | | | | | | Originally we tried to handle this case based on slots_valid. However, there are a number of ways that this can go wrong. For one, we throw away any trailing slots which either aren't written or are set to VARYING_SLOT_PAD. Second, even if PSIZ is a valid slot, we may not actually write anything there. Between the lot of these, it was possible to end up in a case where we tried to do a regular URB write but ended up with a length of 1 which is invalid. This commit moves it to the end and makes it based on a new boolean flag urb_written. Reviewed-by: Iago Toral Quiroga <[email protected]> Cc: [email protected] (cherry picked from commit 7a82ad54bb56cafaeea7f909cd9fc35542c23ba0)
* intel/fs: Mark 64-bit values as being contiguousJason Ekstrand2017-11-101-1/+4
| | | | | | | | | | | | This isn't often a problem , when we're in a compute shader, we must push the thread local ID so we decrement the amount of available push space by 1 and it's no longer even and 64-bit data can, in theory, span it. By marking those uniforms contiguous, we ensure that they never get split in half between push and pull constants. Reviewed-by: Iago Toral Quiroga <[email protected]> Cc: [email protected] (cherry picked from commit 25f7453c9e6dc7c947b936bdac86680c332362bf)
* intel/fs: Fix integer multiplication lowering for src/dst hazardsJason Ekstrand2017-11-101-2/+8
| | | | | | Reviewed-by: Iago Toral Quiroga <[email protected]> Cc: [email protected] (cherry picked from commit d54f8ec744545673fd78f15ffce3cb4e47d4b5f1)
* intel/fs: Fix MOV_INDIRECT for 64-bit values on little-coreJason Ekstrand2017-11-101-36/+39
| | | | | | | | | | The same workaround we need for 64-bit values on little core also takes care of the Ivy Bridge problem and does so a bit more efficiently so we can drop that code while we're here. Reviewed-by: Iago Toral Quiroga <[email protected]> Cc: [email protected] (cherry picked from commit fd1bcccc2de9ba6a1ad6171342a155091963c3b9)
* intel/eu/reg: Add a subscript() helperJason Ekstrand2017-11-101-0/+16
| | | | | | | | This is similar to the identically named fs_reg helper. Reviewed-by: Iago Toral Quiroga <[email protected]> Cc: [email protected] (cherry picked from commit 10e4feed39120072f38274b95e884422f72f360f)
* intel/fs: Use a pair of 1-wide MOVs instead of SEL for any/allJason Ekstrand2017-11-101-9/+33
| | | | | | | | | | | | For some reason, the any/all predicates don't work properly with SIMD32. In particular, it appears that a SEL with a QtrCtrl of 2H doesn't read the correct subset of the flag register and you end up getting garbage in the second half. Work around this by using a pair of 1-wide MOVs and scattering the result. This fixes the any/all instructions for SIMD32. Reviewed-by: Matt Turner <[email protected]> Cc: [email protected] (cherry picked from commit 1b8ef49f48ae3634e4903422a9d9c11864c03cb1)
* intel/fs: Use an explicit D type for vote any/all/eq intrinsicsJason Ekstrand2017-11-101-0/+6
| | | | | | | | | | | | | | The any/all intrinsics return a boolean value so D or UD is the correct type. Unfortunately, get_nir_dest has the annoying behavior of returnning a float type by default. This causes format conversion which gives us -1.0f or 0.0f in the register. If the consumer of the result does an integer comparison to zero, it will give you the right boolean value but if we do something more clever based on the 0/~0 assumption for booleans, this will give the wrong value. Reviewed-by: Iago Toral Quiroga <[email protected]> Cc: [email protected] (cherry picked from commit 1f416630079f38110910ba796f70e2b81e9ddbf4)
* intel/fs: Don't stomp f0.1 in SIMD16 ballotJason Ekstrand2017-11-101-2/+9
| | | | | | | | | | In fragment shaders f0.1 is used for discards so doing ballot after a discard can potentially cause the discard to not happen. However, we don't support SIMD32 fragment shaders yet so this isn't a problem. Reviewed-by: Iago Toral Quiroga <[email protected]> Cc: [email protected] (cherry picked from commit 6c00240bc650805e0b66aa6e17dbe69bbe41e446)
* intel/fs: Use ANY/ALL32 predicates in SIMD32Jason Ekstrand2017-11-101-12/+30
| | | | | | | | | | | | | We have ANY/ALL32 predicates and, for the most part, they work just fine. (See the next commit for more details.) Also, due to the way that flag registers are handled in hardware, instruction splitting is able to split the CMP correctly. Specifically, that hardware looks at the execution group and knows to shift it's flag usage up correctly so a 2H instruction will write to f0.1 instead of f0.0. Reviewed-by: Matt Turner <[email protected]> Cc: [email protected] (cherry picked from commit def013a863558a1f4735d82ef3dfa0f8261fa743)
* intel/fs: Be more explicit about our placement of [un]zipJason Ekstrand2017-11-101-3/+17
| | | | | | | | | | | | | | Before, we were careful to place the zip after the last of the split instructions but did unzip on-demand. This changes things so that the unzips go before all of the split instructions and the unzip comes explicitly after all the split instructions. As a side-effect of this change, we now emit the split instruction from highest SIMD group to lowest instead of low to high. We could have kept the old behavior, but it shouldn't matter and this made the code easier. Reviewed-by: Iago Toral Quiroga <[email protected]> Cc: [email protected] (cherry picked from commit 0d905597fe2997c89022c76cdf84dc4fba5eb055)
* intel/fs: Pass builders instead of blocks into emit_[un]zipJason Ekstrand2017-11-101-26/+35
| | | | | | | | | | This makes it far more explicit where we're inserting the instructions rather than the magic "before and after" stuff that the emit_[un]zip helpers did based on block and inst. Reviewed-by: Iago Toral Quiroga <[email protected]> Cc: [email protected] (cherry picked from commit fcd4adb9d08094520fb8d118d3448b04c6ec1fd1)
* intel/fs: Use a pure vertical stride for large register stridesJason Ekstrand2017-11-101-3/+13
| | | | | | | | | | | | | | | Register strides higher than 4 are uncommon but they can happen. For instance, if you have a 64-bit extract_u8 operation, we turn that into UB -> UQ MOV with a source stride of 8. Our previous calculation would try to generate a stride of <32;8,8>:ub which is invalid because the maximum horizontal stride is 4. To solve this problem, we instead use a stride of <8;1,0>. As noted in the comment, this does not work as a destination but that's ok as very few things actually generate that stride. Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]> Cc: [email protected] (cherry picked from commit e8c9e65185de3e821e1e482e77906d1d51efa3ec)
* intel/fs: Alloc pull constants off mem_ctxJason Ekstrand2017-11-031-1/+1
| | | | | | | | | | | It doesn't actually matter since the only user of push constants, i965, ralloc_steals it back to NULL but it's more consistent and probably fixes memory leaks in some error cases. Reviewed-by: Lionel Landwerlin <[email protected]> Reviewed-by: Tapani Pälli <[email protected]> Cc: [email protected] (cherry picked from commit 7b4387519c382cffef9c62bbbbefcfe71cfde905)
* i965: fix blorp stage_prog_data->param leakTapani Pälli2017-11-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Patch uses mem_ctx for allocation to ensure param array gets freed later. ==6164== 48 bytes in 1 blocks are definitely lost in loss record 61 of 193 ==6164== at 0x4C2EB6B: malloc (vg_replace_malloc.c:299) ==6164== by 0x12E31C6C: ralloc_size (ralloc.c:121) ==6164== by 0x130189F1: fs_visitor::assign_constant_locations() (brw_fs.cpp:2095) ==6164== by 0x13022D32: fs_visitor::optimize() (brw_fs.cpp:5715) ==6164== by 0x13024D5A: fs_visitor::run_fs(bool, bool) (brw_fs.cpp:6229) ==6164== by 0x1302549A: brw_compile_fs (brw_fs.cpp:6570) ==6164== by 0x130C4B07: blorp_compile_fs (blorp.c:194) ==6164== by 0x130D384B: blorp_params_get_clear_kernel (blorp_clear.c:79) ==6164== by 0x130D3C56: blorp_fast_clear (blorp_clear.c:332) ==6164== by 0x12EFA439: do_single_blorp_clear (brw_blorp.c:1261) ==6164== by 0x12EFC4AF: brw_blorp_clear_color (brw_blorp.c:1326) ==6164== by 0x12EFF72B: brw_clear (brw_clear.c:297) Fixes: 8d90e28839 ("intel/compiler: Allocate pull_param in assign_constant_locations") Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> Cc: [email protected] (cherry picked from commit 446c5726ecb968d06a6607e0df42be1cb74948c4)
* intel/compiler/gen9: Pixel shader header only workaroundTopi Pohjolainen2017-11-031-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes intermittent GPU hangs on Broxton with an Intel internal test case. There are plenty of similar fragment shaders in piglit that do not use any varyings and any uniforms. According to the documentation special timing is needed between pipeline stages. Apparently we just don't hit that with piglit. Even with the failing test case one doesn't always get the hang. Moreover, according to the error states the hang happens significantly later than the execution of the problematic shader. There are multiple render cycles (primitive submissions) in between. I've also seen error states where the ACTHD points outside the batch. Almost as if the hardware writes somewhere that gets used later on. That would also explain why piglit doesn't suffer from this - most tests kick off one render cycle and any corruption is left unseen. v2 (Ken): Instead of enabling push constants, enable one of the inputs (PSIZ). v3 (Ken, Jason): Use LAYER instead making vulkan emit_3dstate_sbe() happy. Cc: "17.3 17.2" <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Topi Pohjolainen <[email protected]> (cherry picked from commit 97e01adfd549c260efd615289938265306d42a05)
* intel/eu: Use EXECUTE_1 for JMPIJason Ekstrand2017-10-272-2/+1
| | | | | | | | | | | | | The PRM says "The execution size must be 1." In 73137997e23ff6c11, the execution size was set to 1 when it should have been BRW_EXECUTE_1 (which maps to 0). Later, in dc2d3a7f5c217a7cee9, JMPI was used for line AA on gen6 and earlier and we started manually stomping the exeution size to BRW_EXECUTE_1 in the generator. This commit fixes the original bug and makes brw_JMPI just do the right thing. Reviewed-by: Matt Turner <[email protected]> Fixes: 73137997e23ff6c1145d036315d1a9ad96651281 (cherry picked from commit 562b8d458c2de262019da2c056f75cb9feb5ee54)
* i965: Fix memmem compiler warnings.Eric Anholt2017-10-271-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]> (cherry picked from commit e91c3540fc620b39a16d5bce9fd75aa0ddd7ed7e)
* anv/pipeline: Call nir_lower_system_valaues after brw_preprocess_nirJason Ekstrand2017-10-271-1/+2
| | | | | | | | | | | We currently have a bug where nir_lower_system_values gets called before nir_lower_var_copies so it will miss any system value uses which come from a copy_var intrinsic. Moving it to after brw_preprocess_nir fixes this problem. Reviewed-by: Lionel Landwerlin <[email protected]> Cc: [email protected] (cherry picked from commit 279f8fb69cf68d05287e14f60cf67fc025643bc4)
* anv/pipeline: Drop nir_lower_clip_cull_distance_arraysJason Ekstrand2017-10-271-2/+0
| | | | | | | We already handle it in brw_preprocess_nir Reviewed-by: Lionel Landwerlin <[email protected]> (cherry picked from commit afa0ddb81e693678069c630751e2091eea796937)
* intel/fs: Handle flag read/write aliasing in needs_src_copyJason Ekstrand2017-10-271-1/+3
| | | | | | | | | | | | | | | | In order to implement the ballot intrinsic, we do a MOV from flag register to some GRF. If that GRF is used in a SEL, cmod propagation helpfully changes it into a MOV from the flag register with a cmod. This is perfectly valid but when lower_simd_width comes along, it simply splits into two instructions which both have conditional modifiers. This is a problem since we're reading the flag register. This commit makes us check whether or not flags_written() overlaps with the flag values that we are reading via the instruction source and, if we have any interference, will force us to emit a copy of the source. Reviewed-by: Matt Turner <[email protected]> Cc: [email protected] (cherry picked from commit fa6e74e33e5bc5f6fba8f9de76b8b059515e708f)
* anv: don't assert on device init on CannonlakeLionel Landwerlin2017-10-211-2/+4
| | | | | | | v2: Warn that support is still in alpha (Jason) Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* anv: disable stencil pma fix on Gen > 9Lionel Landwerlin2017-10-211-0/+2
| | | | | | | | This workaround isn't listed on Gen10. Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* blorp: enable R32G32B32X32 blorp ccs copiesLionel Landwerlin2017-10-211-0/+1
| | | | | Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Use align1 mode on ternary instructions on Gen10+Matt Turner2017-10-201-4/+8
| | | | | | | | | Align1 mode offers some nice features over align16, like access to more data types and the ability to use a 16-bit immediate. This patch does not start using any new features. It just emits ternary instructions in align1 mode. Reviewed-by: Scott D Phillips <[email protected]>
* i965: Add align1 ternary instruction emission supportMatt Turner2017-10-201-55/+160
| | | | Reviewed-by: Scott D Phillips <[email protected]>
* i965: Add align1 ternary instruction disassembler supportMatt Turner2017-10-202-75/+288
| | | | Reviewed-by: Scott D Phillips <[email protected]>
* i965: Add align1 ternary instruction-word supportMatt Turner2017-10-201-0/+108
| | | | Reviewed-by: Scott D Phillips <[email protected]>
* i965: Add align1 ternary instruction support to conversion functionsMatt Turner2017-10-204-34/+101
| | | | Reviewed-by: Scott D Phillips <[email protected]>
* i965: Add align1 ternary instruction field encodingsMatt Turner2017-10-201-0/+35
| | | | Reviewed-by: Scott D Phillips <[email protected]>
* i965: Add functions to abstract access to 3src register typesMatt Turner2017-10-202-20/+23
| | | | Reviewed-by: Scott D Phillips <[email protected]>
* i965: Rename brw_inst's functions that access the 3src register typeMatt Turner2017-10-203-18/+18
| | | | | | | | | Put hw_ in the name so that it's clear these are the hardware encodings. Similar to commit 9fb832332868 ("i965: Rename brw_inst's functions that access the register type") Reviewed-by: Scott D Phillips <[email protected]>
* i965: Rename brw_inst 3src functions in preparation for align1Matt Turner2017-10-204-86/+92
| | | | Reviewed-by: Scott D Phillips <[email protected]>
* i965: Print subreg in units of type-size on ternary instructionsMatt Turner2017-10-201-5/+26
| | | | | | | | The instruction word contains SubRegNum[4:2] so it's in units of dwords (hence the * 4 to get it in terms of bytes). Before this patch, the subreg would have been wrong for DF arguments. Reviewed-by: Scott D Phillips <[email protected]>
* i965: Add functions for brw_reg_type <-> hw 3src typeMatt Turner2017-10-202-0/+58
| | | | Reviewed-by: Scott D Phillips <[email protected]>
* i965: Move brw_reg_type_is_floating_point to brw_reg_type.hMatt Turner2017-10-202-13/+15
| | | | | | | I'm going to call this from brw_inst.h, and I don't want to have to include all of brw_reg.h. Reviewed-by: Scott D Phillips <[email protected]>
* nir: Get rid of nir_shader::stageJason Ekstrand2017-10-2011-37/+38
| | | | | | | | It's redundant with nir_shader::info::stage. Acked-by: Timothy Arceri <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-12 07:52:46 +0000