Support Vulkan Debug Printf validation layer

[fu5ha]

It would be cool to be able to pipe print!(), dbg!() and friends (or introduce similar gpu-specific versions) through to https://vulkan.lunarg.com/doc/sdk/1.2.148.1/windows/debug_printf.html

[nipunG314]

Is anyone currently working on this? If not, I would like to take a stab at it.

[bjorn3]

I don't know how easy it would be to make it work with rust-gpu, but would it make sense to use defmt for better performance due to less copying on the gpu side? Or is it expected that the amount of prints is very low.

[nipunG314]

The article linked mentions above that, by default, that the shader will return a value to the validation layer every time the debug statement is encountered in the shader code. The article mentions that steps can be taken to prevent this from happening, but doesn't highlight any of them. We'll probably have to look into that.

If we don't limit the number of messages, the performance will be very slow, especially in the fragment shader.

[fu5ha]

Is anyone currently working on this? If not, I would like to take a stab at it.

Nobody is working on this atm, no. Go for it :)

The article linked mentions above that, by default, that the shader will return a value to the validation layer every time the debug statement is encountered in the shader code. The article mentions that steps can be taken to prevent this from happening, but doesn't highlight any of them. We'll probably have to look into that.

If we don't limit the number of messages, the performance will be very slow, especially in the fragment shader.

yeah, perf is always going to be bad if you're printing from a shader though so I wouldn't worry too much about micro perf opts for this path atm.

[khyperia]

format_args! and related infrastructure (println!, etc.) may be difficult to re-use. As far as I understand it, arguments are stored into a fmt::ArgumentV1 struct, which contains a pointer to a fmt::Opaque, as well as a function pointer that takes a fmt::Opaque pointer, casts it to the right type, and formats it.

This is problematic for multiple reasons:

1. Casting a pointer to an arbitrary type to a pointer to a fmt::Opaque is not supported in spir-v (nor GPU hardware) (so no transmute on pointers, etc.)
2. Function pointers are not supported in spir-v (so no vtables too, etc.)
3. Casting the Opaque back to the concrete type is also not supported, for the same reason.
4. edit, also, dynamically sized arrays cannot be created. so that makes strings (even literals) rather sad. (strings are entirely unimplemented right now)

Not sure what ways around this there are, probably can figure out something, but might take a bit of exploration. If you want to do that exploration, go for it! Just might be a lot to do :)

[khyperia]

Talked about this with the wonderful @m-ou-se for a bit, and she had some ideas:

• b"asdf" compiles to &[u8; 4], a sized array! That we can deal with, perhaps with register_constant_pointer to strip away the reference.
• "it should be doable to make a proc macro gpu_print!("asdf {}", 1.0) that results in some_intrinsic(b"asdf %f", 1.0)"

and the debug_printf extension is, well, literally printf, so we'd compile some_intrinsic to that instruction.

[nipunG314]

I have question about this. I think I'm misunderstanding something.

For the Vulkan backend, at least, wouldn't it be sufficient to add the OpExtension and the OpExtInstImport instructions and append the OpExtInst instruction everytime we want to call debug_printf.

When debug_printf is called, it sends the intended value into a buffer held by the validation layers, which then gets converted to a string and sent to the debugCallbackEXT function (or stdout if it hasn't been defined).

According to the linked document, the module is using the Results to store references for which value has to be sent to the validation layers. We don't need to specify a pointer on the CPU side for that (or do we? This is the part I'm not sure about).

If we're using the validation layer and debug_printf for this, we don't need to manage the output string's memory (like in the sized array in the previous post). My question is: do we want to depend on the Vulkan validation layer for this feature or make it completely in Rust?

[khyperia]

This isn't on our roadmap at all and we don't plan on implementing this, so I'm closing this for now.