- Mar 20, 2017
-
-
Emil Velikov authored
Signed-off-by:
Emil Velikov <emil.velikov@collabora.com>
-
Emil Velikov authored
Signed-off-by:
Emil Velikov <emil.velikov@collabora.com>
-
- Mar 17, 2017
-
-
This reverts commit cce43f6d. Redundant, as the flush already happens at si_cp_dma_prepare. Acked-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit ad4dee52)
-
The index passed to get_shared_memory_ptr is an attribute slot index, i.e. the index of a vec4 within LDS. Therefore this must be scaled by sizeof(vec4) to give the LDS byte offset. Fixes: f4e499ec ("radv: add initial non-conformant radv vulkan driver") Signed-off-by:
Alex Smith <asmith@feralinteractive.com> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> CC: <mesa-stable@lists.freedesktop.org> (cherry picked from commit ce4058da)
-
Avoid a buffer overflow in ac_nir_to_llvm.c's create_function when using more than 4 descriptor sets. radv claims support for 8. Cc: 17.0 <mesa-stable@lists.freedesktop.org> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> (cherry picked from commit e88cac1d)
-
Initially this was a workaround for a bug introduced in LLVM 4.0 in the SimplifyCFG pass that caused image instrinsics to disappear (because they were badly sunk). Finally, this is a win because it decreases SGPR spilling and increases the number of waves a bit. Although, shader-db results are good I think we might want to remove it in the future once the issue is fixed. For now, enable it for LLVM >= 4.0. This also fixes a rendering issue with the speedometer in Dirt Rally. More information can be found here https://reviews.llvm.org/D26348. Thanks to Dave Airlie for the patch. v2: - add a FIXME comment - use if (HAVE_LLVM >= 0x0400) instead Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99484 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97988 Signed-off-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Cc: 17.0 <mesa-stable@lists.freedesktop.org> Reviewed-by:
Marek Olšák <marek.olsak@amd.com> (cherry picked from commit 7751ed39) [Emil Velikov: resolve trivial conflicts] Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Conflicts: src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
-
- Mar 16, 2017
-
-
Need to flush before updating the buffer to ensure that the copy is ordered after previous accesses (assuming the app has performed the appropriate barriers). This fixes potential issues due to draws prior to an update reading the new buffer content, despite having the necessary barriers between them. Signed-off-by:
Alex Smith <asmith@feralinteractive.com> Cc: 17.0 <mesa-stable@lists.freedesktop.org> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit e0cc32b8)
-
The flushes could be due to TRANSFER barriers. Signed-off-by:
Bas Nieuwenhuizen <basni@google.com> Cc: 17.0 <mesa-stable@lists.freedesktop.org> Reviewed-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit cce43f6d)
-
Reviewed-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Connor Abbott <cwabbott0@gmail.com> Cc: "17.0 13.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 60d1aac2)
-
Reviewed-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by:
Connor Abbott <cwabbott0@gmail.com> Cc: "17.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 678fd00f)
-
For render passes with multiple subpasses on gen7, we only fast-clear at the top but an input attachment use can cause us to do a resolve in the middle of the render pass. Once we've done so, we are no longer have a fast-cleared surface so we can just set aux_usage to NONE. Reviewed-by:
Topi Pohjolainen <topi.pohjolainen@intel.com> Cc: "17.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 273b7203)
-
Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=587210 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68504 Acked-by:
Francisco Jerez <currojerez@riseup.net> (cherry picked from commit 7d1195c1)
-
When binding as textures, the alignment can be 16. However when binding as an image, the address has to be aligned to 256. (Also when binding as an RT, but that can't happen with GL or current gallium APIs.) Reported-by:
Roy Spliet <nouveau@spliet.org> Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Acked-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> (cherry picked from commit 32dd8d59)
-
2*4=8 Signed-off-by:
Gregory Hainaut <gregory.hainaut@gmail.com> Reviewed-by:
Timothy Arceri <tarceri@itsqueeze.com> Reviewed-by:
Matt Turner <mattst88@gmail.com> (cherry picked from commit 2ab5eccf)
-
This commit improves the message by telling them that they could probably enable DRI3. More importantly, it includes a little heuristic to check to see if we're running on AMD or NVIDIA's proprietary X11 drivers and, if we are, doesn't emit the warning. This way, users with both a discrete card and Intel graphics don't get the warning when they're just running on the discrete card. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99715 Co-authored-by:
Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by:
Kai Wasserbäch <kai@dev.carbon-project.org> Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net> Tested-by:
Rene Lindsay <rjklindsay@hotmail.com> Acked-by:
Dave Airlie <airlied@redhat.com> Cc: "17.0" <mesa-dev@lists.freedesktop.org> (cherry picked from commit 3d8feb38)
-
Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: "17.0 13.0" <mesa-dev@lists.freedesktop.org> (cherry picked from commit e3d33a23)
-
surf_usage is only useful to image views that may use HiZ buffers. Storage image views don't use HiZ buffers. v2: Update commit message and add an assertion. Fixes: 055ff2ec ("anv: Replace anv_image_has_hiz() with ISL_AUX_USAGE_HIZ") Signed-off-by:
Nanley Chery <nanley.g.chery@intel.com> Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net> (cherry picked from commit 258af3a8) [Emil Velikov: resolve trivial conflicts] Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Conflicts: src/intel/vulkan/anv_image.c
-
Ported from radeonsi, pointed out by Tom. "This prevents LLVM from using sext instructions for local memory offsets and allows the backend to fold immediate offsets into the instruction. This also prevents some incorrect code generation for ptrtoint and inttoptr instructions." Cc: "13.0 17.0" <mesa-stable@lists.freedesktop.org> Reviewed-by:
Tom Stellard <tstellar@redhat.com> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Signed-off-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit b8ee7038) [Emil Velikov: resolve trivial conflicts] Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Conflicts: src/amd/common/ac_nir_to_llvm.c
-
This should prevent cases when a buffer was incorrectly mapped without synchronization just because this wasn't done. Cc: 13.0 17.0 <mesa-stable@lists.freedesktop.org> Reviewed-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> (cherry picked from commit 71a2e4e9)
-
During initial CCS bring-up, I discovered that you have to do a full CS stall prior to doing a CCS resolve as well as afterwards. It appears that the same is needed for fast-clears as well. This fixes rendering corruptions on The Talos Principle on Sky Lake GT4. The issue hasn't been demonstrated on any other hardware however, given that this appears to be a "too many things in the pipe" problem, having it be easier to reproduce on a system with more EUs makes sense. The issues with resolves is demonstrable on a GT3 or GT2 so this is probably also a problem on all GTs. Reviewed-by:
Topi Pohjolainen <topi.pohjolainen@intel.com> Cc: "13.0 17.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 6b644e57)
-
The number of dynamic descriptors is limited by both the number of descriptors and the total number of dynamic things. Because there isn't a single "maximum dynamic things" limit, we need to divide by two so that they can create the maximum of both UBOs and SSBOs. Reviewed-by:
Eduardo Lima Mitev <elima@igalia.com> Cc: "17.0 13.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 5e44ef4a)
-
Emil Velikov authored
Cc: mesa-stable@lists.freedesktop.org Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net> (cherry picked from commit 077078ce) [Emil Velikov: resolve trivial conflicts] Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Conflicts: src/mesa/drivers/dri/i965/brw_defines.h
-
No idea what this does, but disabling it fixes a bunch of failing CTS tests in the lod area, so let's go with that. Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Cc: "13.0 17.0" <mesa-stable@lists.freedesktop.org> Signed-off-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit d81bd2f7)
-
The dynamic_offset_offset in the descriptor set binding layout is relative to the dynamic_offset_start for the set in the pipeline layout. Cc: 17.0 <mesa-stable@lists.freedesktop.org> Signed-off-by:
Fredrik Höglund <fredrik@kde.org> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> (cherry picked from commit 162beb2a)
-
This fixes the wrong dynamic buffer descriptors being updated when firstSet > 0. Cc: 17.0 <mesa-stable@lists.freedesktop.org> Signed-off-by:
Fredrik Höglund <fredrik@kde.org> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> (cherry picked from commit 0941d1a5)
-
It has issues and the fix I'm working on is too complicated for stable, so disable for now. Signed-off-by:
Bas Nieuwenhuizen <basni@google.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> CC: 13.0 17.0 <mesa-stable@lists.freedesktop.org> (cherry picked from commit 0ab2dd36)
-
If we have any pending flushes on the primary command buffer, these must be performed before executing the secondary buffer. This fixes potential corruption when the contents of a subpass which clears any of its render targets are given in a secondary buffer: the flushes after a fast clear would not have been performed until the vkCmdEndRenderPass call. Signed-off-by:
Alex Smith <asmith@feralinteractive.com> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Cc: 13.0 17.0 <mesa-stable@lists.freedesktop.org> (cherry picked from commit 290d7e89)
-
This isn't exposed in -pro, the hw docs say it is deprecated, so let's not bother with it. Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Cc: "13.0 17.0" <mesa-stable@lists.freedesktop.org> Signed-off-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit cc59e24a)
-
See detailed explanation of why this is needed in commit eb60a89b. This spot was missed/overlooked. Basically as a result of the fact that BEGIN_* ends up calling PUSH_SPACE, which in turn adds an extra 8 to the requested amount, we have to be mindful of that when doing bare nouveau_pushbuf_space calls. Reportedly this fixes some crashes when replaying a hitman trace taken on radeonsi. Fixes: eb60a89b ("nouveau: take extra push space into account for pushbuf_space calls") Cc: "13.0 17.0" <mesa-stable@lists.freedesktop.org> Reported-by:
Karol Herbst <nouveau@karolherbst.de> Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> (cherry picked from commit 8e6d6768)
-
Cc: <mesa-stable@lists.freedesktop.org> Signed-off-by:
Nanley Chery <nanley.g.chery@intel.com> Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net> (cherry picked from commit 178f9e5f)
-
The header of ralloc needs to be aligned, because the compiler assumes that malloc returns will be aligned to 8/16 bytes depending on the platform, leading to degraded performance or alignment faults with ralloc. Fixes SIGBUS on Raspberry Pi at high optimization levels. This patch is not perfect for MSVC, as maybe in the future the alignment for the most demanding data type might change to more than 8. v2: Commit message reword/typo fix, and add a bigger explanation in the code (by anholt) Signed-off-by:
Jonas Pfeil <pfeiljonas@gmx.de> Reviewed-by:
Matt Turner <mattst88@gmail.com> Reviewed-by:
Marek Olšák <marek.olsak@amd.com> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit cd2b55e5) Squashed with ralloc: don't leave out the alignment factor Experimentation shows that without alignment factor gcc and clang choose a factor of 16 even on IA-32, which doesn't match what malloc() uses (8). The problem is it makes gcc assume the pointer is 16 byte aligned, so with -O3 it starts using aligned SSE instructions that later fault, so always specify a suitable alignment factor. Cc: Jonas Pfeil <pfeiljonas@gmx.de> Fixes: cd2b55e5 "ralloc: Make sure ralloc() allocations match malloc()'s alignment." Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100049 Signed-off-by:
Grazvydas Ignotas <notasas@gmail.com> Tested by: Mike Lothian <mike@fireburn.co.uk> Tested by: Jonas Pfeil <pfeiljonas@gmx.de> (cherry picked from commit ff494fe9)
-
- Mar 15, 2017
-
-
The is_color_attachement variable is later read when handling two separate error cases, where only one of the cases results in the variable being initialized. This can be avoided by giving the variable a safe default value. Coverity-Id: 1398631 Cc: mesa-stable@lists.freedesktop.org Signed-off-by:
Robert Foss <robert.foss@collabora.com> Reviewed-by:
Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by:
Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by:
Marek Olšák <marek.olsak@amd.com> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit 88becf73)
-
Fixes: dEQP-EGL.functional.robustness.negative_context.invalid_robust_shared_context_creation Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by:
Eric Engestrom <eric.engestrom@imgtec.com> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 4061bbcc)
-
Even though compute shaders cannot access the framebuffer, there is a synchronization issue when a compute dispatch accesses a texture that was previously bound and drawn to as a framebuffer. Section 9.3 (Feedback Loops Between Textures and the Framebuffer) of the OpenGL 4.5 spec rather implicitly clarifies that undefined behavior results if the texture is still attached to the currently bound framebuffer. However, the feedback loop is broken when the application changes the framebuffer binding before a compute dispatch, and the state tracker needs to let the driver known about this. Fixes GL45-CTS.compute_shader.pipeline-post-fs on SI family Radeons. Cc: mesa-stable@lists.freedesktop.org Signed-off-by:
Marek Olšák <marek.olsak@amd.com> (cherry picked from commit 40c77bbf)
-
exec_node::get_prev() does not guard against going past the beginning of the list, so we need to add explicit checks here. Found by ASAN in piglit arb_shader_storage_buffer_object-rendering. Cc: mesa-stable@lists.freedesktop.org Signed-off-by:
Marek Olšák <marek.olsak@amd.com> (cherry picked from commit 911391bd)
-
This was hiding bugs as it retyped the source to destination's type. Signed-off-by:
Samuel Iglesias Gonsálvez <siglesias@igalia.com> Cc: "17.0" <mesa-stable@lists.freedesktop.org> Reviewed-by:
Francisco Jerez <currojerez@riseup.net> (cherry picked from commit 0dddad5b)
-
When generating the MOV INDIRECT instruction, the source type is ignored and it is set to destination's type. However, this is going to change in a later patch, so we need to explicitly set the proper source type. brw_vec8_grf() creates an float type's fs_reg by default, when the ICP handle is actually unsigned. This patch fixes these cases before applying the aforementioned patch. Signed-off-by:
Samuel Iglesias Gonsálvez <siglesias@igalia.com> Cc: "17.0" <mesa-stable@lists.freedesktop.org> Reviewed-by:
Francisco Jerez <currojerez@riseup.net> (cherry picked from commit d8122128)
-
The lowered BSW/BXT indirect move instructions had incorrect source types, which luckily wasn't causing incorrect assembly to be generated due to the bug fixed in the next patch, but would have confused the remaining back-end IR infrastructure due to the mismatch between the IR source types and the emitted machine code. v2: - Improve commit log (Curro) - Fix read_size (Curro) - Fix DF uniform array detection in assign_constant_locations() when it is acceded with 32-bit MOV_INDIRECTs in BSW/BXT. v3: - Move changes in assign_constant_locations() to other patch. Signed-off-by:
Samuel Iglesias Gonsálvez <siglesias@igalia.com> Cc: "17.0" <mesa-stable@lists.freedesktop.org> Reviewed-by:
Francisco Jerez <currojerez@riseup.net> (cherry picked from commit 56266df7)
-
Previously, if we had accesses with different sizes to the same uniform, we might not push it aligned with the bigger one. This is a problem in BSW/BXT when we access an array of DF uniform with both direct and indirect addressing because for the latter we use 32-bit MOV INDIRECT instructions. However this problem can happen with other generations and bitsizes. Signed-off-by:
Samuel Iglesias Gonsálvez <siglesias@igalia.com> Cc: "17.0" <mesa-stable@lists.freedesktop.org> Reviewed-by:
Francisco Jerez <currojerez@riseup.net> (cherry picked from commit a497ab68)
-
This bug can make that we don't detect the end of a contiguous area correctly and push larger areas than the real ones. Signed-off-by:
Samuel Iglesias Gonsálvez <siglesias@igalia.com> Cc: "17.0" <mesa-stable@lists.freedesktop.org> Reviewed-by:
Francisco Jerez <currojerez@riseup.net> (cherry picked from commit 74274252)
-