Debugging fd mix-ups (ie. where, possibly via close()ing the original
fd, etc, you end up with something that is a valid fd but not a valid
*fence* fd) can be difficult. Fortunately we can use the FILE_INFO
ioctl, which will return an error if the fd is not a fence fd.
For android, we instead use the libsync API, which does a similar thing
on modern kernels, but has a fallback path for older android kernels.
Note that the FILE_INFO ioctl has existed upstream since at least prior
to destaging of sync_file.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11202>
We shouldn't be using RETURN_EGL_EVAL() for eglDupNativeFenceFDANDROID()
return, as (while perhaps unlikely) zero is a valid fd. The error case
for EGL_NO_NATIVE_FENCE_FD_ANDROID is already handled in egl_dri2.c
(dri2_dup_native_fence_fd()) so just use RETURN_EGL_SUCCESS() instead.
Also fix ret type.
Fixes: 0201f01dc4 ("egl: add EGL_ANDROID_native_fence_sync")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11202>
Most allocations will want to be in device local memory (if it exists),
so we default to LMEM in the absence of a flag. However, some buffers
are expected to be read/written from the CPU multiple times, and we may
want to explicitly place those buffers in system memory.
This patch adds the infrastructure for deciding on the allocation,
and sets the flags, but does not actually hook up the flag to do
anything, as the kernel infrastructure for LMEM support hasn't landed.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11169>
In the past, we tracked bo->tiling_mode and bo->stride, and used
GEM_{GET,SET}_TILING on all buffers we allocated. This made more sense
in the old days (long before iris even existed) when we used GTT maps to
detile resources. However, that support is now gone, and we never used
it in iris anyway. We don't need to do this in most cases anymore.
We are trying to deprecate these kernel APIs. They have many issues.
One is having a global tiling mode for a buffer when userspace may
want to suballocate multiple resources with different tiling modes
from the same object. Another is...what if processes want to interpret
the data differently, and hot-swap the tiling mode out from under
another process? Another is the fundamental race conditions. There
are many reasons not to use these APIs.
Unfortunately, there is still one case where it's used: when importing
and exporting DMABUFs, we have to communicate the tiling somehow. The
right way to do that is using modifiers, but those didn't always exist,
and aren't always enabled (maybe aren't even commonly enabled). So we
use GET/SET_TILING as a poor-man's IPC mechanism of sorts.
This patch stops calling those APIs in general but continues doing so
for imported/exported objects when we don't have modifiers.
We eliminate iris_bo_alloc_tiled entirely. There is now only one!
One small behavioral change snuck in: iris_memobj_create_from_handle
now aligns the virtual address to 64K rather than 1B when modifiers
aren't present. This should be harmless, and lets us delete a whole
bunch of code.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11169>
This is rarely useful, but after the next patch removes tiling tracking,
this would literally be the only difference between iris_bo_alloc and
iris_bo_alloc_tiled, so we may as well add it.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11169>
Based on a patch by Rafael Antognolli.
We already had a flags parameter, but omitted it from the simple alloc
interface because most callers were passing 0. However, we'll want to
use it for selecting between device local memory and system memory, and
possibly mmap cacheability modes, in the future. At that point, many
more callers will want to specify, so I think we should include flags
in iris_bo_alloc() as well.
A few places used the iris_bo_alloc_tiled() function simply to pass
flags, so this patch converts them to use iris_bo_alloc() instead now
it does everything they want.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11169>
Since 40e1d798c6, we are now using physical register numbers for
everything which makes it all simpler. In particular, we no longer need
the special case for setting up the payload for SIMD16 on Gen4-5. This
fixes a pile of piglit tests on ILK and similar.
Fixes: 40e1d798c6 "intel/fs: Use ra_alloc_contig_reg_class()..."
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11221>
How to use:
- For GALLIUM drivers:
1. Add gallium drivers into your board.mk file:
board.mk:
BOARD_MESA3D_USES_MESON_BUILD := true
BOARD_MESA3D_GALLIUM_DRIVERS := lima panfrost v3d
2. Add the following packages into your device.mk file:
device.mk:
PRODUCT_PACKAGES += \
libEGL_mesa \
libGLESv1_CM_mesa \
libGLESv2_mesa \
libgallium_dri \
libglapi
- For VULKAN drivers:
1. Add single vulkan driver into your board.mk file:
board.mk:
BOARD_MESA3D_USES_MESON_BUILD := true
BOARD_MESA3D_VULKAN_DRIVERS := freedreno broadcom
2. Add the following package configuration into your device.mk file:
device.mk:
PRODUCT_PACKAGES += \
vulkan.freedreno
PRODUCT_PROPERTY_OVERRIDES += \
ro.hardware.vulkan=freedreno
- To build 'libgbm' set definition in the board.mk:
BOARD_MESA3D_BUILD_LIBGBM := true
And add a package to the device.mk:
PRODUCT_PACKAGES += libgbm
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Tested-by: Mauro Rossi <issor.oruam@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10183>
'platform_android' wasn't designed to coexist with 'platform_drm' within
single build, therefore a lot of conflicts appears during compile-time.
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Tested-by: Mauro Rossi <issor.oruam@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10183>
Since the move from master to main, our "Edit on GitLab" links on
docs.mesa3d.org has been pointing to the wrong branch.
Let's fix this, so we don't confuse users who want to contribute
changes.
Acked-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11160>
Not all hardware can treat float, uint and sint samplers and images the
same way, so we need to respect the format-types here.
This has the added benefit of making sure sint and uint data doesn't
get copied through a float, which might mess with signaling nan
encodings.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11164>
We can only support subgroup vote if we have support for SPIR-V 1.3 or
later.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11044>
This moves the previous check up to the screen-creation, making it
possible to enable features based on the SPIR-V version.
The reason we want to be able to do this, is so we can force specific
SPIR-V versions, in order to work around bugs in tools.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11044>
This will hopefully helps making it easier to override the SPIR-V
version we emit, in case some drivers or tools have issues with too
recent SPIR-V versions.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11044>
To make it a bit easier to follow what's going on here, rename the
"spirv_15" boolean to "spirv_1_4_interfaces", and add a comment about
what it's all about.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11044>
The Vulkan spec says the following:
> If imageType is VK_IMAGE_TYPE_2D and flags contains
> VK_IMAGE_CREATE_CUBE_COMPATIBLE_BIT, extent.width and extent.height
> must be equal and arrayLayers must be greater than or equal to 6
This makes a lot of sense, as these are also requirements for being able
to create cubemaps from them in the first place.
Let's thread a bit more careful, and only set this bit in these cases.
This matters in the new case of setting this flag on 2D array textures.
In the other cases, this should already be the case.
I haven't seen this trigger any issues, I just realized this while
reading the Vulkan-spec.
Fixes: 1887ff2ebb ("zink: mark 2d-arrays as cube-compatible")
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11081>
Make helper functions for all descriptor types and have them handle
all of the descriptor update so we can reuse them later to implement
template updates.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11213>
This clarifies the semantics of the index variables compared to the previous
version, which used the same variables in a slightly different way depending
on whether they were used for downwards moves or upwards ones.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10885>
Refactoring total_demand and total_demand_clause to cover non-overlapping
instruction intervals makes the code easier to follow and allows the register
demand to be updated more efficiently in some cases.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10885>
buffer_indices_hashlist is only used by the current
amdgpu_cs_context (= amdgpu_cs.csc).
So store a single 16k int array instead of 2, and switch
the owner when flushing the cs.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11010>
Otherwise the pb_slabs might be freed by another thread in between.
Valgrind example:
==676841== Invalid read of size 1
==676841== at 0x6B0A8B3: get_slab_wasted_size (amdgpu_bo.c:659)
==676841== by 0x6B0AD7D: amdgpu_bo_slab_destroy (amdgpu_bo.c:684)
==676841== by 0x6ACF94F: pb_destroy (pb_buffer.h:259)
==676841== by 0x6ACF94F: pb_reference_with_winsys (pb_buffer.h:282)
==676841== by 0x6ACF94F: radeon_bo_reference (radeon_winsys.h:754)
==676841== by 0x6ACF94F: si_replace_buffer_storage (si_buffer.c:274)
==676841== by 0x6957036: tc_call_replace_buffer_storage (u_threaded_context.c:1554)
[...]
==676841== by 0x4ECCDEE: clone (clone.S:95)
==676841== Address 0x27879945 is 5 bytes inside a block of size 208 free'd
==676841== at 0x48399AB: free (vg_replace_malloc.c:538)
==676841== by 0x6B0E8BD: amdgpu_bo_slab_free (amdgpu_bo.c:863)
==676841== by 0x6B89D4A: pb_slabs_reclaim_locked (pb_slab.c:84)
==676841== by 0x6B89D4A: pb_slab_alloc (pb_slab.c:130)
==676841== by 0x6B0EE7F: amdgpu_bo_create (amdgpu_bo.c:1429)
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4736
Fixes: 965c6445ad ("winsys/amdgpu,radeonsi: add HUD counters for how much memory is wasted by slabs")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11010>
This extension is basically only wrapping SPV_KHR_storage_buffer_storage_class
which is entirely implemented in the SPIR-V frontend.
Relevant CTS tests:
dEQP-VK.glsl.opaque_type_indexing.ssbo_storage_buffer_decoration.*
dEQP-VK.spirv_assembly.*
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11184>
This add a simple mechanism to select which GPU adapter the d3d12
driver should be using. A new environment variable is introduced.
MESA_D3D12_DEFAULT_ADAPTER_NAME
This represent a substring to search for in the GPU descrition,
for example "NVIDIA" or "INTEL", or "NVIDIA GeForce RTX 3090",
etc...
GPU are searched in order and the first one to include the substring
becomes a match. If no match is found, we default to the first
enumerated GPU.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10710>
This hardware supports all of the points of ES 3.1 with the minor
exception of non-red gather operations.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Pierre Moreau <dev@pmoreau.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10569>
This is not enough for desktop GL, since that requires support for
images/buffers in fragment shaders. However this is sufficient for ES
3.1's compute needs, where images/buffers need only be supported in
compute shaders.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Pierre Moreau <dev@pmoreau.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10569>
Such a driver will be expected to handle indirect draws via emulation.
As such we don't want to expose the ext in desktop GL contexts. However
for ES 3.1 it's a required feature, so makes sense to allow fallbacks.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10569>
Right now these rely on the desktop extension enables being set. However
some drivers may not be able to support that full functionality. Allow
presence of ES 3.1 to be sufficient.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10569>
Since the extension was added, we grew a cap to expose the number of
invocations. Use it to prevent geometry shaders from being spuriously
exposed.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10569>
The desktop extensions require more than what's needed for ES 3.1.
Reduce this to allow implementations to expose ES 3.1 without supporting
desktop functionality.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10569>
The requirements for ES 3.1 are lower than the requirements for desktop
GL. The thread block size can be smaller, and images/buffers/atomics
need not be supported in the fragment stage. Allow a driver to expose
ES 3.1 without flipping on the desktop GL extensions.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10569>
NVIDIA hardware can process tall or wide videos, but not both at the
same time (for some gens). This limit is provided in units of
macroblocks.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10677>
The hardware has no support for 3d image loads/stores. So present the
image as a larger 2d image and fudge the coordinates. Note that a 2d
image (in the shader) may be backed by a slice of a 3d image, so we
always have to do the coordinate adjustments for 2d as well.
This is largely copied from the nv50 support, which has the same
restriction, with extra care taken to differentiate loads (which
specifies the X coordinate in bytes) and stores, which specifies it in
(formatted) pixels.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10820>
Prior to an earlier commit, xfb queries were not being marked as 64-bit.
The end result of this is that they would never appear to be "ready",
which in turn led to there always being a wait happening.
Once these got marked as 64-bit, we started checking the attached fence
for being signalled. However the screen fence does not seem to be enough
to wait for the streamout query data to actually be written out. So
instead we add a bit of extra "data" which emulates the 32-bit query way
of doing things (with the payload in front) which is emitted from the
same "unit" as the other streamout data. This seems to be sufficient.
Note that it does not seem to be required to actually emit the final
32-bit query from the streamout unit, but that seems logical and perhaps
there are edge cases where it is required.
While at it, also make the sequence management/initialization more
similar to the nvc0 driver.
Fixes dEQP-GLES3.functional.transform_feedback.*
Fixes: 58d47ca324 ("nv50: add compute invocations counter")
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10867>
Fix defect reported by Coverity Scan.
Side effect in assertion (ASSERT_SIDE_EFFECT)
assignment_where_comparison_intended: Assignment deviceMask = 1U
has a side effect. This code will work differently in a non-debug
build.
Fixes: 234e1b7356 ("v3dv: implement VK_KHR_device_group")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11197>
Rob Clark
Kenneth Graunke
Jason Ekstrand
Roman Stratiienko
Erik Faye-Lund
Iago Toral Quiroga
Tony Wasserka
Marcin Ślusarz
Pierre-Eric Pelloux-Prayer
Steve Pronovost
Ilia Mirkin
Vinson Lee
Yiwei Zhang
Alyssa Rosenzweig