Writing Portable Rendering Code with Nvrhi
developer.nvidia.comAs someone who has dealt with Nvidia messing up resource transitions on AMD cards, I'm not sure how much I would trust a library made by them to also handle that. But besides that point, this seems to do the same stuff that other libraries have done in the past.
Additionally from what I've heard most of those aren't used since if you're doing Vulkan or DX12 you're doing so for the increased control and better potential performance. Throwing in a library to track everything without any understanding of the application just reduces that performance unnecessarily.
The only thing I can pull as evidence for that (anecdotal of course), is this is the first time I've heard of this and I work in the DX12 field on the GPU side. But it's also possible that the library doesn't present itself in any way on the debugging side of things.
NVIDIA has at least 3 abstraction layers such as this and neither NRI or NVRHI seem to have issues with AMD cards. I wouldn't be surprised if one of the libraries or specific versions have problems with AMD cards, it happens during development.
Most engines I've worked do have abstraction layer for gfx APIs, usually you don't have 3 different API specific implementation for all render passes. Abstraction layers (such as NVRHI) do allow taking manual control when needed though.
Anyone know how well / if this compares with BGFX?
I wonder what the over/under on a Metal backend are? Or WebGPU?
There is now also SDL_gpu with a more open source character and support for Metal
How useful is yet another API abstraction layer that omits the rest of the fucking owl (shaders)?
The modern GPU abstraction layers are now funnier than the old "Linux audio" abstraction layers