Even though we can't really do the parsing on behalf of the driver (it's
too complicated), storing it in the vk_image lets us provide a common
implementation of vkGetImageDrmFormatModifierPropertiesEXT(). It'll
also be useful in the next few commits for swapchain images.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12023>
It doesn't make sense to ask for the depth-only or stencil-only format
if there is no depth or stencil. One bit of radv_image.c did seem to
take advantage of the default case in vk_format_depth_only so throw an
`if (vk_format_has_depth(format))` around it.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12023>
Currently, this is optional for drivers to carry around but it scrapes
up most of VkImageCreateInfo for you and parses a couple of extension
structs. We also add a few useful little helpers copied over from ANV.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12023>
In theory, with linear vs. tiled differences, it could be different
(RGBA vs. RGB etc.) but it won't matter for the two checks we do with
it. Also, we probably want to be checking the real format here anyway.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12023>
Using suites makes load-balancing our jobs much easier, keeps the CPU busy
handling the a630_gles_others.sh test sets (and improves the output and
baseline handling for them), and makes it trivial to add in more short
test sets.
a306: still 5 jobs, and we add KHR-GLES2 (KHR-GLES3 is unstable)
a530: still 5 jobs, added KHR-GLES*
a630_gl: 5 jobs becomes 4, and we add KHR-GLES*
a630_vk: still 3 jobs, now 1/3 of all VK instead of 1/4.
a630_vk_full: still 2 jobs, now includes full bypass testing, partial
no-force testing, and testing of pre-merge-skipped tests.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12256>
DONTBLOCK is only used internally for this case, and promoting it over
the staging buffer case ensures that it's always reached when it should be
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12410>
buffers should only be unmapped if they're explicitly marked for unmap,
but images should only be unmapped when running in 32bit, in which case
they need to always be unmapped
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12410>
We were adding them if there was an external dep instead of if there
wasn't, and we were skipping the entire subpass which would've resulted
in attachments not getting marked as used.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12386>
Doesn't fix, but improves the situation in issue #5163. The
VK.spirv_assembly.instruction.graphics.spirv_ids_abuse.lots_ids_* tests
emit about 160k instructions. ir3_sched blows out the stack after
dag_traverse_bottom_up_node reaches a depth of about 130k frames.
This patch replaces the recursively-implemented post-order traversal
with an iterative implementation using a stack, allowing us to process
DAGs as large as memory can hold.
Definitely makes you appreciate the elegance of recursion...
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12232>
The OpenGL ES 2.0 (and later) specifications, section 2.13 (Primitive
Clipping) say the following about point-clipping:
> If the primitive under consideration is a point, then clipping
> discards it if it lies outside the near or far clip plane; otherwise
> it is passed unchanged.
This matches the D3D convention, and we already have a rasterizer-state
bit for it. So let's set that bit when the API is OpenGL ES 2.
We can set this inside the PointSprite-conditional block, because that's
always enabled on GLES 2, and it's undefined to enable this state
without also enabling point_quad_rasterization.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12350>
When I updated this code for multi-sampling, I missed one detail; if we
want to be able to support pipe_rasterizer_state::point_tri_clip, we
need to use the intersection of the bbox (clipped to the viewport
rectangle) and the generated primitive, otherwise we won't end up doing
x/y viewport clipping at all.
Because we've adjusted some of the parts of the bbox when adjusting for
inclusiveness/exclusiveness and fill-rule, we also need to reverse the
adjustment.
Fixes: f530e72ea0 ("llvmpipe: do not always use pixel-rounded coordinates for points")
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12350>
This is mostly a bit of future-proofing. We never end up with offsets
that don't fit in 32 bits today because, thanks to driver limitations
caused by relocations, we don't allocate buffers bigger than 2GB today.
However, if we ever did, it's possible to create a surface on modern
platforms that consumes more than 4GB and we would end up with wrapping
in our offset calculations.
Acked-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11765>
The docs weren't updated when we switched it to 4D. Also, the new docs
are way better. While we're here, use the parameter name offset_B to be
more consistent.
Acked-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11765>
This makes things a bit more clear.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Acked-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11765>
The only user of this case is iris which initializes offset_B to 0 so
there's no real bug here. However, it is unexpected from an API PoV.
Fixes: 9946120d2b "intel/isl: Add more cases to isl_surf_get_uncompressed_surf"
Acked-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11765>
this is an aux/pipebuffer implementation borrowing heavily from the
one in radeonsi. it currently has the following limitations, which
will be resolved in a followup series:
* 32bit address space still explodes
* swapchain images still have separate memory handling
performance in games like Tomb Raider has been observed to increase by
over 1000%
SQUASHED: simplify get_memory_type_index()
now that the heaps are enumerated, this can be reduced to a simple
array index with a fallback
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12146>
Enable CI for lima again on meson-gxl-s805x-libretech-ac boards
with Mali-450.
These boards are managed by a LAVA instance and so follow the LAVA CI
workflow in Mesa.
The goal is to have coverage for deqp-gles2, as lima is a GLES2-only
driver.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11789>
Currently stride, offset, modifier is obtained by invoking
lima_resource_get_handle() with WINSYS_HANDLE_TYPE_KMS.
Before commit 47f000c170 this path was working. Obtained handle
was simply ignored by DRI frontend and only requested data used.
After commit 47f000c170 such requests started to fail when
DRI is initialized using KMSRO and resource has no scanout data.
When lima_resource_get_param() is implemented, it will be used in
a first place to obtain resource data.
Fixes: 47f000c170 ("lima: fail in get_handle(TYPE_KMS) without a scanout resource")
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12362>
