I have been asking for years for per-hardware APIs. I don't know how to make that happen. One nVidia API, one AMD API, and one Intel API is what we want. We may get that on Apple, sort of, since they are obviously moving to their own chips (CPU definitely, GPU presumably?)
-
This Tweet is unavailable.
-
-
What exactly do you think you will get from that over Vulkan + Extensions? Exposing raw ISA is out of the question.
1 reply 0 retweets 1 like -
Replying to @axelgneiting @cmuratori and
Main thing that comes to my mind is lower level memory barriers / flushes / decompression control which might make code/intent a bit clearer. Is that worth having vendor specific APIs vs a bit more verbosity in DX/Vk?
1 reply 0 retweets 0 likes -
-
Replying to @relativetoyou @axelgneiting and
Actually there is a lot more than that. In an ideal graphics API, the data format is completely specified, so there are no API calls besides kickoffs, polls, and waits. Vulkan/D3D12 are nowhere close to this ideal. They are a function spec not a data spec.
3 replies 1 retweet 1 like -
Replying to @cmuratori @relativetoyou and
AMD and Intel already do this. They have low level data specifications, but you can't expect to have *one* for each vendor; you get one for each device. The result of open source communities writing common low level abstractions over these specifications is the GPU drivers :)
1 reply 0 retweets 0 likes -
Replying to @BrookeHodgman @relativetoyou and
I absolutely can, and do, expect it. If they want to change the data format every ~2-3 years, be my guest, I can support many different output formats. In the meantime, the driver is welcome to mutate my data as it sees fit for forwards/backwards compatibility.
1 reply 1 retweet 1 like -
Replying to @cmuratori @BrookeHodgman and
This is not substantially different from what they do now, since they do all the stuff behind my back anyway, just on a per-function call basis. For all we know, it might even be _more_ efficient to do back/forward-compat on whole buffers of invocation than per-function.
1 reply 1 retweet 1 like -
Replying to @cmuratori @BrookeHodgman and
The difference, though, is on the cards I _am_ aware of, I can pass data properly that needs no molestation and that keeps driver participation to a minimum - no thread problems, no API versioning problems, no binding issues, no hiccups, no lazy eval at the wrong times.
1 reply 1 retweet 1 like
Plus now the driver can see everything I was going to do, rather than having to either a) guess or b) buffer up all my API calls anyway so it can analyze them for patterns later. I should think driver authors would _prefer_ this, actually, because it gives them more opt ability!
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.