I think they should work to fix the actual problem, which is that browsers are lame.
-
-
Replying to @Jonathan_Blow
Okay so if nobody should work on abstracting GPU APIs in browsers, what about native? Given current APIs as fixed, do you endorse efforts to try to write a hardened abstraction over them, or just give up and everyone writes for each platform manually?
1 reply 0 retweets 5 likes -
Replying to @trishume
I think we should do what we did in the 1970s, which worked much better than what we are doing today.
1 reply 0 retweets 6 likes -
Replying to @Jonathan_Blow
But that's not an option if I want to program GPUs today. I want a CPU-style toolchain straight to machine code for major GPUs cross-platform too. But that's not an option unless I form a decade-long conspiracy of friends to become execs at Apple, MSFT, AMD, Intel, Nvidia...
2 replies 0 retweets 16 likes -
Replying to @trishume
Somebody has to be the adult in the room or things will continue to get worse.
1 reply 0 retweets 3 likes -
Replying to @Jonathan_Blow
Like which concrete people do you want to do what concrete action? Everyone should stop working on GPU stuff until execs pay attention to the strike? Just everyone complain on Twitter? Anyone who wants to use a GPU should try to become a MSFT GPU exec instead?
2 replies 0 retweets 11 likes -
Replying to @trishume
Know what’s extremely off-putting? Learned helplessness. Don’t be helpless.
1 reply 0 retweets 7 likes -
Replying to @Jonathan_Blow
I already mentioned one of the two plans to a new driver equilibrium I think have a smidge of hope, the other being try to piggy-back off of WebGPU momentum and then work down unifying drivers from there. I'm interested in how you think we might get there. What's your plan?
2 replies 0 retweets 6 likes -
Replying to @trishume
There are many possibilities. One is, build the thing. Build a pretend instruction set that is at a low level such that it would be targetable by any high-level language. Do a pass for LLVM that outputs to this. Then do all the gross garbage that up-translates this to
3 replies 0 retweets 7 likes -
Replying to @Jonathan_Blow @trishume
all the various shading languages. In the short term this is just another sucky shader language, but at least now it's at the right level of abstraction, so someone can do driver-level support in Linux, for example, then continue from there.
4 replies 0 retweets 6 likes
The representation could be an already-existing one (e.g. SPIR-V if you think that is okay), or a modification of that, if judged to be good enough. But the point is to push the ball in the right direction instead of the wrong direction.
-
-
Replying to @Jonathan_Blow @trishume
I am suspicious of SPIR-V (look at all the weird special hardcoded stuff that's in there already), but have not used it so won't comment.
1 reply 0 retweets 0 likes -
Replying to @Jonathan_Blow @trishume
The design goal of WGSL is that conversion to/from SPIR-V should be straightforward and lossless. We at least got Apple to not object to that. And then it has the gross garbage that up-translates that to all the various shading languages.
1 reply 0 retweets 0 likes - Show replies
New conversation -
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.