You're viewing the discuss.systems public feed.

Fabian Giesenrygorous@mastodon.gamedev.place
Oct 4, 2026, 7:09 PM
@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]`.
💬 2🔄 0⭐ 0

Replies

Fabian Giesenrygorous@mastodon.gamedev.place
Oct 4, 2026, 7:12 PM
@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.
💬 1🔄 0⭐ 0
Fabian Giesenrygorous@mastodon.gamedev.place
Oct 4, 2026, 7:14 PM
@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).
💬 0🔄 0⭐ 0
Christoph Kubischpixeljetstream@mastodon.gamedev.place
Oct 5, 2026, 3:22 AM
@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.
💬 0🔄 0⭐ 0