Ray pipeline to Ray tracing vulkan

Started by
4 comments, last by vanitynie 6 months, 2 weeks ago

I have a question, I am learning the ray tracing in vulkan, writing in glsl. I wanna implement a demo with shadow , reflect ,refraction. I have implemented it in ray pipeline by these shaders: ray gen, miss and closet hit shader. But in ray query, not these shader, I only have a fragment shader. Should I put the there shaders into the on shader?, like this , ray gen, miss and closet hit shader → frag shader. but in this case I need too much condition jude. I need some help, or one demo to know how to deal with these question, or how to translate ray pipeline code into ray query code.

  
/* 	color:
	loop:
		  get new_d from d
	    rayQueryInit(new_d) 

	if get new direction new_d
	 rayQueryInit(new_d) 
	 rayQueryProceedEXT(rayQuery);
	get the hit_info:
	 color +=  */
/* 
Advertisement

vanitynie said:
how to translate ray pipeline code into ray query code.

You have to move all you formerly did in gen, miss and hit shaders into the single shader you do your queries from. You can also buffer various data in VRAM (e.g. hit points and material) to split the work over multiple dispatches.

Basically, ray queries disable the usual HWRT pipeline, so you have to implement it yourself.
It's important to know it may also disable some HW optimizations, e.g. reordering rays by hit material, so shader cores are better utilized. Intel has this feature automatically. NV only if you use SER with their proprietary APIs or extensions. AMD implements everything in software and does not have such HW reordering yet, and also ray queries are often faster than the pipeline with AMD HW.

However, thinking of future HW, it's likely that ray queries become more and more inefficient compared to the standard pipeline, as the pipeline restrictions allows IHVs to add more of such optimizations, up to inter-traversal-reordering.

Thus, a good reason to use ray queries is needed. E.g. a parallel algorithm in a compute shader, where you trace many rays in a workgroup and want to access all results to share work or do other optimizations.

Disclaimer: That's just stuff i've heard. And lacking personal HWRT experience so far, i'm not 100% sure about anything.

because I am@JoeJ coding in mobile device . and the mobile device don't support the ray tracing pipeline. so I need to use the vulkan extension: Ray Query. so I have question about how to use the rasterization graphic pipline with ray tracing by ray query. such as the AO, shadow, refraction. so should I put these thing into the compute shader to simulate the ray tracing gen by per pixel or others?

vanitynie said:
because I am@JoeJ coding in mobile device . and the mobile device don't support the ray tracing pipeline.

How interesting. What's the GPU arch? Some Qualcomm?

vanitynie said:
so should I put these thing into the compute shader to simulate the ray tracing gen by per pixel or others?

Yes. But i would not think of it as ‘simulating the ray pipeline’, but rather ‘being free to implement they way i need it, without restrictions such as a single threaded abstraction’.
The pipeline can be great from the perspective of IHVs, but from our perspective i would always prefer ray queries if there were no concerns as mentioned above.

For example, if you do AO or area light shadows in a compute shader, you can access the results of neighboring pixels and make some mini denoiser without using VRAM. That's not possible with the pipeline.

Or, if you don't need such access to nearby samples, you can trace directly from a pixel shader, eliminating the overhead from the RT pipeline and all its shader stages.

I would look for example projects to reduce uncertainty. AMD should have some on their GPU Open webpage, and your IHV as well.

@JoeJ thank you very much, I got a little

This topic is closed to new replies.

Advertisement