Instructions that take a F16 value can generally select which component to
read from. This lets us get rid of some PRMTs.
This also cleans up partial support for it for F2F and streamlines
everything into an uniform model as previously it wasn't wired up
generally and copy prop didn't always propagate the swizzle through.
This also makes it uneccessary to apply a Xx swizzle to scalar FP16
sources.
Totals from 907 (0.08% of 1163204) affected shaders:
CodeSize: 40856816 -> 40843408 (-0.03%); split: -0.03%, +0.00%
Static cycle count: 20898101 -> 20895619 (-0.01%); split: -0.01%, +0.00%
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40392>
By using `GIT_STRATEGY: empty` instead of `none`.
As documented in https://docs.gitlab.com/ci/runners/configure_runners/#git-strategy
Unlike `none`, the `empty` Git strategy deletes and then re-creates
a dedicated build directory before downloading cache or artifact files.
With this strategy, the GitLab Runner hook scripts are still run (if
provided) to allow for further behavior customization. Use the `empty`
Git strategy when:
- You do not need the repository data to be present.
- You want a clean, controlled, or customized starting state every
time a job runs.
In CI-tron jobs we put things there at the start of the job that we want
to keep through the start of the test and until the end of the job.
This requires gitlab-runner >= 17.10, which is already satisfied by all
ci-tron deployments.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35740>
From the OpenCL specification:
`CL_MEM_KERNEL_READ_AND_WRITE`: This flag is only used by
clGetSupportedImageFormats to query image formats that may be both
read from and written to by the same kernel instance. To create a
memory object that may be read from and written to use
CL_MEM_READ_WRITE.
If an application follows the instructions above, i.e. query a list of
supported image formats, using `CL_MEM_KERNEL_READ_AND_WRITE` as
input, and then attempts to create an image using one of the supported
image formats, by calling `clCreateImage` and passing
`CL_MEM_READ_WRITE`, the call to the image creation entry point should
succeed. This instead fails on Mali devices with the error
`CL_IMAGE_FORMAT_NOT_SUPPORTED`.
Rusticl fails when validating the image format against its supported
flags. Formats that support `PIPE_BIND_SHADER_IMAGE` have their
supported flags set as `CL_MEM_WRITE_ONLY` and
`CL_MEM_KERNEL_READ_AND_WRITE`.
This changes the supported CL flags to be `CL_MEM_WRITE_ONLY` for
`PIPE_BIND_SHADER_IMAGE` and `CL_MEM_READ_WRTE |
CL_MEM_KERNEL_READ_AND_WRITE` for `PIPE_BIND_SAMPLER_VIEW |
PIPE_BIND_SHADER_IMAGE`.
Fixes: 3386e142 (rusticl: support read_write images)
Fixes OpenCL-CTS test: `test_image_streams` on Mali. Invocation:
```
test_image_streams write 1D CL_RGB CL_SIGNED_INT8
```
Signed-off-by: Ahmed Hesham <ahmed.hesham@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39692>
Before this, everything was in the giant bifrost_compile.c file, now
preprocess, optimize and postproces are in their own "small"
bifrost_nir.c.
I also removed some dead functions and moved the passes closer to their
usage, (ex, passes only used in preprocess are now just before
preprocess). Otherwise it's all the same code we had before.
Signed-off-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40717>
VCN 5_0_1 uses gfx9 address mode. This was also set in previous
radeon_vcn_dec codes.
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Reviewed-by: David Rosca <david.rosca@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40736>
This would read OOB and crash because data type is optional per the
SPIRV spec.
Original patch by Faith Ekstrand <faith.ekstrand@collabora.com>.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40731>
When converting the index buffer from 4-bytes to 2-bytes, we use the
uploader for the job. Since commit b3133e250e we do an uploader alloc
ref, which releases the uploader buffer if there is no enough space,
creating a new one.
The problem happens when we also need this buffer because it is the one
containing the index buffer to convert. This happens, for instance, if
we need to convert the primitives because they are not supported (e.g.,
converting quads to triangles), as this is done
also using the uploader.
The solution is to ensure the uploader's buffer has an extra reference
so when released, it is not destroyed. This can easily achieved by
calling first pipe_buffer_map_range(), which is required to access the
buffer, and it increases the references.
This fixes `spec@!opengl 1.1@longprim`.
Fixes: b3133e250e ("gallium: add pipe_context::resource_release to eliminate buffer refcounting")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40642>
The TEST_ONLY flag lets you run your display configuration past the driver
to see if it exceeds any of the many arbitrary hardware limits that can't
be expressed through the limited properties that DRM exposes. This maps
quite well to VK_ERROR_INITIALIZATION_FAILED.
Fixes dEQP-VK.wsi.direct_drm.colorspace.basic failure on my anv CFL
system, where we exceeded the primary plane's width restriction for the
specific tiling format chosen.
Closes: #14314
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39466>
The state we return is a single plane per connector, and (effectively)
whether we're currently presenting on it. We already know what connectors
we're presenting on, and there's no reason to re-probe for hotplugged
connectors here to learn that they're not active --
vkGetPhysicalDeviceDisplayProperties2KHR() is what you'd need to do to get
far more important information about the connector in the first place.
Running dEQP-VK.wsi.direct_drm.maintenance1.present\* on my CFL goes from
5.5s to 4.4s due to not re-probing EDID over and over.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39466>
Ian Romanick reported some "undefined behaviour" warnings during some
not specified tests, relating to introduction of RGB[A}16_UNORM formats
in merge request
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38588
This due to overflowing the 32-bits masks[], and then during assignment
the red/green/blue/alphaMask fields in struct gl_config when using a 16
bpc format. Iow. the red/green/blue/alphaMask would not be usable.
Suppress this warning by setting masks[] to zero for unorm16 formats,
just as was previously done for is_float16, ie. fp16 formats.
16 bpc formats are only exposed for display on non-X11 WSI target
platforms like GBM+DRM, Wayland, surfaceless, and these platforms do
not use the info in red/green/blue/alphaMask at all, so the "undefined
behaviour" is meaningless.
Fixes: f2aaa9ce00 ("dri,gallium: Add support for RGB[A]16_UNORM display formats.")
Reported-by: Ian Romanick @idr
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40695>
From the OpenCL specification, `clCreateSubBuffer` should return:
`CL_MISALIGNED_SUB_BUFFER_OFFSET` if there are no devices in
`context` associated with `buffer` for which the `origin` field of
the `cl_buffer_region` structure passed in `buffer_create_info` is
aligned to the `CL_DEVICE_MEM_BASE_ADDR_ALIGN` value.
This was previously unhandled in the entrypoint, marked as TODO.
Add two functions to `Device` for querying the address alignment in
both bits and bytes, for convenience. Properly retrieving the
alignment value from the underlying device/screen is still marked as
TODO.
Signed-off-by: Ahmed Hesham <ahmed.hesham@arm.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40726>
The extension is implemented in shared Vulkan/WSI code and
not driver specific. The underlying kms driver needs to
support HDR metadata signalling on the drm connector, which
vc4 kms does for VideoCore 5 and later since April 2021.
Successfully tested on RaspberryPi 4/400 with a HDR-10
capable HDMI monitor.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40696>
These extensions are implemented in shared Vulkan/WSI code and
not driver specific. A Vulkan driver just needs to support
VK_KHR_timeline_semaphore, which v3dv already supports via
emulated timeline semaphores since April 2022.
Successfully tested on RaspberryPi 4/400.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40696>
Turnip has supported virtio for some time, and KGSL support for the
gallium driver is no longer planned, point users to zink instead.
Also document the WSL backend.
Acked-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40302>
Now that zink can be built without a hard dependency on libdrm by using
the 'software' dri_platform, we can enable EGL, GLX, and the associated
window system platforms (X11, Wayland) in the debian-no-libdrm build job.
Acked-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40302>
Use with_gallium_drm instead of with_gallium_kmsro for the Turnip
libdrm-linking warning. This avoids incorrectly forcing a link to libdrm
when zink is enabled in a KGSL-only build.
Also update the warning to match the others.
Acked-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40302>
Rename the 'hurd' dri_platform to 'pseudo-drm' to represent non-DRM
presentation platforms.
This platform is now also enabled when building zink and Turnip with the
KGSL backend, allowing zink to use Kopper.
Acked-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8634
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40302>
This will allow for building and running zink on systems without libdrm
by using Mesa's internal stubs.
Acked-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40302>
drmGetNodeTypeFromFd and drmGetRenderDeviceNameFromFd will be used in
EGL.
Acked-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40302>
