- Apr 21, 2018
-
-
Dylan Baker authored
-
Dylan Baker authored
Signed-off-by: Dylan Baker <dylan.c.baker@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
-
Dylan Baker authored
This was introduced in commit 8f848ada but not added to the sources list, which is necessary for it to be included in release tarballs. Fixes: 8f848ada ("swr/rast: Start refactoring of builder/packetizer.") Signed-off-by: Dylan Baker <dylan.c.baker@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
-
Dylan Baker authored
This is needed to provide vk_android_native_buffer.h for vk_enum_to_str. v2: - remove accidentally included changes Signed-off-by: Dylan Baker <dylan.c.baker@intel.com> Acked-by: Kenneth Graunke <kenneth@whitecape.org>
-
This has the side-effect of fixing polygon-offset piglit test failures. Signed-off-by: Rhys Perry <pendingchaos02@gmail.com> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
-
Nanley Chery authored
We're going to combine ::mcs_buf and ::hiz_buf in later commits. Once that happens, this function no longer make sense. Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
-
Nanley Chery authored
Free the clear_color_bo in addition to freeing the intel_miptree_aux_buffer which holds the reference to it. Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
-
- Apr 20, 2018
-
-
Faith Ekstrand authored
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
-
Faith Ekstrand authored
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
-
Lucas Stach authored
memcmp returns 0 when both swizzles are the same, which means we don't need any hardware swizzling. texture_format_needs_swiz should return true when the return value of the memcmp is non-zero. Fixes: 751ae6af ("etnaviv: add support for swizzled texture formats") Cc: mesa-stable@lists.freedesktop.org Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Tested-by: Marek Vasut <marex@denx.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by: Wladimir J. van der Laan <laanwj@gmail.com>
-
Samuel Pitoiset authored
For subpass attachments we need one more coordinate with the layer, so make them array types. This fixes a bunch of CTS fails with RADV. Fixes: 24fb3e6a ("ac/nir: use ac_build_image_opcode for image intrinsics") Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
-
Bas Nieuwenhuizen authored
Otherwise a lot of games complain about not having enough memory, and it is sort of local so this seems reasonable to me. CC: 18.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
-
Samuel Pitoiset authored
The SI family doesn't support chaining which means the maximum size in dwords per CS is limited. When that limit was reached we failed to submit the CS and the application crashed. This patch allows to submit up to 4 IBs which is currently the limit, but recent amdgpu supports more than that. Please note that we can reach the limit of 4 IBs per submit but currently we can't improve that. The only solution is to upgrade libdrm. That will be improved later but for now this should fix crashes on SI or when using RADV_DEBUG=noibs. Fixes: 36cb5508 ("radv/winsys: Fail early on overgrown cs.") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105775 Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
-
We can't use any of the existing implementations in u_debug_stack. Android technically has libunwind, but it's been modified to the point where it no longer compiles with the Mesa usage. The library is also not meant to be referenced by vendor libraries. The officially sanctioned way of obtaining backtraces is through the Android own libbacktrace, a C++ library. Access it through a separate C++ source file on Android only. Signed-off-by: Stefan Schake <stschake@gmail.com> Acked-by: Eric Engestrom <eric.engestrom@imgtec.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
-
The fallback path for no libunwind ends up being stubs for Android. Don't compile them in so we can provide our own implementation. Signed-off-by: Stefan Schake <stschake@gmail.com> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
-
Samuel Pitoiset authored
This fixes a ton of CTS crashes. Fixes: c366f422 ("nir: Offset vertex_id by first_vertex instead of base_vertex") Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
-
Samuel Pitoiset authored
Ported from RadeonSI. Local BOs ignore BO priorities, and we don't need those on APUs. Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
-
Samuel Pitoiset authored
Maintaining two different paths is annoying but this gets rid of the performance regression introduced by the global BO list. We might find a better solution in the future, but for now just keeps two paths. Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
-
Samuel Pitoiset authored
In order to reduce a performance regression introduced by 4b13fe55 ("radv: Keep a global BO list for VkMemory."), we are going to maintain two different paths. One when VK_EXT_descriptor_indexing is enabled by the application because we need to have a global BO list, and one (the old one) when it's not enabled. With Talos on Polaris, the global BO list reduces performance by 10% which is too much for me. This reverts commit ab6cadd3. Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
-
José María Casanova Crespo authored
All operations with offset_reg at do_vector_read are done with UD type. So copy propagation was not working through the generated MOVs: mov(8) vgrf9:UD, vgrf7:D This change allows removing the MOV generated for reading the first components for 16-bit and 64-bit ssbo reads with non-constant offsets. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
-
Nicolai Hähnle authored
So that we'll use the dimension-aware intrinsics in the future. Acked-by: Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
In preparation of dimension-aware LLVM image intrinsics. Acked-by: Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
This is in preparation for the new image intrinsics. Acked-by: Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
This is in preparation for the new, dimension-aware LLVM image intrinsics. Acked-by: Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
-
Nicolai Hähnle authored
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
-
Nicolai Hähnle authored
The LLVM instruction returns { i32, i1 }, where the i1 indicates success. We're only interested in the first part, which is the loaded value. Fixes dEQP-GLES31.functional.compute.shared_var.atomic.compswap.* Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
-
Nicolai Hähnle authored
trans is zero-initialized, but trans->resource is setup immediately so needs to be dereferenced. Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
-
Nicolai Hähnle authored
It looks as if the structure fields array is fully initialized below, but in fact at least gcc in debug builds will not actually overwrite the unused bits of bit fields. Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
-
Aaron Watry authored
From CL 1.2 Section 5.2.1: CL_INVALID_VALUE if buffer was created with CL_MEM_HOST_WRITE_ONLY and flags specify CL_MEM_HOST_READ_ONLY , or if buffer was created with CL_MEM_HOST_READ_ONLY and flags specify CL_MEM_HOST_WRITE_ONLY , or if buffer was created with CL_MEM_HOST_NO_ACCESS and flags specify CL_MEM_HOST_READ_ONLY or CL_MEM_HOST_WRITE_ONLY . Fixes CL 1.2 CTS test/api get_buffer_info v2: Correct host_access_flags check (Francisco) Signed-off-by: Aaron Watry <awatry@gmail.com> Reviewed-by: Francisco Jerez <currojerez@riseup.net>
-
- Apr 19, 2018
-
-
Neil Roberts authored
base_vertex will be zero for non-indexed calls and in that case we need vertex_id to be offset by the ‘first’ parameter instead. That is what we get with first_vertex. This is true for both GL and Vulkan. The freedreno driver is also setting vertex_id_zero_based on nir_options. In order to avoid breakage this patch switches the relevant code to handle SYSTEM_VALUE_FIRST_VERTEX so that it can retain the same behavior. v2: change a3xx/fd3_emit.c and a4xx/fd4_emit.c from SYSTEM_VALUE_BASE_VERTEX to SYSTEM_VALUE_FIRST_VERTEX (Kenneth). Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Cc: Rob Clark <robdclark@gmail.com> Acked-by: Marek Olšák <marek.olsak@amd.com>
-
Neil Roberts authored
The base vertex in Vulkan is different from GL in that for non-indexed primitives the value is taken from the firstVertex parameter instead of being set to zero. This coincides with the new SYSTEM_VALUE_FIRST_VERTEX instead of BASE_VERTEX. v2 (idr): Add comment describing why SYSTEM_VALUE_FIRST_VERTEX is used for SpvBuiltInBaseVertex. Suggested by Jason. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> [v1] Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
-
Antía Puentes authored
Until we set gl_BaseVertex to zero for non-indexed draw calls both have an identical value. The Vertex Elements are kept like that: * VE 1: <BaseVertex/firstvertex, BaseInstance, VertexID, InstanceID> * VE 2: <Draw ID, 0, 0, 0> v2 (idr): Mark nir_intrinsic_load_first_vertex as "unreachable" in emit_system_values_block and fs_visitor::nir_emit_vs_intrinsic.
-
Neil Roberts authored
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
-
Antía Puentes authored
This VS system value will contain the value passed as <basevertex> for indexed draw calls or the value passed as <first> for non-indexed draw calls. It can be used to calculate the gl_VertexID as SYSTEM_VALUE_VERTEX_ID_ZERO_BASE plus SYSTEM_VALUE_FIRST_VERTEX. From the OpenGL 4.6 spec, 10.4 "Drawing Commands Using Vertex Arrays": - Page 352: "The index of any element transferred to the GL by DrawArraysOneInstance is referred to as its vertex ID, and may be read by a vertex shader as gl_VertexID. The vertex ID of the ith element transferred is first + i." - Page 355: "The index of any element transferred to the GL by DrawElementsOneInstance is referred to as its vertex ID, and may be read by a vertex shader as gl_VertexID. The vertex ID of the ith element transferred is the sum of basevertex and the value stored in the currently bound element array buffer at offset indices + i." Currently the gl_VertexID calculation uses SYSTEM_VALUE_BASE_VERTEX but this will have to change when the value of gl_BaseVertex is fixed. Currently its value is broken for non-indexed draw calls because it must be zero but we are setting it to <first>. v2: use SYSTEM_VALUE_FIRST_VERTEX as name for the value, instead of SYSTEM_VALUE_BASE_VERTEX_ID (Kenneth). v3 (idr): Rebase on Rob Clark converting nir_intrinsics.h to be generated. Reformat commit message to 72 columns. Reviewed-by: Neil Roberts <nroberts@igalia.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
-
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106131 Fixes: 34cb4d0e ("meson: build tests for gallium mesa state tracker") Signed-off-by: Mike Lothian <mike@fireburn.co.uk> Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
-
Bas Nieuwenhuizen authored
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
-
Bas Nieuwenhuizen authored
I have seen a few applications and games do the dynamic buffer bounds incorrectly, this make it easier to work around, e.g. for debugging. Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
-
Thomas Hellstrom authored
When advertizing this extension, egl_dri2 uses the DRI2_RENDERER_QUERY extension to query whether an sRGB format is supported. That extension will query our driver with the BIND flag PIPE_BIND_RENDER_TARGET rather than PIPE_BIND_DISPLAY_TARGET which is used when building the configs. We only return the correct value for PIPE_BIND_DISPLAY_TARGET. The inconsistency causes EGL to crash at surface initialization if sRGB is not supported. Fix this by supporting both bind flags. Testing done: piglit egl_gl_colorspace srgb Cc: <mesa-stable@lists.freedesktop.org> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Charmaine Lee <charmainel@vmware.com>
-
Include llvm/Transforms/Utils.h with the newest LLVM 7 v2: Include with " " rather than < > (Vinson Lee) v3: Use LLVM_VERSION_MAJOR rather than HAVE_LLVM (George Kyriazis) Signed-of-by: Mike Lothian <mike@fireburn.co.uk> Tested-by: Vinson Lee <vlee@freedesktop.org> Reviewed-By: George Kyriazis <george.kyriazis@intel.com>
-