Raytracing Tests Failing on AMD GPU #6727

cwfitzgerald · 2024-12-13T23:16:03Z

The following tests are all failing with either a device OOM on bind group creation, or a segfault on both my AMD GPUs

     Summary [   4.082s] 54 tests run: 48 passed, 6 failed, 1305 skipped
       ABORT [   3.860s] wgpu-test::wgpu-test [Executed] [Vulkan/AMD Radeon(TM) 890M Graphics/0] wgpu_test::ray_tracing::as_build::out_of_order_as_build
     Message [         ] code 0xc0000005: Invalid access to memory location. (os error 998)
        FAIL [   0.787s] wgpu-test::wgpu-test [Executed] [Vulkan/AMD Radeon(TM) 890M Graphics/0] wgpu_test::ray_tracing::as_build::out_of_order_as_build_use
       ABORT [   3.986s] wgpu-test::wgpu-test [Executed] [Vulkan/AMD Radeon(TM) 890M Graphics/0] wgpu_test::ray_tracing::as_build::unbuilt_blas     
     Message [         ] code 0xc0000005: Invalid access to memory location. (os error 998)
        FAIL [   0.912s] wgpu-test::wgpu-test [Executed] [Vulkan/AMD Radeon(TM) 890M Graphics/0] wgpu_test::ray_tracing::as_use_after_free::acceleration_structure_use_after_free
       ABORT [   3.912s] wgpu-test::wgpu-test [Executed] [Vulkan/AMD Radeon(TM) 890M Graphics/0] wgpu_test::ray_tracing::scene::acceleration_structure_build_no_index
     Message [         ] code 0xc0000005: Invalid access to memory location. (os error 998)
       ABORT [   4.026s] wgpu-test::wgpu-test [Executed] [Vulkan/AMD Radeon(TM) 890M Graphics/0] wgpu_test::ray_tracing::scene::acceleration_structure_build_with_index
     Message [         ] code 0xc0000005: Invalid access to memory location. (os error 998

The text was updated successfully, but these errors were encountered:

cwfitzgerald · 2024-12-14T00:22:51Z

One stack:

>	wgpu_test-a51d5c185a8577b7.exe!ash::extensions_generated::khr::acceleration_structure::Device::get_acceleration_structure_build_sizes(ash::vk::enums::AccelerationStructureBuildTypeKHR self, ash::vk::definitions::AccelerationStructureBuildGeometryInfoKHR * build_type, ref$<slice2$<u32>> build_info, ash::vk::definitions::AccelerationStructureBuildSizesInfoKHR * size_info) Line 275	Rust
 	wgpu_test-a51d5c185a8577b7.exe!wgpu_hal::vulkan::device::impl$4::get_acceleration_structure_build_sizes(wgpu_hal::vulkan::Device * self, wgpu_hal::GetAccelerationStructureBuildSizesDescriptor<wgpu_hal::vulkan::Buffer> * desc) Line 2412	Rust
 	wgpu_test-a51d5c185a8577b7.exe!wgpu_hal::dynamic::device::impl$0::get_acceleration_structure_build_sizes<wgpu_hal::vulkan::Device>(wgpu_hal::vulkan::Device * self, wgpu_hal::GetAccelerationStructureBuildSizesDescriptor<dyn$<wgpu_hal::dynamic::DynBuffer>> * desc) Line 501	Rust
 	wgpu_test-a51d5c185a8577b7.exe!wgpu_core::device::resource::Device::create_blas(wgpu_types::CreateBlasDescriptor<enum2$<core::option::Option<enum2$<alloc::borrow::Cow<str$>>>>> * self, enum2$<wgpu_types::BlasGeometrySizeDescriptors> blas_desc) Line 69	Rust
 	wgpu_test-a51d5c185a8577b7.exe!wgpu_core::global::Global::device_create_blas(wgpu_core::id::Id<enum2$<wgpu_core::id::markers::Device>> self, wgpu_types::CreateBlasDescriptor<enum2$<core::option::Option<enum2$<alloc::borrow::Cow<str$>>>>> * device_id, enum2$<wgpu_types::BlasGeometrySizeDescriptors> desc, enum2$<core::option::Option<wgpu_core::id::Id<enum2$<wgpu_core::id::markers::Blas>>>> sizes) Line 204	Rust
 	wgpu_test-a51d5c185a8577b7.exe!wgpu::backend::wgpu_core::impl$13::create_blas(wgpu::backend::wgpu_core::CoreDevice * self, wgpu_types::CreateBlasDescriptor<enum2$<core::option::Option<ref$<str$>>>> * desc, enum2$<wgpu_types::BlasGeometrySizeDescriptors> sizes) Line 1447	Rust
 	wgpu_test-a51d5c185a8577b7.exe!wgpu::api::device::Device::create_blas(wgpu_types::CreateBlasDescriptor<enum2$<core::option::Option<ref$<str$>>>> * self, enum2$<wgpu_types::BlasGeometrySizeDescriptors> desc) Line 463	Rust
 	wgpu_test-a51d5c185a8577b7.exe!wgpu_test::ray_tracing::as_build::AsBuildContext::new() Line 33	Rust
 	wgpu_test-a51d5c185a8577b7.exe!wgpu_test::ray_tracing::as_build::out_of_order_as_build(wgpu_test::run::TestingContext ctx) Line 122	Rust

Vecvec · 2024-12-14T01:17:19Z

was this one crashing with an OOM or a access violation?

cwfitzgerald · 2024-12-14T01:21:22Z

Access violation - it crashed in amdvlk64.dll, but I missed those in the stack

Vecvec · 2024-12-14T01:22:04Z

~~Could you try hal ray-traced triangle? If it does crash, does it crash at blas or tlas size getting?~~

Nevermind I don't think that would help.

Vecvec · 2024-12-14T01:36:17Z

I wonder if it's trying to read from the vertex buffer (we don't and aren't required to set it), can you attach a program that does this to a debugger and see the address it's trying dereference? It would likely be 0.

Vecvec · 2024-12-15T01:47:31Z

Since AMD's drivers are open source, is it possible to get debug symbols out of them? Knowing where the problem is occurring helps figure out what could be occurring.

cwfitzgerald · 2024-12-15T01:48:35Z

Not the windows ones :)

