Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decide & implement a design for ray tracing pipelines #6760

Open
Vecvec opened this issue Dec 16, 2024 · 1 comment
Open

Decide & implement a design for ray tracing pipelines #6760

Vecvec opened this issue Dec 16, 2024 · 1 comment
Labels
area: api Issues related to API surface feature: raytracing Issues with the Ray Tracing Native Feature type: enhancement New feature or request

Comments

@Vecvec
Copy link
Contributor

Vecvec commented Dec 16, 2024

Is your feature request related to a problem? Please describe.
Currently naga only supports ray queries, however for some (very specific) use-cases ray tracing pipelines could be useful. E.g user defined custom intersection easier without having to change other parts of the shader.

Describe the solution you'd like
To support raytracing pipeline

Describe alternatives you've considered
Not supporting it, it's not really necessary.

Additional context
We also need to decide on some API for raytracing pipelines

@cwfitzgerald cwfitzgerald added area: api Issues related to API surface feature: raytracing Issues with the Ray Tracing Native Feature type: enhancement New feature or request labels Dec 16, 2024
@Vecvec
Copy link
Contributor Author

Vecvec commented Dec 16, 2024

Just want to note some of my previous work in naga, so here is an old WIP raytracing pipeline suggestion (or at least the naga side of it):

  • use @intersection for intersection shaders, @ray_any for any-hit shaders, @ray_closest for closest hit shaders, @ray_miss for ray-miss shaders, and @ray_gen for ray generation shaders (callable shaders were not implemented as they seemed like they were not required.
  • intersection shaders means intersection shader, closest hit shader any hit shader.
  • use @builtin(payload) with a pointer in the ray tracing address space (no requirement on struct, maybe should be same as vertex -> fragment?) allowed in all but ray_gen shaders.
  • use @builtin({world/object}_ray_{origin/direction}) to get the origin/direction in the world/object space allowed in intersection shaders.
  • use @builtin(ray_{origin/direction}) in the miss shader to get origin/direction in the shader.
  • use @builtin(ray_t) in the intersection shaders to get the t on the ray of the hit.
  • many more builtins that I need to clarify what they do.
  • functions:
// begins a trace ray, allowed in generation and closest hit shaders
fn traceRay(ray_struct: ptr<{function/ray_tracing}, ray_query>, acceleration_structure: acceleration_structure, ray_desc: RayDesc);

// the t of the intersection, the type, and an extra u32 to communicate (I've forgotten exactly what this does right now) returns whether the hit was accepted.
fn ReportIntersection(t: f32, ty:u32, intersection:u32) -> bool;

edit: just want to note that it mostly worked but need some hardening ect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: api Issues related to API surface feature: raytracing Issues with the Ray Tracing Native Feature type: enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants