If the pipeline is created with no
VkPipelineSampleLocationsStateCreateInfoEXT, but
VK_DYNAMIC_STATE_SAMPLE_LOCATIONS_ENABLE_EXT is set, we end up
dereferencing a NULL pointer.
Fixes future dEQP-VK.pipeline.*.extended_dynamic_state.*.sample_locations_enable_no_create_info
Fixes: 1deb83fb86 ("vulkan: Add more dynamic multisample states")
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31377>
Per description of VkPipelineShaderStageCreateFlags
```
VK_PIPELINE_SHADER_STAGE_CREATE_REQUIRE_FULL_SUBGROUPS_BIT specifies
that the subgroup sizes must be launched with all invocations active in
the task, mesh, or compute stage.
```
Future CTS tests will use that.
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31023>
this existed for historical reasons, but realistically now it should
be possible to build mesa with dri3 always enabled. additionally,
this check was often used as a substitute for having drm functionality,
which is sort of similar but also not really a direct match
this simplifies a bunch of conditionals and prevents users from footgunnning
themselves into orbit
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30952>
This change adds a Vulkan screenshot layer that allows users to take
screenshots from a Vulkan application, but has an emphasis on
performance, decreasing the performance impact on the application
involved. This allows for automated setups to use this layer to take
screenshots for navigating various in-application menus.
This layer works by hooking into various common Vulkan setup functions, until
it enters the vkQueuePresentKHR function, and from there it copies the current
frame's image from the swapchain as an RGB image to host-cached memory, where
we will receive the information as a framebuffer pointer. From there, we copy
the framebuffer contents to a thread that will detach from the main process
so it can write the image to a PNG file without holding back the main thread.
This layer was created from using the existing overlay layer as a template,
then adding portions of LunarG's VulkanTools screenshot layer:
https://github.com/LunarG/VulkanTools/blob/main/layersvt/screenshot.cpp
More specifically, there were usages of functions, along with modifications of
various functions from screenshot.cpp in the VulkanTools project, used in
screenshot.cpp.
There are some sections of the screenshotting functionality that remain
unmodified from the original screenshot.cpp file in VulkanTools, including the
global locking structures and the writeFile() function, which takes care of
obtaining the images from the swapchain. There were various areas in which
modifications were made, including how images are written to a file (using PNG
instead of PPM, introducing threading, added fences/semaphores, etc), along
with many smaller changes.
v2: Fix segfault upon application exit
v3: Fix filename issue with concatenation, along with some leftover
memory handling that wasn't cleaned up.
v4: Fix some error handling and nits
v5: Fix output directory handling
Reviewed-by: Ivan Briano <ivan.briano@intel.com
Signed-off-by: Casey Bowman <casey.g.bowman@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30527>
VK_KHR_dynamic_rendering_local_read allows the application to sample
from a subpass input attachment where this attachment is also the color
attachment (aka. feedback loop). With legacy RPs, it's easy to detect
that at RP creation time by looking at the input<->color indices but
with DRLR this needs to be determined dynamically.
This flag would help when legacy RPs are converted to dynamic rendering
because it's not possible to know if a subpass used input attachments.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30124>
Add buffer copy/fill/update helpers using compute shaders. The driver
can select the optimal per-workgroup copy/fill/update size by specifying
a non-zero vk_meta_device::buffer_access::optimal_size_per_wg size.
If zero, the core will assume a 64-byte size (the usual cache-line size).
Buffer accesses will be done through SSBOs unless
vk_meta_device::buffer_access::use_global_address is true, in which
case the core will the buffer address using GetBufferDeviceAddress()
and pass that address as a push constant to the compute shader.
Image to buffer copies are always done through a compute shader. The
optimal workgroup size will be chosen based on
vk_meta_copy_image_properties::tile_size: the copy logic picks a
workgroup size matching the tile size, and aligns accesses on a tile.
The view format is selected by the driver. To optimize things on the
shader side, pick UINT formats (usually less work to do to pack data).
Buffer to image copies can be done done through the graphics pipeline
if needed (use_gfx_pipeline passed to vk_meta_copy_buffer_to_image()),
which is useful for vendor-specific compressed formats that can't be
written outside of the graphics pipeline. Drivers should normally prefer
compute-based copies when that's an option. Just like for image to buffer
copies, the workgroup size of compute shaders is picked based on the
image tile size, and the view format must be selected by the driver.
Image to image copies is just a mix of the above, with the driver being
able to select the pipeline type, as well as define the tile size and
view format to use. When using a compute pipeline, the workgroup size
will be MAX2(src_tile_sz, dst_tile_sz), and accesses will be aligned
on the selected reference image.
For compressed formats, the caller should pick an RGBA format matching
the compressed block size.
Co-developed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29333>
Faith Ekstrand