summaryrefslogtreecommitdiffstats
path: root/src/intel
Commit message (Collapse)AuthorAgeFilesLines
* imgui: make sure our copy of imgui doesn't clash with others in the same processLionel Landwerlin2019-02-211-0/+2
| | | | | | | | | | | Signed-off-by: Lionel Landwerlin <[email protected]> Acked-by: Jason Ekstrand <[email protected]> +1-by: Mike Lothian <[email protected]> +1-by: Tapani Pälli <[email protected]> +1-by: Eric Engestrom <[email protected]> +1-by: Yurii Kolesnykov <[email protected]> +1-by: myfreeweb <[email protected]> +1-by: Kenneth Graunke <[email protected]>
* build: move imgui out of src/intel/tools to be reusedLionel Landwerlin2019-02-2119-31619/+10
| | | | | | | | | | | Signed-off-by: Lionel Landwerlin <[email protected]> Acked-by: Jason Ekstrand <[email protected]> +1-by: Mike Lothian <[email protected]> +1-by: Tapani Pälli <[email protected]> +1-by: Eric Engestrom <[email protected]> +1-by: Yurii Kolesnykov <[email protected]> +1-by: myfreeweb <[email protected]> +1-by: Kenneth Graunke <[email protected]>
* nir, glsl: move pixel_center_integer/origin_upper_left to shader_info.fsAlejandro Piñeiro2019-02-214-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On GLSL that info is set as a layout qualifier when redeclaring gl_FragCoord, so somehow tied to a specific variable. But in practice, they behave as a global of the shader. On ARB programs they are set using a global OPTION (defined at ARB_fragment_coord_conventions), and on SPIR-V using ExecutionModes, that are also not tied specifically to the builtin. This patch moves that info from nir variable and ir variable to nir shader and gl_program shader_info respectively, so the map is more similar to SPIR-V, and ARB programs, instead of more similar to GLSL. FWIW, shader_info.fs already had pixel_center_integer, so this change also removes some redundancy. Also, as struct gl_program also includes a shader_info, we removed gl_program::OriginUpperLeft and PixelCenterInteger, as it would be superfluous. This change was needed because recently spirv_to_nir changed the order in which execution modes and variables are handled, so the variables didn't get the correct values. Now the info is set on the shader itself, and we don't need to go back to the builtin variable to set it. Fixes: e68871f6a ("spirv: Handle constants and types before execution modes") v2: (Jason) * glsl_to_nir: get the info before glsl_to_nir, while all the rest of the info gathering is happening * prog_to_nir: gather the info on a general info-gathering pass, not on variable setup. v3: (Jason) * Squash with the patch that removes that info from ir variable * anv: assert that OriginUpperLeft is true. It should be already set by spirv_to_nir. * blorp: set origin_upper_left on its core "compile fragment shader", not just on some specific places (for this we added an helper on a previous patch). * prog_to_nir: no need to gather specifically this fragcoord modes as the full gl_program shader_info is copied. * spirv_to_nir: assert that we are a fragment shader when handling this execution modes. v4: (reported by failing gitlab pipeline #18750) * state_tracker: update too due changes on ir.h/gl_program v5: * blorp: minor change after change on previous patch * radeonsi: update due this change. v6: (Timothy Arceri) * prog_to_nir: remove extra whitespace * shader_info: don't use :1 on origin_upper_left * glsl: program.fs.origin_upper_left/pixel_center_integer can be move out of the shader list loop
* blorp: introduce helper method blorp_nir_init_shaderAlejandro Piñeiro2019-02-213-7/+16
| | | | | | | | This initializes the nir shader that will be used by blorp. Right now it doesn't do too much beyond calling nir_builder_init_simple_shader, and setting a name. More stuff will be added on following patches. v2: there is a case were it is used a VERTEX_SHADER (Alejandro)
* anv: use anv_shader_bin_write_to_blob()'s return valueEric Engestrom2019-02-201-3/+1
| | | | | Signed-off-by: Eric Engestrom <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* anv: drop unused importsEric Engestrom2019-02-201-2/+0
| | | | | | Signed-off-by: Eric Engestrom <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* anv: make sure the extensions stay sortedEric Engestrom2019-02-201-0/+20
| | | | | Signed-off-by: Eric Engestrom <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* anv: sort vendors extensions after KHR and EXTEric Engestrom2019-02-201-2/+2
| | | | | Signed-off-by: Eric Engestrom <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* anv: sort extensions alphabeticallyEric Engestrom2019-02-201-1/+1
| | | | | | Signed-off-by: Eric Engestrom <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* anv: anv: refactor error handling in anv_shader_bin_write_to_blob()Tapani Pälli2019-02-201-28/+26
| | | | | | | | | | v2: blob manages error state internally, just return true if errors did not occur (Jason) CID: 1442546 Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Eric Engestrom <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* anv: implement VK_EXT_depth_clip_enableLionel Landwerlin2019-02-205-4/+23
| | | | | | | A new extension allowing the user to explictly specify the clipping behavior. Signed-off-by: Lionel Landwerlin <[email protected]>
* isl: remove the cache line size alignment requirementSamuel Iglesias Gonsálvez2019-02-201-14/+0
| | | | | | | | | | | | The cacheline size was a requirement for using the BLT engine, which we don't use anymore except for a few things on old HW, so we drop it. Fixes CTS's CL#3500 test: dEQP-VK.api.image_clearing.core.clear_color_image.2d.linear.single_layer.r8g8b8_unorm Signed-off-by: Samuel Iglesias Gonsálvez <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* intel/compiler/test: Add unit test for mismatched signedness comparisonMatt Turner2019-02-151-0/+32
| | | | | | | | | v2 (idr): Move adding the test to after adding the fix. Reordering the two commits prevents possible headaches for git-bisect with scripts that always do 'ninja check'. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109404 Reviewed-by: Ian Romanick <[email protected]>
* intel/compiler: Avoid propagating inequality cmods if types are differentMatt Turner2019-02-151-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | v2: Fix silly bug in logic. s/||/&&/ All but one of the affected shaders is in an Unreal4 demo. The other is in Tomb Raider. All of the cases that Ian investigated appear to be sequences like the following if (int(uint(some_float)) < 0) /* other relations too */ ... At least in Tomb Raider, it's not obvious that this sequence came from the original shader. In some of the Unreal demos, the shader contains code like if (int(uint(textureLod(...))) > 0) ... which explicitly generates the offending sequence. All Gen6+ platforms had similar results (Skylake shown): total instructions in shared programs: 15437170 -> 15437187 (<.01%) instructions in affected programs: 4492 -> 4509 (0.38%) helped: 0 HURT: 17 HURT stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 HURT stats (rel) min: 0.05% max: 0.73% x̄: 0.66% x̃: 0.73% 95% mean confidence interval for instructions value: 1.00 1.00 95% mean confidence interval for instructions %-change: 0.57% 0.75% Instructions are HURT. total cycles in shared programs: 383007996 -> 383007992 (<.01%) cycles in affected programs: 20542 -> 20538 (-0.02%) helped: 6 HURT: 7 helped stats (abs) min: 2 max: 6 x̄: 5.33 x̃: 6 helped stats (rel) min: 0.11% max: 0.36% x̄: 0.32% x̃: 0.36% HURT stats (abs) min: 4 max: 4 x̄: 4.00 x̃: 4 HURT stats (rel) min: 0.27% max: 0.27% x̄: 0.27% x̃: 0.27% 95% mean confidence interval for cycles value: -3.30 2.69 95% mean confidence interval for cycles %-change: -0.19% 0.19% Inconclusive result (value mean confidence interval includes 0). No changes on Iron Lake or GM45. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109404 Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Tested-by: [email protected] Tested-by: Danylo Piliaiev <[email protected]>
* intel/compiler/test: Set devinfo->gen = 7Matt Turner2019-02-151-1/+1
| | | | | | | We emit an FBL instruction which only exists since Gen7. This prevents the test from segfaulting when run with TEST_DEBUG=1. Reviewed-by: Ian Romanick <[email protected]>
* 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]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-25 09:07:25 +0000