Hacker News new | ask | show | jobs
by Cieric 637 days ago
As 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.

1 comments

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.