From the perspective of the gpu, host read or host write has the same
implication (gpu cache flush) in the dst access flags. We should
include host write in the dst access flags.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32102>
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>
Avoids sanitizer errors like:
```
../src/intel/vulkan/anv_pipeline_cache.c:406:4: runtime error: null pointer passed as argument 1, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:406:4: runtime error: null pointer passed as argument 2, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:417:4: runtime error: null pointer passed as argument 2, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:435:4: runtime error: null pointer passed as argument 1, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:435:4: runtime error: null pointer passed as argument 2, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:439:4: runtime error: null pointer passed as argument 1, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:439:4: runtime error: null pointer passed as argument 2, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:443:4: runtime error: null pointer passed as argument 1, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:443:4: runtime error: null pointer passed as argument 2, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:447:4: runtime error: null pointer passed as argument 1, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:447:4: runtime error: null pointer passed as argument 2, which is declared to never be null
```
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32098>
This is required, otherwise we regress latency in cases where
applications are using FIFO without explicit KHR_present_wait.
This is an unacceptable regression.
The fix is to normalize the behavior to X11 WSI.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Fixes: d052b0201e ("vulkan/wsi/wayland: Use fifo protocol for FIFO")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32029>
Instead of using frame callbacks - which may stop firing if our surface is
occluded - use the new commit-timing-v1 protocol in combination with the
presentation feedback protocol.
If the required protocols are unavailable, or the environment variable
MESA_VK_WSI_DEBUG contains "nowlts", we fall back to frame callback
based pacing behaviour.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26150>
The fifo protocol allows us to ensure that a compositor presents
an image that we submit to it. Use this to reliably implement FIFO
semantics.
Note: On systems where the fifo protocol is available an occluded
surface may find itself unthrottled when previously it would have
been frozen.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26150>
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>
Perfetto is allowed to choose it's own default clock, and before this we just assumed the presentation times reported by the compositor are the same as perfetto's internal clock, which is not always the case. I got a nasty trace where all the wayland presents were in the wrong location. This fixes that by asking the compositor which clock it uses, then passing that along to perfetto.
A workaround for my compositor was setting use_monotonic_clock=true in the perfetto config, as my compositor (and I suspect most others) use the monotonic clock for presentation timestamps. However, asking the compositor is definitely the most correct solution.
I added a clock param to `MESA_TRACE_TIMESTAMP_{BEGIN,END}`, as it's only use that I could see was in wsi_common_wayland, and in general it seems good to be careful about which clock tracing timestamps come from.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31779>
Tilers need to know, at the very least, which input attachments are
"real" input attachments which map to a color or depth/stencil
attachment in tile memory and which are "fake" input attachments that
should be treated as regular textures. To do this we need to know
VkRenderingInputAttachmentIndexInfoKHR::colorAttachmentCount, which
wasn't provided by the state tracking infrastructure. When the
VkRenderingInputAttachmentIndexInfoKHR isn't provided, we don't know it,
though, so we have to record a special UKNOWN value. In that case, the
driver will know thanks to
VUID-VkGraphicsPipelineCreateInfo-renderPass-09652 that all input
attachments are "real" input attachments that map directly to color
attachments if they have an InputAttachmentIndex.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31261>
