this removes the hardcoded count of 5 mem blocks to cache and replaces
it with a value that's based on the number of allocations seen
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11594>
this doesn't seem to be a real issue now that tc doesn't break makeCurrent
anymore, but if such a thing were to once again become a problem, at least
there will be handling for it
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11437>
this uses a pointer to a batch state substruct for timeline tracking,
which provides a few nice benefits:
* explicit ability to detect unflushed batches (even on other contexts)
* the context doesn't need to have a "current" timeline id
* timeline (batch) ids can be distributed during submit, not when recording begins
* an abstracted api which can be more easily changed under the hood
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11437>
the visible vram heap is potentially going to be limited in size, so avoid
caching these allocations since that locks them to a given allocation size
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11397>
* buffers can use normal mem prop checking to determine host_visible setting
* sparse buffers are never coherent, so this case can be dropped from the conditional
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11397>
Buffers are created without a format in Vulkan, and we always pass in
R8_UNORM for them in Gallium. It's the view-formats we should have
checked, if anything.
But that's orthogonal to this. We shoudn't keep checking R8_UNORM
capabilities for buffers, all it's going to do is trigger asserts.
Fixes: 00dc0036b ("zink: flatten out buffer creation usage flags codepath")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11416>
We already set this bit unconditionally right before, no point in
repeating it.
Fixes: 00dc0036b ("zink: flatten out buffer creation usage flags codepath")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11416>
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>
Add a moltenvk-dir build option to supply the MacOS Vulkan SDK MoltenVK location.
Force compiler, for zink only, into object-c mode when MoltenVK is used to allow for the MacOS ioSurface and CAMetalLayer types that the headers expose.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11129>
have_moltenvk was moved to a different location but code being protected in platform specific guard, so was unnoticed.
Fixes: 598dc3dca4 ("zink: use cached memory for all resources when possible")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11129>
OpenGL allows reinterpreting 2D array textures as cubemaps,
so we need to always set the cube-compatible flag for them.
This fixes a piglit test on Lavapipe.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10913>
We need to check if the number of samples are valid for the image
first if we've going to set the cube-compatible bit.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10913>
The u_resource_vtbl indirection is going to be removed.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10659>
nvidia claims format feature support for various flags but then doesn't
actually support them for a 3D image, only 2D, meaning that an extra step
is necessary before creating a linear image
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10823>
when emitting barriers, we don't need to end the renderpass in some cases
this handles the case of emitting barriers for new resources which have
never before been accessed and thus do not require synchronization at a
specific point in the batch
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10700>
this breaks the driver!
the uploader always maps its own pointer, so modifying that at any
point just explodes things later
Fixes: d179c5d28e ("zink: implement threaded context")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10787>
sparse buffers are not cpu-readable, so any mapping requires that they
use a staging buffer, either the stream uploader for writes or a manual
copy for readback
future work here should attempt to resolve two perf issues:
* sparse allocations should be allocated dynamically using a suballocator
or some other, more useful strategy
* readback shouldn't allocate a huge staging buffer
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10509>
I think at one point before staging resource flagging was less reliable
this method made sense, but now it's worse
Fixes: 6ff6d01c37 ("zink: don't use cached mem for staging resources")
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10363>
