@GDCPresoReviews Presumably, you would see the same thing with 0xffffffff and 32-bit inds, and this is actually required by the D3D spec (yes, I checked when I was implementing this myself), but that one is not actually a problem because a 4-billion-triangle draw would almost certainly just trip a timeout on any actual HW anyhow.
@GDCPresoReviews Anyway, to translate some old-school terminology into what is happening these days:
"Pre-transform vertex cache": identifies duplicate verts by just their indices. Effectively disabled for non-indexed draws. Used when building groups of verts to be shaded.
"Post-transform vertex cache": this is what the position/parameter caches in AMD GPUs are derived from - the storage you assemble primitives out of.
And then there's regular cache for things like vertex data fetches.
@GDCPresoReviews As in, loads you do from vertex buffers and such are just memory accesses and go through your regular shader memory hierarchy.
Vertex data reads in shaders used to have somewhat dedicated HW (the "IA" in D3D terminology) but these days usually don't. Even if you don't declare it, a normal VS is launched with the equivalent of SV_VertexID in some register, and vertex fetches from a VB end up compiling to some variant of `VertexBuf[SV_VertexId]`.
@GDCPresoReviews sometimes there's a bit of "minor magic" there to introduce a layer of indirection for old-school shaders (pre-PSO) where VS code was defined independent from the vertex format/input layout and the same shader could be used with multiple vertex layouts.
I've seen it both ways. Sometimes that remapping HW is still there, some HW does it by compiling the fetch portion into an independent shader fragment with the VS getting a function pointer to it and doing a subroutine call.
@GDCPresoReviews and, of course, in the post-PSO world, you know the input layout when you're compiling the VS so you can just hard-wire it all in, at which point it really does just turn into buffer loads indexed by SV_VertexID (or SV_InstanceID for per-instance data).
@rygorous @GDCPresoReviews NV still has dedicated hardware for vertex attribute fetch to hide latency. Though it may be less impactful these days in theory can schedule vertex warps "later", rather than schedule them as shader, which then immediately wait for their loads and doing so already eats into occupancy. Though because of easier GPU driven rendering doing custom pulling, those benefits tend to outweigh doing it manually.