From the Vulkan documentation, the queueFamilyIndex value will be
created with VkDeviceQueueCreateInfo. So let's avoid counting the
index value and just refer to the already-created value.
This will resolve crashes on some GPUs for various workloads.
v2: Needed to use GetDeviceQueue() in order to map the queueFamilyIndex
values. These values can be different when obtaining the queue used
for presentation, so we need to ensure we update the mapped
queueFamilyIndex value for the associated queue_data struct.
Signed-off-by: Casey Bowman <casey.g.bowman@intel.com>
Reviewed-by: Felix DeGrood <felix.j.degrood@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33487>
The mesa screenshot layer attempts to use VK_FORMAT_R8G8B8_UNORM by
default. Using this, we can directly & efficiently write out to a
PNG file without further modifications. However, some GPUs don't
support the given format, so for those that don't, we'll attempt to
use VK_FORMAT_R8G8B8A8_UNORM, which will require some work to ensure
the alpha values are set to opaque to make RGB comparisons easier.
If both surface formats fail, a more descriptive failure
will be shown.
Signed-off-by: Casey Bowman <casey.g.bowman@intel.com>
Reviewed-by: Felix DeGrood <felix.j.degrood@intel.com>
Reviewed-by: Karmjit Mahil <karmjit.mahil@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33295>
Adds an optional region selection, based off percentages of the
starting/ending of an image's X & Y values.
This is intended as a performance enhancement tradeoff for smaller
images to be created.
With a smaller image size, the screenshotting layer will change the
region boundaries on the GPU side, which will decrease the amount of
time it takes to copy the image over to CPU-accessible memory.
Using vkcube as an example, the original image size is 500x500:
mesa-screenshot: DEBUG: Screenshot Authorized!
mesa-screenshot: DEBUG: Needs 2 steps
mesa-screenshot: DEBUG: Time to copy: 123530 nanoseconds
Then, by cropping the area to a 100x100 image, we get the following:
mesa-screenshot: DEBUG: Screenshot Authorized!
mesa-screenshot: DEBUG: Using region: startX = 40% (200), startY = 40% (200), endX = 60% (300), endY = 60% (300)
mesa-screenshot: DEBUG: Needs 2 steps
mesa-screenshot: DEBUG: Time to copy: 12679 nanoseconds
For this example, this is a ~90% time reduction improvement!
Overall, this option reduces the copy time to a point where it can
become negligible, relative to the frame time of the application.
Signed-off-by: Casey Bowman <casey.g.bowman@intel.com>
Reviewed-by: Felix DeGrood felix.j.degrood@intel.com
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32016>
Reduced the looping copy structure of a 2D array down to a single malloc
& memcpy operation to copy the entirety of the image buffer to a local
1D array copy.
With this setup, we can write the image row by row using the associated
libpng API call.
Local testing with vkcube showed ths as a large perf gain, reducing the
time it took to copy images by more than half:
Previous method:
mesa-screenshot: DEBUG: Time to copy: 251907 nanoseconds
Current method:
mesa-screenshot: DEBUG: Time to copy: 112904 nanoseconds
Also reduced swapchain image list malloc operations to one use. This
doesn't have much perf impact, but it's good to reduce the number of malloc
operations overall.
Signed-off-by: Casey Bowman <casey.g.bowman@intel.com>
Reviewed-by: Felix DeGrood <felix.j.degrood@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31793>
This frees a fairly large amount of memory from the 2D matrix by
iterating over the rows to free them individually.
Liuqiang spotted some areas that we return early in the threaded
function and don't free some pointers.
To remedy this, we'll reorder the checks so that we don't have to
return early and can instead use an if/else flow to take care of
these problematic areas in a more elegant way.
Co-authored-by: Casey Bowman <casey.g.bowman@intel.com>
Co-authored-by: liuqiang <liuqiang@kylinos.cn>
Reviewed-by: Felix DeGrood <felix.j.degrood@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31793>
This allows larger buffer sizes when using the env config as well
as filepath for the output directory.
This will allow, for example, using a large number of singular frames:
frames=1/2/3/4/5/6/7/8/.../300
Also fixed an issue with filepaths sometimes being appended with garbage
characters due to not being initialized.
Signed-off-by: Casey Bowman <casey.g.bowman@intel.com>
Reviewed-by: Felix DeGrood <felix.j.degrood@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31793>
Previously, only the first image in the swapchain was chosen at all times
to be copied to a file.
This meant that if a list of consecutive images were selected, multiple
duplicate images would be saved, instead of the proper frames actually
used in the workload.
Now, the index is properly obtained from AcquireNextImageKHR(), leading
to the same image being used for the workload to be copied and saved to
a file.
Signed-off-by: Casey Bowman <casey.g.bowman@intel.com>
Reviewed-by: Felix DeGrood <felix.j.degrood@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31793>
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>
