-
Notifications
You must be signed in to change notification settings - Fork 125
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
Portable Acceleration Structures #1955
base: dev
Are you sure you want to change the base?
Portable Acceleration Structures #1955
Conversation
CI gfxreconstruct build queued with queue ID 344454. |
CI gfxreconstruct build # 5784 running. |
154df0e
to
c08661a
Compare
CI gfxreconstruct build queued with queue ID 344470. |
c08661a
to
c810c23
Compare
CI gfxreconstruct build queued with queue ID 344472. |
CI gfxreconstruct build # 5785 running. |
CI gfxreconstruct build # 5785 failed. |
CI gfxreconstruct build queued with queue ID 344525. |
CI gfxreconstruct build # 5787 running. |
CI gfxreconstruct build # 5787 failed. |
- Add internal command/queue-assets, manage lifetime
c810c23
to
62d9748
Compare
CI gfxreconstruct build queued with queue ID 344604. |
CI gfxreconstruct build # 5789 running. |
- cleanup obsolete warnings
CI gfxreconstruct build queued with queue ID 344693. |
CI gfxreconstruct build # 5790 running. |
CI gfxreconstruct build # 5790 failed. |
else | ||
{ | ||
GFXRECON_LOG_INFO_ONCE( | ||
"VulkanAddressReplacer::ProcessCmdTraceRays: missing buffer_info->replay_address, remap failed") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you specify the function because this macro is within a lambda, therefore __FUNCTION__
has weird value? :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we might not need the log-error there at all. was mostly for debugging, also added a return value to check
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
purged the log-info
bool VulkanAddressReplacer::init_pipeline() | ||
{ | ||
if (pipeline_sbt_ != VK_NULL_HANDLE) | ||
if (_pipeline_sbt != VK_NULL_HANDLE) | ||
{ | ||
// assume already initialized |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I call these kinds of functions ensure_*
. :)
@@ -249,7 +249,13 @@ VkResult VulkanRebindAllocator::CreateBuffer(const VkBufferCreateInfo* create | |||
|
|||
if ((create_info != nullptr) && (buffer != nullptr) && (allocator_data != nullptr)) | |||
{ | |||
result = functions_.create_buffer(device_, create_info, nullptr, buffer); | |||
auto aligned_size = [](uint32_t size, uint32_t alignment) -> uint32_t { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a similar function in vulkan_address_replacer.cpp
. How about moving this in a common header under the graphics namespace?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I chose util/alignment_utils.h
and consolidated the alignment and divup helpers there
CI gfxreconstruct build queued with queue ID 345010. |
CI gfxreconstruct build # 5796 running. |
CI gfxreconstruct build # 5796 failed. |
VkWriteDescriptorSet* in_pDescriptorWrites = p_descriptor_writes->GetPointer(); | ||
VkCopyDescriptorSet* in_pDescriptorCopies = p_pescriptor_copies->GetPointer(); | ||
|
||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we check that one or more of the extensions are enabled before we do this? I know right now it will only be for Ray Tracing, and eventually things like device generated commands, but should we not do this work if we don't have to?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good point, will check if we can avoid any unnecessary work
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found we can guard the loop like this:
// bail out if we're not tracking any shadow acceleration-structures
if (shadow_as_map_.empty())
{
return;
}
this will avoid any iteration when the class is not actively replacing stuff
GFXRECON_ASSERT(allocator != nullptr); | ||
|
||
if (allocator->SupportsOpaqueDeviceAddresses() || !loading_trim_state_) | ||
if (loading_trim_state_) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why only if loading trim state in all 3 of the following functions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
those 3 meta-commands all issue calls to restore state around acceleration-structures. rebuild, (compaction-)copies and querying the compacted size. that's only required for loading the trim state (afterwards the flow is through the Override*Acceleration*() overrides)
@@ -634,7 +611,7 @@ void VulkanDecoderBase::DispatchVulkanAccelerationStructuresWritePropertiesMetaC | |||
|
|||
std::size_t bytes_read = ValueDecoder::DecodeHandleIdValue(parameter_buffer, sizeof(format::HandleId), &device_id); | |||
bytes_read += ValueDecoder::DecodeEnumValue(parameter_buffer + bytes_read, sizeof(VkQueryType), &query_type); | |||
bytes_read += ValueDecoder::DecodeHandleIdValue( | |||
ValueDecoder::DecodeHandleIdValue( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not update the bytes read here? This seems wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can add it back, it's just nobody will check bytes_read
after that and clang-tidy remarked something there. will check
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clang-tidy's comment was: "The value is never used"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm... Ok. I won't push for it, but I just worry about something being added after this being incorrect. Maybe just add (void)bytes_read; line to make clang-tidy happy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I share your concern. if anyone appends stuff here I'd rather leave it and ignore clang-tidy (I think it's great, just not here) -> rolled back
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
if (omitted_pipeline_cache_data_) | ||
// NOTE: as of early 2025, rayTracingPipelineShaderGroupHandleCaptureReplay is not widely supported. | ||
// e.g. newest nvidia desktop-drivers do not support this feature | ||
if (device_info->property_feature_info.feature_rayTracingPipelineShaderGroupHandleCaptureReplay) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to make sure this was enabled at vkCreateDevice
time? Or does the device_info
already do it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
device_info
has it all. the feature might have been available during capture, but still missing during replay (e.g. seeing that for rayTracingPipelineShaderGroupHandleCaptureReplay
between nvidia(no) <-> radv(yes))
for replay, we do checks in gfxrecon::graphics::VulkanDeviceUtil
figuring out if to enable the feature or not.
the information for replay is pulled from VkPhysicalDeviceRayTracingPipelineFeaturesKHR
via a vkGetPhysicalDeviceFeatures2
call. active when available both during capture & replay.
some of that logic needed to be touched in this PR (and it might not be the end of story yet).
CI gfxreconstruct build queued with queue ID 345554. |
CI gfxreconstruct build # 5801 running. |
CI gfxreconstruct build # 5801 failed. |
CI gfxreconstruct build queued with queue ID 346759. |
CI gfxreconstruct build # 5816 running. |
CI gfxreconstruct build # 5816 failed. |
CI gfxreconstruct build queued with queue ID 346827. |
CI gfxreconstruct build # 5818 running. |
CI gfxreconstruct build # 5818 passed. |
8fd261b
to
ec2788e
Compare
CI gfxreconstruct build queued with queue ID 346892. |
CI gfxreconstruct build # 5819 running. |
CI gfxreconstruct build # 5819 passed. |
…iss it during init
CI gfxreconstruct build queued with queue ID 347107. |
worked mostly on
decode::VulkanAddressReplacer
,finally enabling portable replay of raytracing pipelines, when using RebindAllocator (
-m rebind
).-> tracking, meta-commands, copies, query-pool handling and rebuild
-> rebuild AS from original input-buffers when trimming.
-> check AS- and scratch-buffer sizes, replace resources with shadow objects where required
belongs to #1526