summaryrefslogtreecommitdiffstats
path: root/src/intel
Commit message (Collapse)AuthorAgeFilesLines
* intel/fs: Bail in optimize_extract_to_float if we have modifiersJason Ekstrand2019-02-141-0/+9
| | | | | | | | | | | | This fixes a bug in runscape where we were optimizing x >> 16 to an extract and then negating and converting to float. The NIR to fs pass was dropping the negate on the floor breaking a geometry shader and causing it to render nothing. Fixes: 1f862e923cb "i965/fs: Optimize float conversions of byte/word..." Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109601 Tested-by: Lionel Landwerlin <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* intel/fs: Silence a compiler warningJason Ekstrand2019-02-141-2/+1
| | | | Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* anv: Silence some compiler warnings in release buildsJason Ekstrand2019-02-142-4/+4
| | | | Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* anv/blorp: Delete a pointless assertJason Ekstrand2019-02-141-5/+0
| | | | | | | | Just a little higher up in the function we assert that the aspect masks are actually equal so there's no reason for the weaker check. Also, the temporary variables were causing compiler warnings in release builds. Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* anv: Put MOCS in the correct locationKenneth Graunke2019-02-141-2/+2
| | | | | | | | | | | My patch to switch from struct-based MOCS to numeric MOCS accidentally divided all MOCS entries by 2 in the Vulkan driver. MOCS on Gen9+ is just an array index into a table. But in the hardware packets, the index starts at bit 1. So we need to shift it. Fixes: 0b44644ca68 (genxml: Consistently use a numeric "MOCS" field) Reviewed-by: Jason Ekstrand <[email protected]>
* anv/tests: compile to something sensible in release buildsEric Engestrom2019-02-145-0/+10
| | | | | | | | assert()-based tests make no sense without asserts, so make sure asserts are compiled in, even if the rest of the code has asserts turned off. Signed-off-by: Eric Engestrom <[email protected]> Acked-by: Lionel Landwerlin <[email protected]>
* drm-uapi: use local files, not system libdrmEric Engestrom2019-02-1419-27/+25
| | | | | | | | | There was an issue recently caused by the system header being included by mistake, so let's just get rid of this include path and always explicitly #include "drm-uapi/FOO.h" Signed-off-by: Eric Engestrom <[email protected]> Reviewed-by: Kristian H. Kristensen <[email protected]>
* intel: Use the NIR lowering for isign.Eric Anholt2019-02-143-31/+1
| | | | | | | | | | | Drops one instruction from fs-sign-int.shader_test. No change in shader-db due to it having 0 instances of sign(genIType). This may hurt isign64 if algebraic runs before int64 lowering, but I wasn't sure how to mark the algebraic opt as "every bit size but 64". v2: Update commit message about shader-db. Reviewed-by: Ian Romanick <[email protected]> (v1)
* meson: Add dependency on genxml to anvilDylan Baker2019-02-131-2/+5
| | | | | | | | | | | | Currently the Intel "anvil" driver races with the generation of genxml files, while i965 has an explicit dependency. This patch adds the same dependency to anvil. Fixes: d1992255bb29054fa51763376d125183a9f602f ("meson: Add build Intel "anv" vulkan driver") Acked-by: Jason Ekstrand <[email protected]> Acked-by: Lionel Landwerlin <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* anv/cmd_buffer: check for NULL framebufferJuan A. Suarez Romero2019-02-121-5/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This can happen when we record a VkCmdDraw in a secondary buffer that was created inheriting from the primary buffer, but with the framebuffer set to NULL in the VkCommandBufferInheritanceInfo. Vulkan 1.1.81 spec says that "the application must ensure (using scissor if neccesary) that all rendering is contained in the render area [...] [which] must be contained within the framebuffer dimesions". While this should be done by the application, commit 465e5a86 added the clamp to the framebuffer size, in case of application does not do it. But this requires to know the framebuffer dimensions. If we do not have a framebuffer at that moment, the best compromise we can do is to just apply the scissor as it is, and let the application to ensure the rendering is contained in the render area. v2: do not clamp to framebuffer if there isn't a framebuffer v3 (Jason): - clamp earlier in the conditional - clamp to render area if command buffer is primary v4: clamp also x and y to render area (Jason) v5: rename used variables (Jason) Fixes: 465e5a86 ("anv: Clamp scissors to the framebuffer boundary") CC: Jason Ekstrand <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* intel/compiler: add scale_factors to sampler_prog_key_dataTapani Pälli2019-02-122-0/+7
| | | | | | | | Patch propagates given scale_factors to lowering options. Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* intel/dump_gpu: Disambiguate between BOs from different GEM handle spaces.Francisco Jerez2019-02-111-18/+23
| | | | | | | | | | | | | | | | This fixes a rather astonishing problem that came up while debugging an issue in the Vulkan CTS. Apparently the Vulkan CTS framework has the tendency to create multiple VkDevices, each one with a separate DRM device FD and therefore a disjoint GEM buffer object handle space. Because the intel_dump_gpu tool wasn't making any distinction between buffers from the different handle spaces, it was confusing the instruction state pools from both devices, which happened to have the exact same GEM handle and PPGTT virtual address, but completely different shader contents. This was causing the simulator to believe that the vertex pipeline was executing a fragment shader, which didn't end up well. Reviewed-by: Lionel Landwerlin <[email protected]>
* intel/fs: Use enumerated array assignments in fb read TXF setupJason Ekstrand2019-02-111-5/+9
| | | | | | | It's more clear and means we don't have to update the array every time we add an optional texture instruction argument Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* intel/compiler: use 0 as sampler in emit_mcs_fetchCaio Marcelo de Oliveira Filho2019-02-082-2/+2
| | | | | | | | | | | | The sampler will be ignored since the underlying 'ld_mcs' operation won't use it, so just fill the field with 0 instead of the texture to make it clearer that's the case. This will also avoid is_high_sampler() to kick in unnecessarily, in case we are using the operation for a texture with index >= 16. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* intel/compiler: Silence warning about value that may be used uninitializedIan Romanick2019-02-081-1/+1
| | | | | | | | | | | | | | | | For some reason, this warning only occurs for me in release builds. In file included from src/intel/compiler/brw_nir_lower_mem_access_bit_sizes.c:25:0: src/intel/compiler/brw_nir_lower_mem_access_bit_sizes.c: In function ‘brw_nir_lower_mem_access_bit_sizes’: src/compiler/nir/nir_builder.h:501:26: warning: ‘src_swiz[2]’ may be used uninitialized in this function [-Wmaybe-uninitialized] alu_src.swizzle[i] = swiz[i]; ~~~~~~~~~~~~~~~~~~~^~~~~~~~~ src/intel/compiler/brw_nir_lower_mem_access_bit_sizes.c:225:16: note: ‘src_swiz[2]’ was declared here unsigned src_swiz[4]; ^~~~~~~~ Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* anv: assert that color attachment are validLionel Landwerlin2019-02-081-4/+1
| | | | | | | | | | | This reverts commit d76e7779884775bcebf235adb0e8367816b9b95d. Let's make this obvious that there is an application issue if it tries to access an attachment that doesn't exist in the current pass. Signed-off-by: Lionel Landwerlin <[email protected]> Fixes: d76e7779884775 ("anv: Handle VK_ATTACHMENT_UNUSED in colorAttachment") Reviewed-by: Jason Ekstrand <[email protected]>
* anv: wire up the state_pool_padding testEmil Velikov2019-02-051-0/+5
| | | | | | | | | Cc: Jason Ekstrand <[email protected]> Fixes: 927ba12b53c ("anv/tests: Adding test for the state_pool padding.") Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Eric Engestrom <[email protected]> Reviewed-by: Rafael Antognolli <[email protected]><Paste> Reviewed-by: Dylan Baker <[email protected]>
* isl: assert that Gen8+ don't have bit6_swizzlingCaio Marcelo de Oliveira Filho2019-02-041-0/+3
| | | | | | | v2: Rewrite the condition to more clearly match the comment. (Jordan) Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* anv: skip bit6 swizzle detection in Gen8+Caio Marcelo de Oliveira Filho2019-02-041-2/+14
| | | | | | | | It is always false on Gen8+. Also, move the variable definition near its use. Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* anv: Fix VK_EXT_transform_feedback working with varyings packed in PSIZDanylo Piliaiev2019-02-041-3/+20
| | | | | | | | | | | | | Transform feedback did not set correct SO_DECL.ComponentMask for varyings packed in VARYING_SLOT_PSIZ: gl_Layer - VARYING_SLOT_LAYER in VARYING_SLOT_PSIZ.y gl_ViewportIndex - VARYING_SLOT_VIEWPORT in VARYING_SLOT_PSIZ.z gl_PointSize - VARYING_SLOT_PSIZ in VARYING_SLOT_PSIZ.w Fixes: 36ee2fd61c8f94 "anv: Implement the basic form of VK_EXT_transform_feedback" Signed-off-by: Danylo Piliaiev <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* anv: Handle VK_ATTACHMENT_UNUSED in colorAttachmentDanylo Piliaiev2019-02-041-0/+4
| | | | | | | | | | | | | From the Vulkan 1.0.98 spec for vkCmdClearAttachments: "If the aspectMask member of any element of pAttachments contains VK_IMAGE_ASPECT_COLOR_BIT, then the colorAttachment member of that element must either refer to a color attachment which is VK_ATTACHMENT_UNUSED, or must be a valid color attachment." Signed-off-by: Danylo Piliaiev <[email protected]> Reviewed-by: Tapani Pälli <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]>
* anv: Implement VK_EXT_buffer_device_addressJason Ekstrand2019-02-015-2/+67
| | | | Reviewed-by: Lionel Landwerlin <[email protected]>
* intel/fs: Implement nir_intrinsic_global_atomic_*Jason Ekstrand2019-02-018-0/+202
| | | | eviewed-by: Kenneth Graunke <[email protected]>
* intel/fs: Use SENDS for A64 writes on gen9+Jason Ekstrand2019-02-011-10/+23
| | | | eviewed-by: Kenneth Graunke <[email protected]>
* intel/fs: Implement load/store_global with A64 untyped messagesJason Ekstrand2019-02-017-1/+273
| | | | eviewed-by: Kenneth Graunke <[email protected]>
* intel/fs: Do the grf127 hack on SIMD8 instructions in SIMD16 modeJason Ekstrand2019-02-011-7/+6
| | | | | | | | | | | Previously, we only applied the fix to shaders with a dispatch mode of SIMD8 but the code it relies on for SIMD16 mode only applies to SIMD16 instructions. If you have a SIMD8 instruction in a SIMD16 shader, neither would trigger and the restriction could still be hit. Fixes: 232ed8980217dd "i965/fs: Register allocator shoudn't use grf127..." Reviewed-by: Jose Maria Casanova Crespo <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel/fs: Properly handle 64-bit types in LOAD_PAYLOADJason Ekstrand2019-02-012-2/+7
| | | | | | | | | By just assigning dst.type to src[i].type, we ensure that the offset at the end of the loop actually offsets it by the right number of registers. Otherwise, we'll get into a case where we copy with a Q type and then offset with a D type and things get out of sync. Reviewed-by: Kenneth Graunke <[email protected]>
* intel/fs/cse: Split create_copy_instr into three casesJason Ekstrand2019-02-011-17/+17
| | | | | | | | | | Previously, we tried to combine all cases where the instruction being CSE'd writes to more than one MOV worth of registers into one case with a bit of special casing for LOAD_PAYLOAD. This commit splits things so that LOAD_PAYLOAD is entirely it's own case. This makes tweaking the LOAD_PAYLOAD case simpler in the next commit. Reviewed-by: Kenneth Graunke <[email protected]>
* intel/nir: Add global support to lower_mem_access_bit_sizesJason Ekstrand2019-02-011-0/+2
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* intel/fs: Fix memory corruption when compiling a CSOscar Blumberg2019-02-011-1/+2
| | | | | | | | Missing check for shader stage in the fs_visitor would corrupt the cs_prog_data.push information and trigger crashes / corruption later when uploading the CS state. Reviewed-by: Kenneth Graunke <[email protected]>
* meson: remove -std=c++11 from intel/toolsDylan Baker2019-01-311-1/+1
| | | | | | | | | | | | | | | | | | | | for meson all C++ code is already compiled as C++11, so it's unnecessary. It's also the wrong way to do this, if we really needed this the correct way is to set: ```meson executable( ... override_options : ['cpp_std=c++11'], ) ``` Which ensures not only that the correct syntax for the current compiler is used, but also that meson doesn't create arguments like `-std=c++14 ... -std=c++11` Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* meson: fix style in intel/toolsDylan Baker2019-01-311-15/+17
| | | | | | | | | The `:` in options should always have one space before and after `foo : bar`, and lists do not get spaces around the braces: `[foo]` not `[ foo ]` Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* meson: remove build_by_default : trueDylan Baker2019-01-311-7/+0
| | | | | | | | | Which is and has always been the default. This is largely an artifact of how the building of these tools was controlled when the meson build was originally created. Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* intel/fs: Use split sends for surface writes on gen9+Jason Ekstrand2019-01-292-18/+47
| | | | | | | | | | | | | Surface reads don't need them because they just have the one address payload. With surface writes, on the other hand, we can put the address and the data in the different halves and avoid building the payload all together. The decrease in register pressure and added freedom in register allocation resulting from this change reduces spilling enough to improve the performance of one customer benchmark by about 2x. Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Add interference between SENDS sourcesJason Ekstrand2019-01-291-0/+27
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Support SENDS in SHADER_OPCODE_SENDJason Ekstrand2019-01-293-8/+66
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/disasm: Properly disassemble split sendsJason Ekstrand2019-01-291-19/+142
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/eu: Add support for the SENDS[C] messagesJason Ekstrand2019-01-294-19/+255
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/inst: Indent some codeJason Ekstrand2019-01-291-177/+183
| | | | | | | We're about to add some more if cases so let's have the giant re-indent in it's own patch to make review easier. Acked-by: Iago Toral Quiroga <[email protected]>
* intel/inst: Fix the ia16_addr_imm helpersJason Ekstrand2019-01-291-4/+5
| | | | | | | | These have clearly never seen any use.... On gen8, the bottom 4 bits are missing so we need to shift them off before we call set_bits and shift again when we get the bits. Found by inspection. Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/disasm: Rework SEND decoding to use descriptorsJason Ekstrand2019-01-291-36/+50
| | | | | | | | | | | | Instead of fetching the information out of the instruction directly, fetch the descriptor and then pluck the information out of the descriptor. The current scheme works ok for SEND but with SENDS, it all falls to pieces because the descriptor is completely shuffled around. This commit doesn't actually convert everything. One notable exception is URB messages which don't even use descriptors in emit_urb_WRITE yet. Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/eu: Add more message descriptor helpersJason Ekstrand2019-01-291-27/+216
| | | | | | | | | | | | | | | | We want to be able to extract data from descriptors as well as unify a bit of the descriptor construction. One of the unifications we do is to unify the read/write and dataport descriptors. On gen4-5, read/write are substantially different and the read descriptors change between gen4 and gen4.x. On gen6, they unified layouts between read, write, and dataport. Then, on gen8, they added one bit to the message type field but left it reserved MBZ for read/write messages. This commit chooses to treat that as if they expanded the field everywhere and just didn't have enough enum values for read/write to bother with the extra bit. 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/eu: Use GET_BITS in brw_inst_set_send_ex_descJason Ekstrand2019-01-291-5/+5
| | | | | | It's a bit more readable Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Use SHADER_OPCODE_SEND for varying UBO pulls on gen7+Jason Ekstrand2019-01-297-88/+25
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Use SHADER_OPCODE_SEND for texturing on gen7+Jason Ekstrand2019-01-294-142/+177
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Use a logical opcode for IMAGE_SIZEJason Ekstrand2019-01-294-6/+21
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Use SHADER_OPCODE_SEND for surface messagesJason Ekstrand2019-01-295-214/+201
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Add a generic SEND opcodeJason Ekstrand2019-01-299-3/+91
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/eu: Rework surface descriptor helpersJason Ekstrand2019-01-292-234/+234
| | | | | | | | | | This commit pulls the surface descriptor helpers out into brw_eu.h and makes them no longer depend on the codegen infrastructure. This should allow us to use them directly from the IR code instead of the generator. This change is unfortunately less mechanical than perhaps one would like but it should be fairly straightforward. Reviewed-by: Iago Toral Quiroga <[email protected]>