Before we can fix big endian, we kind of have to agree on how pixel data
should be laid out in memory.
For this we have to use packed data for !is_array declared formats and per
element values for is_array ones.
Also we need proper PACKED_1xn definitions for BE.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7776>
There is no point in having a write to an attachment enabled when there
is no corresponding output in the shader. Per VK spec it is an UB,
however a few apps depend on attachment not being changed if FS doesn't
have corresponding output.
Fixes water in Genshin Impact.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10489>
The idea behind this assert is that if a buffer is in
bufmgr->handle_table it's because it has been shared from i965 to the
outside. This is when we add the drm FD associated to this BO to
bo->exports.
But we also import buffer from the outside into i965 and those buffers
don't have an associated drm FD added to bo->exports.
If you import the same buffer more than once, you'll run into this
assert.
v2: Also drop assert from brw_bo_gem_create_from_name() (Ian)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 57e4d0aa1c ("i965: fix export of GEM handles")
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10386>
For GL, we've previously mostly ignored the binding property for sampler variables
during the shader compilation step. For CL, our image bindings were always 0-based as well.
Now, for Vulkan, we are going to be getting explicit bindings and need to emit DXIL that
respects those bindings. Since Vulkan can also have both split and combined images and samplers,
we now need to be smarter about recognizing when NIR is trying to use a "sampler" as *both* an
image and sampler (in deref mode, the same variable will be deref'd as both image and sampler).
That "being smarter" bit comes next, but first, let's prep GL for building correct root
signatures and binding the resources correctly.
Reviewed-By: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10298>
Currently, a resized window results in an VK_ERROR_OUT_OF_DATE_KHR. But,
this seems to go against the spec, which suggests returning
VK_SUBOPTIMAL_KHR if the surface extent no longer matches the window
extent. (It does not *require* the WSI actually scale the contents, only
encourages doing so "if possible")
More to the point, VK_SUBOPTIMAL_KHR is the correct status to return if
the client *can* continue presenting to this swapchain, even if the
result will look wrong / "suboptimal". It's the client's decision on
when exactly to recreate the swapchain in this case, and the client may
very well end up wanting to continue presenting for a frame or two, to
prevent flooding the driver with swapchain recreations (which can result
in the window appearing visually "frozen" while resizing).
This change makes live resizing *significantly* smoother in e.g. mpv.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3196>
If the swapchain already does not match the current geometry at the time
of creation, set the initial status to VK_SUBOPTIMAL_KHR as a way to
inform clients to please resize the swapchain.
This solves a race condition where users have no way of knowing if the
surface extent changed in between the user querying the current extent
and creating the swapchain, and might end up missing a resize event
because of it, since XCB_PRESENT_CONFIGURE_NOTIFY is not yet being
handled.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3196>
This is similar to the transcode_etc flag in that it changes the ASTC
fallback (when present) to use DXT5 instead of RGBA8888. This reduces
the memory footprint of the app at the expense of a bit of correctness.
Because it's not quite correct, it's hidden behind a driconf option.
Reviewed-by: Eric Anholt <eric@anholt.net>
Acked-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10476>
Fixes a double-free in dEQP-VK.wsi.display_control.register_device_event
where the fence that we destroyed got destroyed again. Leaving it unset
in the error path leaves the test's NULL in place.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10473>
I mixed up the EXT and ARB version of the extensions; we actually do
require shaderStorageImageWriteWithoutFormat as well here.
Thanks to Ilia Mirkin for pointing this out.
It also seems I got really confused about what was required when writing
the docs, so let's fix that as well.
Fixes: 341332b23a ("zink: correct image cap checks")
Fixes: ecac7f3da1 ("docs: add missing zink-requirement")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10463>
Sometimes, there's a surplus of semicolons, and there's enough to go
around for everyone. So maybe you'll save a few away for later. But in
the big pictures, it seems better to get rid of these so we don't
overrun the semicolon quota.
Or whatever, I'm just cleaning up here.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10466>