Switch to using FourCC for buffer allocations instead of
DRI_IMAGE_FORMAT, albeit with a transient helper to convert from FourCC
to DRI_IMAGE_FORMAT for createImage.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30245>
There's no real reason for the two to exist separately. Nuke the old
createImage in favour of just having createImageWithModifiers.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30245>
This is the last user of the old createImageFromName entrypoint; use
createImageFromNames instead, which involves converting to using FourCC
and also a byte rather than pixel stride.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30245>
Instead of looking up a mesa_format from a DRI_IMAGE_FORMAT, then
looking up the internal format from there, just go directly from A to B.
Inspired by an unmerged commit from Emma Anholt.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30245>
They're calling the same thing in the backend, just merge the impls. We
don't need to maintain the old function and struct layout, because we're
version locked between loader and driver.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30245>
They're calling the same thing in the backend, so reduce the proliferation
of interfaces consumed within our implementation.
driVkImageExtensionSw now sets dri2_from_dma_bufs, which means that
egl_dri2 will now expose EXT_image_dma_buf_import. Given that it
previously set dri2_from_fds suggesting that it can import dmabufs, this
is presumably OK.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30245>
... and rename createImageFromRenderbuffer2() to be it. We don't need to
maintain the old function and struct layout, because we're version locked
between loader and driver.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30245>
When using the ancient DRM-buffer extension, use createImageFromNames
instead of createImageFromName, so we can deprecate the latter.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30245>
The hashtable stores a hash generated from the key, so there is no need
to duplicate the key, as otherwise it is a leak.
Found through address sanitizer.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
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/30204>
Also optimize the denorm scaling path by only emitting the expensive trans op once
and allowing fma for the final muliplication.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29245>
We were generating odd instructions like:
math inv(8) g93<1>HF g85<8,8,1>HF null<8,8,1>F { align1 1Q @7 $4 };
It's unclear whether the type of the null operand matters, but sometimes
these things don't get ignored properly. Out of caution, retype the
null source to match the actual operand's type. It'll at least look
less surprising in assembly dumps.
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30193>
We had some helpers for this at one point but the old ones were super
clunky and didn't really do what we wanted so they were removed.
However, we have a lot of manual banging in opt_copy_prop and we're
about to add more. These new helpers will make it all a lot safer.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30230>
