Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement pixel history for dual source output and blend src/dest on Vulkan #3011

Closed

Conversation

w-pearson
Copy link
Contributor

Description

Split from #3003; depends on (and includes a copy of) #3009.

This PR implements getting the dual source output and the blend source/destination components under Vulkan. It also fixes a crash when a very large number of primitives hit the same fragment in a single draw call (but there are also few draw calls overall), which is an unlikely situation in practice but did occur in some of my tests (not part of this PR).

Currently, no backend sets this, and it is not displayed.
Currently, no backend sets them, and they are not displayed.
The first one is a simply a typo.

The second one seems to be an unnecessary value that doesn't make sense
(as blend factors are ignored when blendEnable is false, and setting the
source color blend factor to the destination color seems like an
uncommon situation (the equivalent to blendEnable being false is
source = 1, dest = 0). This does not seem to be a driver bug, as
the commit that added it (5043898) does
not mention that nor does it seem to work around other driver bugs.

The third one is that VulkanDebugManager::PixelHistoryCopyPixel was
declared but never defined. VulkanPixelHistoryCallback::CopyImagePixel
serves the same purpose.
Before, the buffer could be overrun, which could result in anything from
garbage data to the GPU device being lost to segfaults. Now, correct
data is gathered.

We can't know in advance how many primitives will hit the targetted
pixel, so it's not possible to create the buffer until after our first
pass for each events (fortunately we do know the number of events in
advance). It is possible that we don't need a larger buffer, though,
in which case the original one can be re-used.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants