Hash :
fc4fc174
Author :
Date :
2024-12-10T22:01:28
Vulkan: Prevent crash with D/S FF without D/S attachment The spec says that the values for gl_LastFragDepth/StencilARM are undefined if there is no depth/stencil attachment. This "just" works on tiling GPUs, because reading input attachments simply translates to reading _something_ from the tile memory. For ANGLE, the situation is a little more complicated. ANGLE has to bind descriptors for input attachments (because non-tilers read from the input attachment descriptor instead of using the knowledge that input and color/depth/stencil attachments are one and the same thing in tile memory). When a depth/stencil attachment is missing, there is no image to bind to the descriptor set. ANGLE cannot skip binding an image to the descriptor set, because OpImageRead (translated from subpassLoad()) attempts to access the input descriptor; skipping this causes an internal crash in SwiftShader for example. ANGLE cannot bind a bogus image as input attachment, as Vulkan requires that input attachments are also color/depth/stencil attachments. ANGLE _could_ bind a bogus image as input attachment and also as depth/stencil attachment. This is rather risky, as it then also has to be careful to make sure that depth/stencil attachment is never actually used (i.e. it affects the depth/stencil state, load/store ops etc). In this change, the shader itself is modified to remove references to the depth/stencil input attachments if the attachment is missing. This is rather inefficient, as it means the pipeline warmup will not produce a usable pipeline, but it's accepted as a workaround for something apps shouldn't really be doing. Bug: angleproject:376572258 Change-Id: I0de68252b61615cb82cba7d1730699aadf41e92f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6085368 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
ANGLE’s Vulkan back-end implementation lives in this folder.
Vulkan is an explicit graphics API. Compared to APIs like OpenGL or D3D11 explicit APIs can offer a number of significant benefits:
The vk::Renderer class represents an EGLDisplay. vk::Renderer owns shared global
resources like the VkDevice, VkQueue, the Vulkan format tables
and internal Vulkan shaders. The ContextVk class implements the back-end
of a front-end OpenGL Context. ContextVk processes state changes and handles action commands like
glDrawArrays and glDrawElements.
A render pass has three states: unstarted, started and active (we call it active in short),
started but inactive (we call it inactive in short). The back-end records commands into command
buffers via the following ContextVk APIs:
beginNewRenderPass: Writes out (aka flushes) prior pending commands into a primary command
buffer, then starts a new render pass. Returns a secondary command buffer inside a render pass
instance. getOutsideRenderPassCommandBuffer: May flush prior command buffers and close the render pass if
necessary, in addition to issuing the appropriate barriers. Returns a secondary command buffer
outside a render pass instance. getStartedRenderPassCommands: Returns a reference to the currently open render pass’ commands
buffer. onRenderPassFinished: Puts render pass into inactive state where you can not record more
commands into secondary command buffer, except in some special cases where ANGLE does some
optimization internally. flushCommandsAndEndRenderPassWithoutSubmit: Marks the end of render pass. It flushes secondary
command buffer into vulkan’s primary command buffer, puts secondary command buffer back to
unstarted state and then goes into recycler for reuse.
The back-end (mostly) records Image and Buffer barriers through additional CommandBufferAccess
APIs, the result of which is passed to getOutsideRenderPassCommandBuffer. Note that the barriers
are not actually recorded until getOutsideRenderPassCommandBuffer is called:
onBufferTransferRead and onBufferComputeShaderRead accumulate VkBuffer read barriers. onBufferTransferWrite and onBufferComputeShaderWrite accumulate VkBuffer write barriers. onBuffferSelfCopy is a special case for VkBuffer self copies. It behaves the same as write. onImageTransferRead and onImageComputerShadeRead accumulate VkImage read barriers. onImageTransferWrite and onImageComputerShadeWrite accumulate VkImage write barriers. onImageRenderPassRead and onImageRenderPassWrite accumulate VkImage barriers inside a
started RenderPass.
After the back-end records commands to the primary buffer and we flush (e.g. on swap) or when we call
vk::Renderer::finishQueueSerial, ANGLE submits the primary command buffer to a VkQueue.
See the code for more details.
In this example we’ll be recording a buffer copy command:
// Ensure that ANGLE sets proper read and write barriers for the Buffers.
vk::CommandBufferAccess access;
access.onBufferTransferWrite(dstBuffer);
access.onBufferTransferRead(srcBuffer);
// Get a pointer to a secondary command buffer for command recording.
vk::OutsideRenderPassCommandBuffer *commandBuffer;
ANGLE_TRY(contextVk->getOutsideRenderPassCommandBuffer(access, &commandBuffer));
// Record the copy command into the secondary buffer. We're done!
commandBuffer->copyBuffer(srcBuffer->getBuffer(), dstBuffer->getBuffer(), copyCount, copies);
More implementation details can be found in the doc directory: