Also to be clear…these “wrappers” would really just be alternatives to the D3D interfaces but would essentially expose the exact same methods, with the same names and parameters. So they wouldn’t really be providing an alternative abstraction or anything, just a nicer view with less crust and helpful comments.

Anyhow, interested to hear if anybody has thoughts good or bad so feel free to share.

The one I’ve been thinking about the most is whether root signatures should be exposed, or to what degree. They’re a pain point for beginners, and if you assume bindless you can skip nearly all of it. But that would make the wrapper more opinionated, and it’s not clear how exactly it would work.

There’s plenty of design questions so far, some minor and some more major. The largest probably being which features to exclude. Some are less controversial, like dropping legacy barriers or vertex buffers. Others are tougher, like whether geometry shaders or descriptor copying should make the cut.

It’s not at all clear to me yet that this a good idea that would have value, and be worth my time. But it does seem intriguing to me, especially since D3D12 has changed so much and there’s plenty of “traps” for beginners to fall into by using legacy approaches.

However I think there would also be an opportunity to throw in some quality-of-life “extension” functions help smooth over certain API warts. For example, passing a char* string instead of a wchar* string for SetName or booting up a device with an Agility SDK path.

One of goals would be to directly (re-)expose the D3D functions and types rather than being more opinionated, and have the ability to seamlessly transition between the native interfaces and wrapper types through implicit conversions. This would make it easy to adopt, drop, or punch through.