Vecvec · 2024-12-15T01:51:25Z

Oh, that's annoying. Is it possible to (using a debugger) see at what address the access violation is occurring?

cwfitzgerald · 2024-12-15T02:14:27Z

Yeah, I'll look when I've a minute

cwfitzgerald · 2024-12-15T05:57:19Z

It's 0x8, but that's just adding 8 to a zero pointer.

If it helps this is the debugger dump of locals from ashes wrapper function,

cwfitzgerald · 2024-12-15T06:04:54Z

Ah alright, it's first doing

rax = *(self.handle + 8 + 43144) // this is zero
// stuff
rcx = *(rax + 8)

00007FF95CA652B4  mov         rax,qword ptr [r15+0A888h]  
00007FF95CA652BB  lea         r8,[rbp-1]  
00007FF95CA652BF  lea         rdx,[rbp-51h]  
00007FF95CA652C3  mov         rcx,qword ptr [rax+8]

r15 is self.handle + 8

cwfitzgerald · 2024-12-15T06:11:17Z

Bad AS? The handle seems to point as approximately nothing

Vecvec · 2024-12-15T18:18:32Z

Bad AS? The handle seems to point as approximately nothing

At get_acceleration_structure_build_sizes there is no acceleration structure, that function call is to get its size so that it can be allocated. There are also no buffers as they should not impact size. (I'm assuming AS means acceleration structure in this context)

nical · 2024-12-16T09:11:14Z

We should probably not expose the ray tracing feature on AMD until this stuff is figured out.

Vecvec · 2024-12-21T20:43:32Z

Just want to check, does this also occur on the examples, if so which ones? That might be able to narrow things down (e.g. most of the examples use an index buffer).

Vecvec · 2024-12-21T20:52:46Z

Noticed that although we set index_type to none in build_acceleration_structures we don't in get_acceleration_structure_build_sizes, would it be possible to insert .index_type(vk::IndexType::NONE_KHR) in there too? I'm going to get a patch ready to do that because we should be doing this.

Edit: I can't really see why this would be causing it, but it's the only bug I can currently find...

cwfitzgerald · 2024-12-22T04:27:35Z

Nope did nothing

Vecvec · 2024-12-22T04:45:25Z

OK. I wasn't expecting it to work, but since there was a bug in the same function I was interested.

Vecvec · 2024-12-22T04:46:56Z

Do the examples work?

cwfitzgerald · 2024-12-22T23:54:31Z

Do the examples work?

Weirdly, yes - all 5 do.

Vecvec · 2024-12-23T01:38:03Z

Weirdly, yes - all 5 do.

Then we need to find what the examples are doing differently.

Vecvec · 2024-12-23T01:46:15Z

There are two things I can find (quickly)

all examples have an index buffer, all tests don't.
All examples use AccelerationStructureGeometryFlags::OPAQUE while all tests use `::empty()'

The geo flags seem the most likely (because we have already found 3 index bugs). Could you try changing them?

Vecvec · 2024-12-23T21:14:16Z

ACCELERATION_STRUCTURE_BUILD_WITH_INDEX was marked as failing, but did that one fail in the same place? ~~It doesn't appear on the failing tests (and nor does ACCELERATION_STRUCTURE_BUILD_NO_INDEX)~~(never mind just noticed it does). These tests both use wgpu::AccelerationStructureGeometryFlags::OPAQUE too.

cwfitzgerald · 2024-12-23T23:18:22Z

Yup, failed in the same place:

 	amdvlk64.dll!00007ff9bb9e52c3()	Unknown
 	VkLayer_khronos_validation.dll!DispatchGetAccelerationStructureBuildSizesKHR(VkDevice_T * device, VkAccelerationStructureBuildTypeKHR buildType, const VkAccelerationStructureBuildGeometryInfoKHR * pBuildInfo, const unsigned int * pMaxPrimitiveCounts, VkAccelerationStructureBuildSizesInfoKHR * pSizeInfo) Line 1384	C++
 	VkLayer_khronos_validation.dll!vulkan_layer_chassis::GetAccelerationStructureBuildSizesKHR(VkDevice_T * device, VkAccelerationStructureBuildTypeKHR buildType, const VkAccelerationStructureBuildGeometryInfoKHR * pBuildInfo, const unsigned int * pMaxPrimitiveCounts, VkAccelerationStructureBuildSizesInfoKHR * pSizeInfo) Line 27495	C++
>	wgpu_test-361ae807292d2ffa.exe!ash::extensions_generated::khr::acceleration_structure::Device::get_acceleration_structure_build_sizes(ash::vk::enums::AccelerationStructureBuildTypeKHR self, ash::vk::definitions::AccelerationStructureBuildGeometryInfoKHR * build_type, ref$<slice2$<u32>> build_info, ash::vk::definitions::AccelerationStructureBuildSizesInfoKHR * size_info) Line 275	Rust
 	wgpu_test-361ae807292d2ffa.exe!wgpu_hal::vulkan::device::impl$4::get_acceleration_structure_build_sizes(wgpu_hal::vulkan::Device * self, wgpu_hal::GetAccelerationStructureBuildSizesDescriptor<wgpu_hal::vulkan::Buffer> * desc) Line 2413	Rust
 	wgpu_test-361ae807292d2ffa.exe!wgpu_hal::dynamic::device::impl$0::get_acceleration_structure_build_sizes<wgpu_hal::vulkan::Device>(wgpu_hal::vulkan::Device * self, wgpu_hal::GetAccelerationStructureBuildSizesDescriptor<dyn$<wgpu_hal::dynamic::DynBuffer>> * desc) Line 501	Rust
 	wgpu_test-361ae807292d2ffa.exe!wgpu_core::device::resource::Device::create_blas(wgpu_types::CreateBlasDescriptor<enum2$<core::option::Option<enum2$<alloc::borrow::Cow<str$>>>>> * self, enum2$<wgpu_types::BlasGeometrySizeDescriptors> blas_desc) Line 69	Rust
 	wgpu_test-361ae807292d2ffa.exe!wgpu_core::global::Global::device_create_blas(wgpu_core::id::Id<enum2$<wgpu_core::id::markers::Device>> self, wgpu_types::CreateBlasDescriptor<enum2$<core::option::Option<enum2$<alloc::borrow::Cow<str$>>>>> * device_id, enum2$<wgpu_types::BlasGeometrySizeDescriptors> desc, enum2$<core::option::Option<wgpu_core::id::Id<enum2$<wgpu_core::id::markers::Blas>>>> sizes) Line 204	Rust
 	wgpu_test-361ae807292d2ffa.exe!wgpu::backend::wgpu_core::impl$13::create_blas(wgpu::backend::wgpu_core::CoreDevice * self, wgpu_types::CreateBlasDescriptor<enum2$<core::option::Option<ref$<str$>>>> * desc, enum2$<wgpu_types::BlasGeometrySizeDescriptors> sizes) Line 1433	Rust
 	wgpu_test-361ae807292d2ffa.exe!wgpu::api::device::Device::create_blas(wgpu_types::CreateBlasDescriptor<enum2$<core::option::Option<ref$<str$>>>> * self, enum2$<wgpu_types::BlasGeometrySizeDescriptors> desc) Line 487	Rust
 	wgpu_test-361ae807292d2ffa.exe!wgpu_test::ray_tracing::scene::acceleration_structure_build(wgpu_test::run::TestingContext * ctx, bool use_index_buffer) Line 40	Rust
 	wgpu_test-361ae807292d2ffa.exe!wgpu_test::ray_tracing::scene::acceleration_structure_build_with_index_initializer::closure$0(wgpu_test::ray_tracing::scene::acceleration_structure_build_with_index_initializer::closure_env$0 *, wgpu_test::run::TestingContext ctx) Line 124	Rust

Vecvec · 2024-12-23T23:39:31Z

Ok... that means that my first ideas don't work. The only other thing I have been able to find is that we use downlevel_defaults for tests but defaults for examples. Could you try inserting .limits(Limits::default()) after the features have been set?

cwfitzgerald · 2024-12-23T23:46:32Z

I can try it, but those are only for internal validation, they don't make it down to vulkan (I don't think).

Vecvec · 2024-12-23T23:51:03Z

No, they don't seem to. Don't bother.

Vecvec · 2024-12-24T00:11:14Z

Do the examples work when run as part of the test? I'm really unsure what other differences there are.

cwfitzgerald · 2024-12-24T00:18:29Z

It seems so

Vecvec · 2024-12-24T04:33:07Z

My only other idea is that because only one downlevel capability is being set it's triggering some odd code path that AMD doesn't like (probably unlikely).

Vecvec · 2024-12-26T05:59:59Z

I am now wondering whether this call is even the root cause - using vulkan's API dump it seems that the actual call to this function is given the same parameters (excluding pointer differences) with acceleration_structure_build_with_index (failing) and ray_cube_compute (succeeding). I'm not sure how to approach this now.

Vecvec · 2024-12-26T22:33:04Z

In ray_cube_compute, could you try changing wgpu::DownlevelCapabilities::default() in required_downlevel_capabilities to

        wgpu::DownlevelCapabilities {
            flags: wgpu::DownlevelFlags::COMPUTE_SHADERS,
            .. wgpu::DownlevelCapabilities::default()
        }

and tell me if it still works? If so could you add downlevel flags until it does work and tell me what the flag the made it work was?

cwfitzgerald · 2025-01-08T22:18:49Z

Made no difference

Vecvec · 2025-01-09T08:15:14Z

Could you try swapping out the original ray_cube_compute's init function with this (I'm assuming that new build_with_transform fails too - tell me if it succeeds)

let vertices = device.create_buffer_init(&BufferInitDescriptor {
            label: None,
            contents: &[0; mem::size_of::<[[f32; 3]; 3]>()],
            usage: BufferUsages::BLAS_INPUT,
        });

        let transform = device
            .create_buffer_init(&wgpu::util::BufferInitDescriptor {
                label: Some("Vertex Buffer"),
                contents: bytemuck::cast_slice(&[
                    1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0,
                ]),
                usage: wgpu::BufferUsages::VERTEX | wgpu::BufferUsages::BLAS_INPUT,
            });

        let blas_size = BlasTriangleGeometrySizeDescriptor {
            vertex_format: VertexFormat::Float32x3,
            vertex_count: 3,
            index_format: None,
            index_count: None,
            flags: AccelerationStructureGeometryFlags::empty(),
        };

        let blas = device.create_blas(
            &CreateBlasDescriptor {
                label: Some("BLAS"),
                flags: AccelerationStructureFlags::PREFER_FAST_TRACE,
                update_mode: AccelerationStructureUpdateMode::Build,
            },
            BlasGeometrySizeDescriptors::Triangles {
                descriptors: vec![blas_size.clone()],
            },
        );

        let tlas = device.create_tlas(&CreateTlasDescriptor {
            label: Some("TLAS"),
            max_instances: 1,
            flags: AccelerationStructureFlags::PREFER_FAST_TRACE,
            update_mode: AccelerationStructureUpdateMode::Build,
        });

        let mut tlas_package = TlasPackage::new(tlas);
        tlas_package[0] = Some(TlasInstance::new(
            &blas,
            [1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0],
            0,
            0xFF,
        ));

        let mut encoder_build = device
            .create_command_encoder(&CommandEncoderDescriptor {
                label: Some("BUILD 1"),
            });

        encoder_build.build_acceleration_structures(
            [&BlasBuildEntry {
                blas: &blas,
                geometry: BlasGeometries::TriangleGeometries(vec![BlasTriangleGeometry {
                    size: &blas_size,
                    vertex_buffer: &vertices,
                    first_vertex: 0,
                    vertex_stride: mem::size_of::<[f32; 3]>() as BufferAddress,
                    index_buffer: None,
                    index_buffer_offset: None,
                    transform_buffer: Some(&transform),
                    transform_buffer_offset: Some(0),
                }]),
            }],
            [&tlas_package],
        );
        queue.submit([encoder_build.finish()]);
        
        panic!("finished");

and see if that reaches the panic? (this is just the test I mentioned earlier turned into a example)

cwfitzgerald · 2025-01-09T15:59:33Z

So swapped out with the init, than run the test associated with the example. AMD successfully hit finished, but nvidia threw validation errors

[2025-01-09T15:58:04Z ERROR wgpu_hal::vulkan::instance] VALIDATION [VUID-vkCmdBuildAccelerationStructuresKHR-pInfos-03671 (0x2229b56c)]
        Validation Error: [ VUID-vkCmdBuildAccelerationStructuresKHR-pInfos-03671 ] Object 0: handle = 0x1d3528e4a70, name = BUILD 1, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x2e2941000000001f, name = (wgpu) scratch buffer, type = VK_OBJECT_TYPE_BUFFER; | MessageID = 0x2229b56c | vkCmdBuildAccelerationStructuresKHR(): pInfos[0].scratchData.deviceAddress (0xe9b2000) has no buffer(s) associated to it such that valid usage passes. At least one buffer associated to this device address must be valid.
    The following buffers have an address range that does not include scratch address range [0xe9b2000, 0xe9b2a80):
    VkBuffer 0x2e2941000000001f[(wgpu) scratch buffer]: buffer address range is [0xe9b2000, 0xe9b2880)

    The Vulkan spec states: If pInfos[i].mode is VK_BUILD_ACCELERATION_STRUCTURE_MODE_BUILD_KHR, all addresses between pInfos[i].scratchData.deviceAddress and pInfos[i].scratchData.deviceAddress + N - 1 must be in the buffer device address range of the same buffer, where N is given by the buildScratchSize member of the VkAccelerationStructureBuildSizesInfoKHR structure returned from a call to vkGetAccelerationStructureBuildSizesKHR with an identical VkAccelerationStructureBuildGeometryInfoKHR structure and primitive count (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-vkCmdBuildAccelerationStructuresKHR-pInfos-03671)
[2025-01-09T15:58:04Z ERROR wgpu_hal::vulkan::instance]         objects: (type: COMMAND_BUFFER, hndl: 0x1d3528e4a70, name: BUILD 1), (type: BUFFER, hndl: 0x2e2941000000001f, name: (wgpu) scratch buffer)
thread '<unnamed>' panicked at examples\src\ray_cube_compute\mod.rs:232:9:
finished
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[2025-01-09T15:58:05Z ERROR wgpu_test::expectations] Panic: finished
[2025-01-09T15:58:05Z ERROR wgpu_test::expectations] Validation Error: Validation Error: [ VUID-vkCmdBuildAccelerationStructuresKHR-pInfos-03671 ] Object 0: handle = 0x1d3528e4a70, name = BUILD 1, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x2e2941000000001f, name = (wgpu) scratch buffer, type = VK_OBJECT_TYPE_BUFFER; | MessageID = 0x2229b56c | vkCmdBuildAccelerationStructuresKHR(): pInfos[0].scratchData.deviceAddress (0xe9b2000) has no buffer(s) associated to it such that valid usage passes. At least one buffer associated to this device address must be valid.
    The following buffers have an address range that does not include scratch address range [0xe9b2000, 0xe9b2a80):
    VkBuffer 0x2e2941000000001f[(wgpu) scratch buffer]: buffer address range is [0xe9b2000, 0xe9b2880)

    The Vulkan spec states: If pInfos[i].mode is VK_BUILD_ACCELERATION_STRUCTURE_MODE_BUILD_KHR, all addresses between pInfos[i].scratchData.deviceAddress and pInfos[i].scratchData.deviceAddress + N - 1 must be in the buffer device address range of the same buffer, where N is given by the buildScratchSize member of the VkAccelerationStructureBuildSizesInfoKHR structure returned from a call to vkGetAccelerationStructureBuildSizesKHR with an identical VkAccelerationStructureBuildGeometryInfoKHR structure and primitive count (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-vkCmdBuildAccelerationStructuresKHR-pInfos-03671)

Vecvec · 2025-01-09T18:12:51Z

How odd... I shall have to look into that. The other test I derived this from failed? If so then that narrows our search.

cwfitzgerald · 2025-01-09T18:15:52Z

Yes, wgpu_test::ray_tracing::as_build::build_with_transform fails with a similar error

--- STDERR:              wgpu-test::wgpu-test [Executed] [Vulkan/NVIDIA GeForce RTX 4070/0] wgpu_test::ray_tracing::as_build::build_with_transform ---
[2025-01-09T18:14:57Z ERROR wgpu_hal::vulkan::instance] VALIDATION [VUID-vkCmdBuildAccelerationStructuresKHR-pInfos-03671 (0x2229b56c)]
        Validation Error: [ VUID-vkCmdBuildAccelerationStructuresKHR-pInfos-03671 ] Object 0: handle = 0x18438a36680, name = BUILD 1, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x95a125000000001a, name = (wgpu) scratch buffer, type = VK_OBJECT_TYPE_BUFFER; | MessageID = 0x2229b56c | vkCmdBuildAccelerationStructuresKHR(): pInfos[0].scratchData.deviceAddress (0xe9b2000) has no buffer(s) associated to it such that valid usage passes. At least one buffer associated to this device address must be valid.
    The following buffers have an address range that does not include scratch address range [0xe9b2000, 0xe9b2a80):
    VkBuffer 0x95a125000000001a[(wgpu) scratch buffer]: buffer address range is [0xe9b2000, 0xe9b2880)

    The Vulkan spec states: If pInfos[i].mode is VK_BUILD_ACCELERATION_STRUCTURE_MODE_BUILD_KHR, all addresses between pInfos[i].scratchData.deviceAddress and pInfos[i].scratchData.deviceAddress + N - 1 must be in the buffer device address range of the same buffer, where N is given by the buildScratchSize member of the VkAccelerationStructureBuildSizesInfoKHR structure returned from a call to vkGetAccelerationStructureBuildSizesKHR with an identical VkAccelerationStructureBuildGeometryInfoKHR structure and primitive count (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-vkCmdBuildAccelerationStructuresKHR-pInfos-03671)
[2025-01-09T18:14:57Z ERROR wgpu_hal::vulkan::instance]         objects: (type: COMMAND_BUFFER, hndl: 0x18438a36680, name: BUILD 1), (type: BUFFER, hndl: 0x95a125000000001a, name: (wgpu) scratch buffer)
[2025-01-09T18:14:57Z ERROR wgpu_test::expectations] Validation Error: Validation Error: [ VUID-vkCmdBuildAccelerationStructuresKHR-pInfos-03671 ] Object 0: handle = 0x18438a36680, name = BUILD 1, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x95a125000000001a, name = (wgpu) scratch buffer, type = VK_OBJECT_TYPE_BUFFER; | MessageID = 0x2229b56c | vkCmdBuildAccelerationStructuresKHR(): pInfos[0].scratchData.deviceAddress (0xe9b2000) has no buffer(s) associated to it such that valid usage passes. At least one buffer associated to this device address must be valid.
    The following buffers have an address range that does not include scratch address range [0xe9b2000, 0xe9b2a80):
    VkBuffer 0x95a125000000001a[(wgpu) scratch buffer]: buffer address range is [0xe9b2000, 0xe9b2880)

    The Vulkan spec states: If pInfos[i].mode is VK_BUILD_ACCELERATION_STRUCTURE_MODE_BUILD_KHR, all addresses between pInfos[i].scratchData.deviceAddress and pInfos[i].scratchData.deviceAddress + N - 1 must be in the buffer device address range of the same buffer, where N is given by the buildScratchSize member of the VkAccelerationStructureBuildSizesInfoKHR structure returned from a call to vkGetAccelerationStructureBuildSizesKHR with an identical VkAccelerationStructureBuildGeometryInfoKHR structure and primitive count (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-vkCmdBuildAccelerationStructuresKHR-pInfos-03671)
thread '<unnamed>' panicked at tests\src\run.rs:120:9:
tests\tests\ray_tracing\as_build.rs:333:53: test "wgpu_test::ray_tracing::as_build::build_with_transform" did not behave as expected
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrac

Vecvec · 2025-01-09T18:16:23Z

Does it fail on AMD?

cwfitzgerald · 2025-01-09T18:17:49Z

It segfaults.

Vecvec · 2025-01-09T18:21:25Z

Ok - that narrows it down, that means that the error is not in the test itself.

Vecvec · 2025-01-09T18:38:24Z

The nVidea issue is unrelated, I think it's because there is no way to tell if there is a transform buffer and for some reason nVidea has a larger scratch size for that. You should open an issue for it as you know more about it.

github-project-automation bot added this to WebGPU for Firefox Dec 13, 2024

github-project-automation bot moved this to Todo in WebGPU for Firefox Dec 13, 2024

cwfitzgerald added type: bug Something isn't working backend: vulkan Issues with Vulkan labels Dec 13, 2024

cwfitzgerald mentioned this issue Dec 13, 2024

Skip AMD GPUs from RT Tests #6728

Merged

cwfitzgerald added feature: bindless Issues with Bindless Native Feature feature: raytracing Issues with the Ray Tracing Native Feature and removed feature: bindless Issues with Bindless Native Feature labels Dec 14, 2024

jimblandy removed this from WebGPU for Firefox Dec 16, 2024

This was referenced Dec 16, 2024

Ray Tracing Tracking Issue #6762

Open

Support DXR in wgpu-hal & naga. #6777

Merged

Vecvec mentioned this issue Dec 22, 2024

Set index type to NONE in get_acceleration_structure_build_sizes #6802

Merged

5 tasks

Vecvec mentioned this issue Jan 5, 2025

[vulkan] acceleration structure in a descriptor pool are not properly allocated #6859

Closed

Raytracing Tests Failing on AMD GPU #6727

Raytracing Tests Failing on AMD GPU #6727

Comments

cwfitzgerald commented Dec 13, 2024

cwfitzgerald commented Dec 14, 2024

Vecvec commented Dec 14, 2024

cwfitzgerald commented Dec 14, 2024

Vecvec commented Dec 14, 2024 • edited Loading

Vecvec commented Dec 14, 2024 • edited Loading

Vecvec commented Dec 15, 2024

cwfitzgerald commented Dec 15, 2024

Vecvec commented Dec 15, 2024

cwfitzgerald commented Dec 15, 2024

cwfitzgerald commented Dec 15, 2024

cwfitzgerald commented Dec 15, 2024 • edited Loading

cwfitzgerald commented Dec 15, 2024

Vecvec commented Dec 15, 2024

nical commented Dec 16, 2024

Vecvec commented Dec 21, 2024

Vecvec commented Dec 21, 2024 • edited Loading

cwfitzgerald commented Dec 22, 2024

Vecvec commented Dec 22, 2024 • edited Loading

Vecvec commented Dec 22, 2024

cwfitzgerald commented Dec 22, 2024 • edited Loading

Vecvec commented Dec 23, 2024

Vecvec commented Dec 23, 2024

Vecvec commented Dec 23, 2024 • edited Loading

cwfitzgerald commented Dec 23, 2024

Vecvec commented Dec 23, 2024

cwfitzgerald commented Dec 23, 2024

Vecvec commented Dec 23, 2024

Vecvec commented Dec 24, 2024

cwfitzgerald commented Dec 24, 2024

Vecvec commented Dec 24, 2024

Vecvec commented Dec 26, 2024 • edited Loading

Vecvec commented Dec 26, 2024 • edited Loading

cwfitzgerald commented Jan 8, 2025

Vecvec commented Jan 9, 2025 • edited Loading

cwfitzgerald commented Jan 9, 2025 • edited Loading

Vecvec commented Jan 9, 2025 • edited Loading

cwfitzgerald commented Jan 9, 2025

Vecvec commented Jan 9, 2025

cwfitzgerald commented Jan 9, 2025

Vecvec commented Jan 9, 2025

Vecvec commented Jan 9, 2025 • edited Loading

Vecvec commented Dec 14, 2024 •

edited

Loading

Vecvec commented Dec 14, 2024 •

edited

Loading

cwfitzgerald commented Dec 15, 2024 •

edited

Loading

Vecvec commented Dec 21, 2024 •

edited

Loading

Vecvec commented Dec 22, 2024 •

edited

Loading

cwfitzgerald commented Dec 22, 2024 •

edited

Loading

Vecvec commented Dec 23, 2024 •

edited

Loading

Vecvec commented Dec 26, 2024 •

edited

Loading

Vecvec commented Dec 26, 2024 •

edited

Loading

Vecvec commented Jan 9, 2025 •

edited

Loading

cwfitzgerald commented Jan 9, 2025 •

edited

Loading

Vecvec commented Jan 9, 2025 •

edited

Loading

Vecvec commented Jan 9, 2025 •

edited

Loading