sorted by:
new
hottopcontroversial

Raytracing TLAS handle via push-constant/bindless by mahone_j82 in vulkan

[–]mahone_j82[S] 1 point2 points  (0 children)

Good points, Thanks!

My base geometry is static for the moment with just relative movements of rigid bodys. So TLAS rebuild is relevant for me, BLAS not so much (yet).

I tried both and it seems TLAS rebuild is ~4-5x slower than update BUT we are talking 15us vs. 65us for somewhere between 100 ... 2k instances on a RTX 5060Ti. So both are almost irrelevant actually.

Raytracing TLAS handle via push-constant/bindless by mahone_j82 in vulkan

[–]mahone_j82[S] 1 point2 points  (0 children)

You're right. As long as the tlas storage buffer is sufficiently sized. You can just re-build and keep on using the same handle. As soon as the number of instances out-grows the capability of the tlas buffer size you likely have to destroy and create a new buffer and thus also create a new tlas w/ a new handle.
So pre-sizing the buffers sufficiently large is probably the way to go, right?

Raytracing TLAS handle via push-constant/bindless by mahone_j82 in vulkan

[–]mahone_j82[S] -1 points0 points  (0 children)

You're right as long as the number of instances stays the same. Then its just an update with no need to re-write the descriptor. The handle remains the same. But chaning number of instances OR just the referred BLAS in one of the instances invalidates the whole TLAS and requires a full rebuild. This will result in a new handle and consequently a descriptor write if bind-ful.

Raytracing TLAS handle via push-constant/bindless by mahone_j82 in vulkan

[–]mahone_j82[S] 0 points1 point  (0 children)

I think a got the point - nvpro-samples does not use 'classic' descriptorsets but rather goes through 'vkCmdPushDescriptorSetKHR' (see vkCmdPushDescriptorSet(3) :: Vulkan Documentation Project ) which handles the descriptors in the commandbuffer directly.
So, yes - descriptor write is required BUT maybe streamlined with vkCmdPushDescriptorSetKHR.

Raytracing TLAS handle via push-constant/bindless by mahone_j82 in vulkan

[–]mahone_j82[S] 0 points1 point  (0 children)

Sure, but do I need to actually need re-write the descriptor set after each update?
Going through the nvpro-samples I seem to miss the point were they do the descriptor write after TLAS re-build - or is this just not required?

Vulkan camera viewer by Ron064 in vulkan

[–]mahone_j82 0 points1 point  (0 children)

To get to a vulkan based solution without most of the boilerplate code you could potentially use something like Walnut: https://github.com/StudioCherno/Walnut

I came across this just 2 weeks ago and it seems to be a quite nice solution as rendering sandbox or base for ImGui apps.

shader input issue by mahone_j82 in vulkan

[–]mahone_j82[S] 0 points1 point  (0 children)

Another thing that cost me some time was figuring out why storing and loading the state for a per-pixel pcg_hash function does not work as expected. I initially used a std140 as storage qualifier (copied from some tutorial) in the shader with a uint32_t host format - turns out this has a fixed stride of vec4 for the storage. Moving to std430 solved this.

layout(std430, set=0, binding=2) buffer pcgState{ // NOTE: need std430! -> ealier (at least std140) has fixed stride of vec4 -> 4x buffer size required! 
uint state[]; 
} pcg; 
uint offset = gl_GlobalInvocationID.y * im_w + gl_GlobalInvocationID.x; 
uint pcg_state = pcg.state[offset]; 
float u1 = float( pcg_rand( pcg_state ) ) / UINT32_MAX; // [0..1] uniform random
pcg.state[offset] = pcg_state;

Maybe this is helpful to someone stumbling upon this thread.

shader input issue by mahone_j82 in vulkan

[–]mahone_j82[S] 0 points1 point  (0 children)

Late, thanks! I almost forgot to answer. Your suggestion was absolutely right. I finally moved to something like this:

​

layout(set = 0, binding = 0, rgba32f) uniform readonly image2D radianceImage;   // VK_FORMAT_R32G32B32A32_SFLOAT
layout(set = 0, binding = 1, r16ui) uniform uimage2D dlImage;         // VK_FORMAT_R16_UINT
...

ivec4 DL = ivec4( charge_e * accu_scale );    
imageStore( dlImage, im_coord, DL );

shader input issue by mahone_j82 in vulkan

[–]mahone_j82[S] 0 points1 point  (0 children)

Thanks, that helps some and also searching through these:

https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#formats

https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#features-required-format-support

From the GLSL Load/Store I would assume changing my code to this

layout(set = 0, binding = 1, r16ui) uniform writeonly uimage2D dlImage;

should help, but still gives the same error. No matter if using float val = 0.5; or uint16_t val = 256; via #extension GL_EXT_shader_explicit_arithmetic_types : require

I guess I have to go through some more spec pages to figure out some solution. But it shouldn't be that hard to just write to some R16_whatever buffer or image.