Voit lisätä twiitteihisi sijainnin, esimerkiksi kaupungin tai tarkemman paikan, verkosta ja kolmannen osapuolen sovellusten kautta. Halutessasi voit poistaa twiittisi sijaintihistorian myöhemmin. Lue lisää
I've written/worked on a handful of rendering API abstractions, but never found much on the internet regarding it. Most of my knowledge was gained at work places, or just trying it myself. I am eager to see what this has to say.https://twitter.com/longbool/status/1219438349527724032 …
I am only about two page scrolls down and already nodding along. The most recent iteration of my personal rendering abstraction follows the same 3 needs (and nothing more!).
Overall I agree with his wrapping up points. His code is a bit oopier than I care for, but that matters little. The spicy hot takes are interesting...
RE: Render graphs moistly suck -- I've never attempted to precompile them, but reordering and queue submissions decisions absolutely.
RE: Meta command buffers -- I've not found them terrible to debug, and I do things to actively make it easier. 1, every command gets a name. 2, I have my own validation of my API which helps define the contracts between the frontend and backend.
After only a few validations per command, you start to catch everything in the stack anyway.
RE: Leave HLSL alone -- Yeah pretty much. In fact, I try to not let the abstraction say much about the shader blobs anyway. It does, however, makes it hard to support API specific things like push-constants, or deal with differences in resource binding.
I think to have anymore opinions, I'd have to see more code. I almost wrote out my reactions to specific parts of the post, but realized enough of it could be saying the same thing a different way.
Twitter saattaa olla ruuhkautunut tai ongelma on muuten hetkellinen. Yritä uudelleen tai käy Twitterin tilasivulla saadaksesi lisätietoja.
