- Dec 04, 2019
-
-
Dylan Baker authored
-
Daniel Schürmann authored
Fixes: 3a20ef4a 'aco: refactor value numbering' Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
-
- Dec 03, 2019
-
-
Faith Ekstrand authored
gl_Viewport is also in the VUE header so we need to whack the read offset to 0 and emit a default (no overrides) SBE_SWIZ entry in that case as well. Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (cherry picked from commit b1f37688)
-
Reworks: * Adjust comment to list the state packets that curro found to be affected. Fixes: 8125d796 ("intel/dev: Add preliminary device info for Tigerlake") Cc: 19.3 <mesa-stable@lists.freedesktop.org> Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Acked-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Francisco Jerez <currojerez@riseup.net> (cherry picked from commit e277009d)
-
Some backends require that there are no array varyings. If there were no arrays in the input shader, the pass shouldn't have to create new ones. Closes: mesa/mesa#2103 Closes: mesa/mesa#2167 Fixes: bcd14756 ('nir/lower_io_to_vector: add flat mode') Signed-off-by: Rhys Perry <pendingchaos02@gmail.com> Reviewed-by: Connor Abbott <cwabbott0@gmail.com> (cherry picked from commit 5404b7aa)
-
Fixes: 13ab63bb ('radv: Implement VK_EXT_buffer_device_address.') Signed-off-by: Rhys Perry <pendingchaos02@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> (cherry picked from commit 35fab1ba)
-
Fixes: 93c8ebfa 'aco: Initial commit of independent AMD compiler' Reviewed-by: Rhys Perry <pendingchaos02@gmail.com> (cherry picked from commit 8861a82b)
-
LLVM and the proprietary compiler seem to do this Fixes: b01847bd ("aco/gfx10: Fix mitigation of VMEMtoScalarWriteHazard.") Signed-off-by: Rhys Perry <pendingchaos02@gmail.com> Reviewed-by: Daniel Schürmann <daniel@schuermann.dev> (cherry picked from commit a9fc81b0)
-
Fixes: 93c8ebfa ('aco: Initial commit of independent AMD compiler') Signed-off-by: Rhys Perry <pendingchaos02@gmail.com> Reviewed-by: Daniel Schürmann <daniel@schuermann.dev> (cherry picked from commit 11f43caa)
-
Closes: mesa/mesa#2156 Fixes: 93c8ebfa ('aco: Initial commit of independent AMD compiler') Signed-off-by: Rhys Perry <pendingchaos02@gmail.com> Reviewed-by: Daniel Schürmann <daniel@schuermann.dev> (cherry picked from commit ff70ccad)
-
ptiled is always NULL so the if statement is useless. CoverityID: 1415572 Fixes: b9627765 ("etnaviv: rework compatible render base") CC: <mesa-stable@lists.freedesktop.org> Reviewed-by: Jonathan Marek <jonathan@marek.ca> Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> (cherry picked from commit 1be22083)
-
brw_performance_query_metrics.h was removed in 134e750e and brw_performance_query.h was removed in 8ae66679 remove reference to these files from Makefile.sources Signed-off-by: Jonathan Gray <jsg@jsg.id.au> Fixes: 134e750e ("i965: extract performance query metrics") Fixes: 8ae66679 ("intel/perf: move query_object into perf") Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> (cherry picked from commit 34dda0ca)
-
We must reset the damage info of our render targets here even though a damage reset normally happens when the DRI layer swaps buffers. That's because there can be implicit flushes the GL app is not aware of, and those might impact the damage region: if part of the damaged portion is drawn during those implicit flushes, you have to reload those areas before next draws are pushed, and since the driver can't easily know what's been modified by the draws it flushed, the easiest solution is to reload everything. Reported-by: Carsten Haitzler <raster@rasterman.com> Fixes: 65ae86b8 ("panfrost: Add support for KHR_partial_update()") Cc: <mesa-stable@lists.freedesktop.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> (cherry picked from commit c6e2096c)
-
BACK_LEFT attachment can be outdated when the user calls KHR_partial_update() (->lastStamp != ->texture_stamp), leading to a damage region update on the wrong pipe_resource object. Let's delay the ->set_damage_region() call until the attachments are updated when we're in that case. Reported-by: Carsten Haitzler <raster@rasterman.com> Fixes: 492ffbed ("st/dri2: Implement DRI2bufferDamageExtension") Cc: <mesa-stable@lists.freedesktop.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Marek Olšák <marek.olsak@amd.com> (cherry picked from commit b196e1a8)
-
Was totally broken ... Removed two if(point) {} because point is always non-NULL and we were counting on that already for counting, since we NULL our references to semaphores without active point earlier. Fixes: 4aa75bb3 "radv: Add wait-before-submit support for timelines." Closes: mesa/mesa#2137 Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> (cherry picked from commit 48fc6541)
-
pthread_mutex_unlock() when unlocked is documented by posix as being undefined behaviour. On OpenBSD pthread_mutex_unlock() will call abort(3) if this happens. This occurs in amdgpu_winsys_create() after cb446dc0 winsys/amdgpu: Add amdgpu_screen_winsys Signed-off-by: Jonathan Gray <jsg@jsg.id.au> Cc: 19.2 19.3 <mesa-stable@lists.freedesktop.org> Signed-off-by: Marek Olšák <marek.olsak@amd.com> (cherry picked from commit 3fe3bde4)
-
They were out of sync. Besides syncing, lets ensure they never diverge again. Fixes: 8d2654a4 "radv: Support VK_EXT_inline_uniform_block." Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> (cherry picked from commit 4cde0e04)
-
When drawing the main character in Shadow of Mordor, the game appears to draw Talion with one vertex shader, and the Wraith with another. If the compiler optimizes those in different ways which lead to slight imprecisions, then the resulting positions may not line up, leading to Z-fighting occurring as the game decides which of the two are in front. brw_nir_opt_peephole_ffma looks at usages of multiply adds across the entire shader, and may make different decisions between the two, leading to such imprecisions and Z-fighting. This started happening recently after a NIR change to eliminate unnecessary MOVs (7025dbe7), but that change simply exposed the existing problem. Improves performance on Skylake GT4e by 1.22945% +/- 0.398672% (n=3), likely due to the fixed rendering. Closes: mesa/mesa#1985 Fixes: 7025dbe7 ("nir: Skip emitting no-op movs from the builder.") Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit 51cc3808)
-
Many applications use multi-pass rendering and require their vertex shader position to be computed the same way each time. Optimizations may consider, say, fusing a multiply-add based on global usage of an expression in a shader. But a second shader with the same expression may have different code, causing that optimization to make the other choice the second time around. The correct solution is for applications to mark their VS outputs 'invariant', indicating they need multiple shaders to compute that output in the same manner. However, most applications fail to do so. So, we add a new driconf option - vs_position_always_invariant - which forces the gl_Position output in vertex shaders to be marked invariant. Fixes: 7025dbe7 ("nir: Skip emitting no-op movs from the builder.") Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit 9b577f2a)
-
This implementation is loosely based on ROCm. https://github.com/RadeonOpenCompute/ROCm-Device-Libs/blob/master/ockl/src/wfredscan.cl This fixes dEQP-VK.subgroups.arithmetic.*.subgroupexclusive* on GFX10. Fixes: 227c29a8 ("amd/common/gfx10: implement scan & reduce operations") Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> (cherry picked from commit c9aa8439) Conflicts resolved by Dylan Baker
-
- Nov 27, 2019
-
-
When a fragment shader includes an input variable decorated with SampleId or SamplePosition, sample shading should be enabled because minSampleShadingFactor is expected to be 1.0. Cc: 19.2, 19.3 <mesa-stable@lists.freedesktop.org> Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> (cherry picked from commit 86a5fbfd)
-
Dylan Baker authored
-
Do not link libgallium_nine with libgalliumvl_stub if it's already linked with libgalliumvl. Linking with stub leads to "duplicate symbol" errors. Fixes: 6b4c7047 ("meson: build gallium nine state_tracker") Closes: mesa/mesa#2040 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Dylan Baker <dylan@pnwbakers.com> (cherry picked from commit 9af22ccd)
-
Fixes: 946193ae "radv: add support for VK_AMD_buffer_marker" Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> (cherry picked from commit 25bc9102)
-
Commit 0899bf55 made some deqp-gles3 tests related to RGB8 PBOs fail on R600 because it exposed PIPE_FORMAT_R8G8B8_UNORM and R600 doesn't propely handle this. Disabling this format also for buffers fixes the issue. In addition, disabling also the related RGB8 integer formats for buffers fixes some deqp-gles3 tests: dEQP-GLES3.functional.texture.specification.teximage2d_pbo.rgb8ui_cube dEQP-GLES3.functional.texture.specification.texsubimage2d_pbo.rgb8i_2d dEQP-GLES3.functional.texture.specification.texsubimage2d_pbo.rgb8i_cube dEQP-GLES3.functional.texture.specification.texsubimage2d_pbo.rgb8ui_2d dEQP-GLES3.functional.texture.specification.texsubimage2d_pbo.rgb8ui_cube dEQP-GLES3.functional.texture.specification.teximage3d_pbo.rgb8i_2d_array dEQP-GLES3.functional.texture.specification.teximage3d_pbo.rgb8i_3d dEQP-GLES3.functional.texture.specification.teximage3d_pbo.rgb8ui_2d_array dEQP-GLES3.functional.texture.specification.teximage3d_pbo.rgb8ui_3d dEQP-GLES3.functional.texture.specification.texsubimage3d_pbo.rgb8i_2d_array dEQP-GLES3.functional.texture.specification.texsubimage3d_pbo.rgb8i_3d dEQP-GLES3.functional.texture.specification.texsubimage3d_pbo.rgb8ui_2d_array dEQP-GLES3.functional.texture.specification.texsubimage3d_pbo.rgb8ui_3d Fixes: 0899bf55 st/mesa: Map MESA_FORMAT_RGB_UNORM8 <-> PIPE_FORMAT_R8G8B8_UNORM Closes #2118 Signed-off-by: Gert Wollny <gert.wollny@collabora.com> Reviewed-by: Eric Anholt <eric@anholt.net> (cherry picked from commit e41958e3)
-
In order to prevent a potential malicious pipeline tainting our secure compile process and interfering with successive pipelines we want to create a fresh fork for each pipeline compile. Benchmarking has shown that simply forking on each pipeline creation doubles the total time it takes to compile a fossilize db collection. So instead here we fork the process at device creation so that we have a slim copy of the device and then fork this otherwise idle and untainted process each time we compile a pipeline. Forking this slim copy of the device results in only a 20% increase in compile time vs a 100% increase. Fixes: cff53da3 ("radv: enable secure compile support") (cherry picked from commit f54c4e85)
-
This will be used to create a communication pipe between the user facing device and a freshly forked (per pipeline compile) slim copy of that device. We can't use pipe() here because the fork will not be a direct fork of the user facing process. Instead we use a previously forked copy of the process that was forked at device creation in order to reduce the resources required for the fork and avoid performance issues. Fixes: cff53da3 ("radv: enable secure compile support") (cherry picked from commit 1663bb1f)
-
In the following commits we want to be able to fork an existing lightweight fork created at device creation time. In order for the user facing process to communicate with this new fresh fork we create some members here to hold FIFO file descriptors and a unique id. Here we also add a new fork enum that we use to tell the lightweight process to create a fresh fork. For more information on why we create a fresh fork see the following commits. (cherry picked from commit ef54f15d)
-
This reverts commit f97b731c. Closes: mesa/mesa#250 Reviewed-by: Roland Scheidegger <sroland@vmware.com> (cherry picked from commit a3c8bc10)
-
The CMP instruction on Gen4 and Gen5 generates one bit (the LSB) of valid data and 31 bits of junk. Results of comparisons that are used as Boolean values need to have a fixup applied to generate the proper 0/~0 values. Calling fs_visitor::nir_emit_alu with need_dest=false prevents the fixup code from being generated. This results in a sequence like: cmp.l.f0.0(16) g8<1>F g14<8,8,1>F 0x0F /* 0F */ ... cmp.l.f0.0(16) g4<1>F g6<8,8,1>F 0x0F /* 0F */ (+f0.1) or.z.f0.1(16) null<1>UD g4<8,8,1>UD g8<8,8,1>UD instead of cmp.l.f0.0(16) g8<1>F g14<8,8,1>F 0x0F /* 0F */ ... cmp.l.f0.0(16) g4<1>F g6<8,8,1>F 0x0F /* 0F */ or(16) g4<1>UD g4<8,8,1>UD g8<8,8,1>UD (+f0.1) and.z.f0.1(16) null<1>UD g4<8,8,1>UD 1UD I examined a couple of the shaders hurt by this change, and ALL of them would have been affected by this bug. :( Reviewed-by: Tapani Pälli <tapani.palli@intel.com> Closes: mesa/mesa#1836 Fixes: 0ba9497e ("intel/fs: Improve discard_if code generation") Iron Lake total instructions in shared programs: 8122757 -> 8122957 (<.01%) instructions in affected programs: 8307 -> 8507 (2.41%) helped: 0 HURT: 100 HURT stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 HURT stats (rel) min: 0.84% max: 6.67% x̄: 2.81% x̃: 2.76% 95% mean confidence interval for instructions value: 2.00 2.00 95% mean confidence interval for instructions %-change: 2.58% 3.03% Instructions are HURT. total cycles in shared programs: 188510100 -> 188510376 (<.01%) cycles in affected programs: 76018 -> 76294 (0.36%) helped: 0 HURT: 55 HURT stats (abs) min: 2 max: 12 x̄: 5.02 x̃: 4 HURT stats (rel) min: 0.07% max: 3.75% x̄: 0.86% x̃: 0.56% 95% mean confidence interval for cycles value: 4.33 5.71 95% mean confidence interval for cycles %-change: 0.60% 1.12% Cycles are HURT. GM45 total instructions in shared programs: 4994403 -> 4994503 (<.01%) instructions in affected programs: 4212 -> 4312 (2.37%) helped: 0 HURT: 50 HURT stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 HURT stats (rel) min: 0.84% max: 6.25% x̄: 2.76% x̃: 2.72% 95% mean confidence interval for instructions value: 2.00 2.00 95% mean confidence interval for instructions %-change: 2.45% 3.07% Instructions are HURT. total cycles in shared programs: 128928750 -> 128928982 (<.01%) cycles in affected programs: 67442 -> 67674 (0.34%) helped: 0 HURT: 47 HURT stats (abs) min: 2 max: 12 x̄: 4.94 x̃: 4 HURT stats (rel) min: 0.09% max: 3.75% x̄: 0.75% x̃: 0.53% 95% mean confidence interval for cycles value: 4.19 5.68 95% mean confidence interval for cycles %-change: 0.50% 1.00% Cycles are HURT. (cherry picked from commit e51eda99)
-
From OES_EGL_image_external_essl3 Closes: mesa/mesa#1901 Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by: Marek Olšák <marek.olsak@amd.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
-
Fixes: 32aba91c (llvmpipe: use ppc64le/ppc64 Large code model for JIT-compiled shaders) Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
-
Fixes: cea39af2 ("freedreno/ir3: Generalize ir3_shader_disasm()") Reviewed-by: Rob Clark <robdclark@gmail.com> (cherry picked from commit d0f38394)
-
Specifically when we are in non-uniform control flow, as we would need to set the condition for the last instruction. If (for example) a image atomic load stores directly their value on a NIR register, last_inst would be a nop, and would fail when set the condition. Fixes piglit test: spec/glsl-es-3.10/execution/cs-ssbo-atomic-if-else-2.shader_test Fixes: 6281f26f ("v3d: Add support for shader_image_load_store.") v2: (Changes suggested by Eric Anholt) * Cover all sig.ld* signals, not just ldunif and ldtmu, as all of them have the same restriction. * Update comment explaining why we add a MOV in that case * Tweak commit message. v3: * Drop extra set of parens (Eric) * Add missing ld signal to is_ld_signal to fix shader-db regression. Reviewed-by: Eric Anholt <eric@anholt.net> (cherry picked from commit b4bc59e3)
-
Fixes dEQP test: dEQP-GLES31.functional.synchronization.inter_call.with_memory_barrier.image_atomic_multiple_interleaved_write_read Fixes piglit test: spec/glsl-es-3.10/execution/cs-image-atomic-if-else.shader_test Fixes: 6281f26f ("v3d: Add support for shader_image_load_store.") Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Eric Anholt <eric@anholt.net> (cherry picked from commit d9830551)
-
When the scratch ringbuffer settings are changed, the shader unit has to be idle or we will have shaders using old and new settings. That combination is not supported on the HW (likely the offset is ringbuffer idx * WAVESIZE * 1024). CC: <mesa-stable@lists.freedesktop.org> Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> (cherry picked from commit 4eb2a1dc)
-
Eric Engestrom authored
Two files exist in that directory: - vulkan_xlib_randr.h - vulkan_xlib_xrandr.h Both were imported in 205c2715 ("vulkan: Update the XML and headers to 1.1.70") with identical contents (ie. the VK_EXT_acquire_xlib_display extension), but the former was never included anywhere and can't be found upstream [1], while the latter is included in vulkan.h and found upstream. [1] https://github.com/KhronosGroup/Vulkan-Headers/tree/master/include/vulkan Fixes: 205c2715 ("vulkan: Update the XML and headers to 1.1.70") Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Acked-by: Jason Ekstrand <jason@jlekstrand.net> (cherry picked from commit 344859c3)
-
- Nov 20, 2019
-
-
Dylan Baker authored
-
Faith Ekstrand authored
The bounds checking is actually less safe than just pushing the data. If the bounds checking actually ever kicks in and it's not on the last UBO push range, then the shrinking will cause all subsequent ranges to be pushed to the wrong place in the GRF. One of the behaviors we definitely don't want is for OOB UBO access to result in completely unrelated UBOs returning garbage values. It's safer to just push the UBOs as-requested. If we're really concerned about robustness, we can emit shader code to do bounds checking which should be stupid cheap (a CMP followed by SEL). Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
-
A security advisory (TALOS-2019-0857/CVE-2019-5068) found that creating shared memory regions with permission mode 0777 could allow any user to access that memory. Several Mesa drivers use shared- memory XImages to implement back buffers for improved performance. This path changes the shmget() calls to use 0600 (user r/w). Tested with legacy Xlib driver and llvmpipe. Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> (cherry picked from commit 02c3dad0)
-