mirror of
https://github.com/baldurk/renderdoc.git
synced 2026-05-04 17:10:47 +00:00
baldurk
101 lines
5.4 KiB
XML
101 lines
5.4 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
|
<topic id="b08af848-7c58-4ff4-9a2a-6bb5cfb0b037" revisionNumber="1">
|
|
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
|
|
<introduction>
|
|
<para>
|
|
This page documents the support of Vulkan in RenderDoc. This gives an overview of
|
|
what RenderDoc is capable of, and primarily lists information that is relevant. You might also
|
|
be interested in the <link xlink:href="86b8bce7-b7cd-4b10-aa61-706463d14fe0">full list of features</link>.
|
|
</para>
|
|
<para>
|
|
The latest information and up-to-date support is always available on the
|
|
<externalLink>
|
|
<linkText>GitHub wiki</linkText>
|
|
<linkAlternateText>Vulkan wiki page on GitHub</linkAlternateText>
|
|
<linkUri>https://github.com/baldurk/renderdoc/wiki/Vulkan</linkUri>
|
|
</externalLink>.
|
|
</para>
|
|
</introduction>
|
|
<section address="Layer">
|
|
<title>Vulkan capture</title>
|
|
<content>
|
|
<para>
|
|
RenderDoc's Vulkan support uses the sophisticated layering mechanism built into the Vulkan
|
|
API. This means that once RenderDoc has registered its capture layers, there is no need
|
|
for invasive process hooking - we can simply launch the target process with an environment
|
|
variable set.
|
|
</para>
|
|
<para>
|
|
The one requirement of this however is that the layer does need to be registered in an OS
|
|
specific way - on windows this is in the registry, on linux this is in an /etc folder. That
|
|
way the Vulkan loader can scan and initialise the layer.
|
|
</para>
|
|
<para>
|
|
Usually this will happen for you if you install RenderDoc with a proper installer, or update
|
|
from a previous version. However if you are compiling RenderDoc yourself or running a loose
|
|
unzipped build, the capture panel will show a warning indicating that the layers need to
|
|
be registered. Just click this and the registration will be applied.
|
|
</para>
|
|
<para><mediaLink><image xlink:href="LayerRegistration"/></mediaLink></para>
|
|
</content>
|
|
</section>
|
|
<section address="Performance">
|
|
<title>Performance notes</title>
|
|
<content>
|
|
<para>
|
|
Vulkan is intended as a high-performance low CPU overhead API, and RenderDoc strives to
|
|
maintain that performance contract at a reasonable level. While some overhead is inevitable
|
|
RenderDoc aims to have no locks on the 'hot path' of command buffer recording, minimal or
|
|
no allocation, and in general to have low performance overhead while not capturing.
|
|
</para>
|
|
<para>
|
|
Some patterns of access are more or less conducive to good performance on RenderDoc, so
|
|
if you are having trouble with slow capture, large memory/disk overhead or slow replay you
|
|
might want to try eliminating use of persistent maps of memory from coherent heaps - you
|
|
can use vkFlushMappedMemoryRanges to emulate non-coherent heaps and RenderDoc will take
|
|
advantage of that, or you can use non-persistent maps.
|
|
</para>
|
|
<para>
|
|
Likewise try to avoid making very large memory allocations in the range of 1GB and
|
|
above. By its nature RenderDoc must save one or mor copies of memory allocations to enable
|
|
proper capture, so having allocations limited to only a few 100s of MBs can help gain
|
|
granularity of management and limit the memory overhead RenderDoc adds. There may be
|
|
optimisation of this in future on RenderDoc's side but there are no easy guarantees.
|
|
</para>
|
|
</content>
|
|
</section>
|
|
<section address="Features">
|
|
<title>Current support</title>
|
|
<content>
|
|
<para>
|
|
RenderDoc has initial support for Vulkan at the launch of version 1.0, but it contains some
|
|
caveats. In addition, not all replay features are currently supported, but this is being
|
|
actively worked on.
|
|
</para>
|
|
|
|
<list class="bullet">
|
|
<listItem><para>RenderDoc assumes that even if multiple GPUs are present, that only one VkDevice and one
|
|
VkQueue will be created and used.</para></listItem>
|
|
<listItem><para>RenderDoc captures will in general not be portable between different systems, only currently
|
|
supporting capture and replay on the same or similar enough machines.</para></listItem>
|
|
<listItem><para>Sparse textures are only supported for non-arrayed 2D textures with no mips.</para></listItem>
|
|
<listItem><para>Pixel history is not implemented.</para></listItem>
|
|
<listItem><para>Shader debugging is not currently supported.</para></listItem>
|
|
<listItem><para>Edit-and-continue of shaders and custom visualisation shaders are not supported.</para></listItem>
|
|
<listItem><para>Mesh output of geometry/tessellation shader stages is not available.</para></listItem>
|
|
</list>
|
|
</content>
|
|
</section>
|
|
<section address="Linux">
|
|
<title>Non-windows platforms</title>
|
|
<content>
|
|
<para>Linux and other platform support follows naturally when thinking about Vulkan support. Currently
|
|
there is full support for capturing and replaying on linux, however the Qt UI is still
|
|
heavily work in progress.</para>
|
|
</content>
|
|
</section>
|
|
<relatedTopics>
|
|
<link xlink:href="86b8bce7-b7cd-4b10-aa61-706463d14fe0" />
|
|
</relatedTopics>
|
|
</developerConceptualDocument>
|
|
</topic> |