Open
Conversation
d4cfa96 to
4a1f6c9
Compare
Collaborator
|
These are all under |
Member
Author
|
I'd say the second, that the entire If you took main's By that logic, I should also move out |
…line` and `ray_query`
…ion` to `fragment`
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
While working on spirv-std functions to query builtins, I was annoyed that our shader specific intrinsics were a bit all over the place within
spirv-std. Particularly annoying was that some intrinsics got their own mod in the root (e.g.debug_printf,sampleretc.), some intrinsics are withinarch(e.g.arch::subgroup,arch::mesh_shading), and the raytracing stuff is both inray_tracingandarch::ray_tracingwhile mixing the two ray tracing APIs ofray_pipelineandray_query.Since that PR will add a lot of new intrinsics for querying (and setting) all the different built-ins, I want to cleanup our module before implementing them all. And as most shader shader types needs their own slightly different built-in declaration, I want to give every single shader type (or extension) a module in the root of the crate.
This leaves
archwith only barriers, atomics and some miscellaneous intrinsics, which may be used from any shader. Should we also move barriers and atomics to the root of the crate?Changes
spirv_std::arch::primitive->spirv_std::geometryspirv_std::arch::mesh_shading->spirv_std::meshandspirv_std::taskspirv_std::arch::subgroup->spirv_std::subgroupspirv_std::arch::derivative->spirv_std::fragmentspirv_std::arch::demote_to_helper_invocation_ext->spirv_std::fragmentspirv_std::arch::barrier->spirv_std::barrierspirv_std::arch::atomics->spirv_std::atomic(Note the missingsto matchstd::sync::atomic)spirv_std::archstays the same, notablyIndexUncheckedspirv_std::ray_tracing, containing any shared types directly (AccelerationStructure,RayFlags)spirv_std::ray_tracing::ray_pipelineAccelerationStructure::trace_ray(&self, ...)->ray_pipeline::trace_ray(AccelerationStructure, ...), since this function is ray pipeline exclusivespirv_std::ray_tracing::ray_queryread_clockarch::read_clock*tospirv_std::shader_clock::read_clock*