Some of the newer additions to HLSL do not follow the existing conventions of the language and this creates some inconsistencies. It would have been great if some of these inconsistencies are fixed in some of the future HLSL versions.
The 1st is the DispatchRaysIndex(). Someone would expect a sematic like SV_DispatchRaysIndex. Same for PrimitiveIndex(), InstanceID() and probably more that I have forgotten.
I haven't found exactly why that is but it seems that SV_RayPayload and SV_IntersectionAttributes can be omitted. Maybe they shouldn't since this creates confusion.
Mesh shaders output is defined by vertices, primitives and indices keywords. Eg out vertices MeshPerVertOut verts[N], out primitives MeshPerPrimitiveOut primitives[M], out indices uint3 indices[M]. This is inconsistent with how ray payload is defined for example. Maybe these should be semantics.
These are only a few examples. There are possibly more.
Some of the newer additions to HLSL do not follow the existing conventions of the language and this creates some inconsistencies. It would have been great if some of these inconsistencies are fixed in some of the future HLSL versions.
The 1st is the
DispatchRaysIndex()
. Someone would expect a sematic likeSV_DispatchRaysIndex
. Same forPrimitiveIndex()
,InstanceID()
and probably more that I have forgotten.I haven't found exactly why that is but it seems that
SV_RayPayload
andSV_IntersectionAttributes
can be omitted. Maybe they shouldn't since this creates confusion.Mesh shaders output is defined by
vertices
,primitives
andindices
keywords. Egout vertices MeshPerVertOut verts[N], out primitives MeshPerPrimitiveOut primitives[M], out indices uint3 indices[M]
. This is inconsistent with how ray payload is defined for example. Maybe these should be semantics.These are only a few examples. There are possibly more.