Continuing from Fabian Giesen: Bindless Chain Letter,
"You’re implicitly assuming there’s lots of different types of resource tables. Why?" - To compare and contrast to the "Single View Type Per Table" design Microsoft disclosed about DX12 here: Direct3D 12 API Preview, download the slides, see slide 22.
"NV GL bindless: what’s the handle values in TEX handle?" - I also could not find anything online that documents what exactly that is.
"NV with resource tables: why are you billing the handle table address LDC per texture sample?" - Yes that line should have had a "(sometimes)" label, now corrected. However the LDC uses a 64-bit base address, so "tableBaseAddress" would be a pair of registers. That pair is likely to be reclaimed often. More so if a 64-bit "MOV" from constant is cheap and dual issued.
"AMD GL bindless" - The similarity between your example and my example is that we both placed the global descriptor table in a pair of scalar in the up-to-16 scalar preload and used a S_LOAD_DWORD_X8 to load the descriptor. The difference is that I'm suggesting that constant buffers should also be part of the up-to-16 scalar preload, and in the form of 64-bit pointers instead of buffer descriptors (as in your example). The other difference is that given a well engineered constant buffer, the application would group constants used at similar times, such that the shader compiler would not do a single S_BUFFER_LOAD_DWORD (as in your example) but instead a S_LOAD_WORD_X16 (or perhaps smaller) to grab many constants at one time. This better amortizes the cost of fetching the "handle". Which is exactly the point you mentioned towards the end of your post.
Another Reply
This one for Sean Barrett: "My reaction to @TimothyLottes' post: should we be making long-lasting decisions about APIs based on cycle-counting current GPUs?" - Instruction counting is one important aspect to validate a design: is the design actually a good match for the hardware? The current set of NVIDIA and AMD GPUs are likely going to be important in the market for the next 5-10 years. Might as well build an API for what exists, then when hardware changes, evolve or build another API when you actually know what those changes are. I'd like to fully understand how to minimize the work required, and how to do that on current hardware.
Another Reply
This one for John W Kloetzli, Jr: "Descriptors are more flexible than that. Can simulate bindless by keeping global resource table." - Yes directly exposing hardware descriptors would be the most flexible design. It also would result in completely different implementations on every vendor. How does one design that in a way that could be accepted by the ISVs and IHVs at Khronos?
"You’re implicitly assuming there’s lots of different types of resource tables. Why?" - To compare and contrast to the "Single View Type Per Table" design Microsoft disclosed about DX12 here: Direct3D 12 API Preview, download the slides, see slide 22.
"NV GL bindless: what’s the handle values in TEX handle?" - I also could not find anything online that documents what exactly that is.
"NV with resource tables: why are you billing the handle table address LDC per texture sample?" - Yes that line should have had a "(sometimes)" label, now corrected. However the LDC uses a 64-bit base address, so "tableBaseAddress" would be a pair of registers. That pair is likely to be reclaimed often. More so if a 64-bit "MOV" from constant is cheap and dual issued.
"AMD GL bindless" - The similarity between your example and my example is that we both placed the global descriptor table in a pair of scalar in the up-to-16 scalar preload and used a S_LOAD_DWORD_X8 to load the descriptor. The difference is that I'm suggesting that constant buffers should also be part of the up-to-16 scalar preload, and in the form of 64-bit pointers instead of buffer descriptors (as in your example). The other difference is that given a well engineered constant buffer, the application would group constants used at similar times, such that the shader compiler would not do a single S_BUFFER_LOAD_DWORD (as in your example) but instead a S_LOAD_WORD_X16 (or perhaps smaller) to grab many constants at one time. This better amortizes the cost of fetching the "handle". Which is exactly the point you mentioned towards the end of your post.
Another Reply
This one for Sean Barrett: "My reaction to @TimothyLottes' post: should we be making long-lasting decisions about APIs based on cycle-counting current GPUs?" - Instruction counting is one important aspect to validate a design: is the design actually a good match for the hardware? The current set of NVIDIA and AMD GPUs are likely going to be important in the market for the next 5-10 years. Might as well build an API for what exists, then when hardware changes, evolve or build another API when you actually know what those changes are. I'd like to fully understand how to minimize the work required, and how to do that on current hardware.
Another Reply
This one for John W Kloetzli, Jr: "Descriptors are more flexible than that. Can simulate bindless by keeping global resource table." - Yes directly exposing hardware descriptors would be the most flexible design. It also would result in completely different implementations on every vendor. How does one design that in a way that could be accepted by the ISVs and IHVs at Khronos?