KHR_get_memory_requirements2 was enabled but GetImageMemoryRequirem
ents2 was not. This stubs out GetImageMemoryRequirements2 to fix it.
Signed-off-by: Yusuf Khan <yusisamerican@gmail.com>
v2: remove the v1 version of the command as its provided by the
common runtime
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
vulkan spec says:
If the memory object is allocated from a heap with the
VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT bit set, that object’s
backing memory may be provided by the implementation lazily. The
actual committed size of the memory may initially be as small as
zero (or as large as the requested size), and monotonically
increases as additional memory is needed.
As far as I can tell we ignore the bit meaning that we allocate the
requested size so return that as the size.
Signed-off-by: Yusuf Khan <yusisamerican@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
This values was found by trial-and-error poking at the hardware until it
stopped complaining. It's not clear if we need separate values for
compressed vs. not. This appears to work on Turing regardless of what
we set for SET_Z_COMPRESSION.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
The bits are already in the table we copied from the nouveau GL drivers,
we just need to set up some enums and plumb it through. With that,
we're now properly advertising which formats are renderable.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
Also, add a helper for depth/stencil formats and use
nil_format_supports_color_targets() helper to compute Vulkan format
features rather than checking for a non-zero color format.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
Annoyingly, with the current uAPI, this requires creating a dummy
context and throwing it away. Fortunately, we should only do this once
on driver load so it's really not that big a problem.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
IDK if NVIDIA hardware even supports setting sample locations. I've not
been able to find the packets. In any case, if and when we implement
the extension, we can wire it up then.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
fixes a bunch of these
nv50_ir_lowering_nvc0.cpp:2878: void nv50_ir::NVC0LoweringPass::handleLDST(nv50_ir::Instruction*): Assertion `prog->getType() == Program::TYPE_TESSELLATION_CONTROL' failed.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
This is unlikely but can happen if you have the following sequence:
1. vkCmdSetScissors()
2. No pipeline bind
3. vkCmdClearImage() which causes a meta save
4. Meta restore with vk_cmd_set_dynamic_graphics_state()
In that case, we don't have scissor counts but need to restore the
scissors set with `vkCmdSetScissors()` before the meta save. We can
safely copy all of them, it's just more memory traffic than maybe we'd
like. Fortunately, this can only happen at the start of a command
buffer and only with a fairly silly sequence of commands.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24326>
