Open tangmi opened 3 years ago
Merge remote-tracking branch 'upstream/master' into acceleration-stru…
Please try to rebase instead of merging, to keep history linear
Merge remote-tracking branch 'upstream/master' into acceleration-stru…
Please try to rebase instead of merging, to keep history linear
I'll do this when I clean up this draft, please call me out if I forget then!
@kvark the changes in hal
are ready for review. Please note there's no rush since the backends depend on new releases of upstream deps and the usefulness of this API depends on ray-tracing-pipelines or ray-query being also defined and implemented.
Some things on my mind:
ash
release >=0.32
).
hal
to support it.Thank you for moving this forward!
First of all, we've been trying to wrap up hal-0.7 release for the last month. I'd like to do this before merging the changes here. Also note how a lot of type signatures are simplified now: Borrow
, ExactSizeIterator
, and IntoIterator
are all gone! If you haven't already, please consider updating this PR to reflect that change with the new API.
Please note there's no rush since the backends depend on new releases of upstream deps
We are totally cool with depending on github revisions from master. We only switch to releases when necessary, i.e. during a release. So this is not a blocker to merging the PR.
@tangmi what's the status of this work?
@tangmi what's the status of this work?
The current state is that I have an API shape I'm pretty happy with and am in the middle of fixing some issues in the Vulkan impl (I think the last thing I was working on was overthinking mapping lists-of-lists of structs such that all the lifetimes agree).
Unfortunately, life and work has taken me away from this for the last couple months. Also, I (and everyone else) have been having a real hard time getting a hold of a GPU that can test ray query--although if ray tracing pipelines work, it's very likely that ray query will also work. I'm definitely still eager to get back into gfx-rs.
On the plus side, I believe ash
as since released so I think we don't need to point at some random revision anymore!
@tangmi it would be good if gfx-rs organization created a "hardware fund" for cases like this...
@kvark I'd happily contribute to a fund like that--sadly, I just can't find any ray tracing cards for sale at all this year!
(I know there's scalpers around but I feel icky supporting that!)
@tangmi now with Vulkan's RT support, aren't there any AMD cards on the market? Sorry, I'm not generally shopping for these.
It would be great to chat on #gfx:matrix.org (or a different platform, if you have a preference?) and see if we can unblock your progress.
Initial API proposal for just the acceleration structure part of adding ray tracing support. Once the API design is set, we can implement (and smoke test) and then move on to adding ray tracing pipelines and ray query feature detection.
There's a lot of open questions I have in the comments and I intend for this draft to be a place to track discussion. @kvark: I intend to drive discussion on individual pieces at
#gfx:matrix.org
, referring to this PR as a reference, so don't worry about reviewing all at once (I'll make sure we get through all of it)!The main theme of nearly all my questions is about how far can we deviate from
VK_KHR_acceleration_structure
to better fitgfx
(and potentially gain some API safety). Additionally, my intention is to make an API that is implemented trivially in Vulkan and pretty easily in DX12. Metal is an afterthought (although it is being thought about!), but I don't expect to make any significant concessions in the API to accommodate MPS.Here's some notes on implementation differences I expect between DX12 and Vulkan, which may be interesting to discuss how we'll solve:
B::AccelerationStructure
vk::AccelerationStructureKHR
ID3D12Buffer
, since there's no handle associated with an acceleration structureash::extensions::khr::AccelerationStructure::write_acceleration_structures_properties
withash::vk::QueryType::ACCELERATION_STRUCTURE_COMPACTED_SIZE_KHR
ID3D12GraphicsCommandList4::EmitRaytracingAccelerationStructurePostbuildInfo
(orBuildRaytracingAccelerationStructure
) and does not use a QueryPool. We can likely modify dx12's B::QueryPool to include a special case for the acceleration structure queries.vk::PhysicalDeviceAccelerationStructureFeaturesKHR::acceleration_structure_host_commands
+ methods onDevice
mint::RowMatrix3x4
. Metal uses a 4x4 matrix (matrix_float4x4
), which I believe maps tomint::RowMatrix4
, given this "Working with Matrices" doc.float3
min, then max to specify the AABB. Metal puts a bounding box on every acceleration structure and doesn't have an AABB-specific variant.VkAccelerationStructureInstanceKHR
D3D12_RAYTRACING_INSTANCE_DESC
VkAccelerationStructureGeometryKHR
andVkAccelerationStructureBuildRangeInfoKHR
at descriptor and build time, respectively. ThevkGetAccelerationStructureBuildSizesKHR
takes a primitive count array that we can use for the DX caseD3D12_RAYTRACING_GEOMETRY_TRIANGLES_DESC
orD3D12_RAYTRACING_GEOMETRY_AABBS_DESC
, and doesn't require any additional data at build time. We will just add the primitive count array values to the geometry info structs as we build them.Related: #2418