https://futureofcoding.org/ logo
Join Slack
Powered by
“How much should it cost to do graphics?” — Jonath...
# of-graphics
s
“How much should it cost to do graphics?” — Jonathan Blow and Bennett replay one of our favorite discussions: https://twitter.com/Jonathan_Blow/status/1255724297399627776 This is the leaf tweet of a discussion on Twitter. How do you link to a specific branch of a tree of tweets? Like so?
i
Yeah, I've yet to see a good way to review a whole tweet conversation tree. But this thread was tasty.
w
As @EthanIClark1 said, "As troll-y as Bennet's reply is, he has a point: HTML is probably the simplest/fastest way to make something that renders on most modern devices." How did we go so wrong? 😱
c
One massive thing missing from basically all OS's is a "stdcanvas" or "stdpaint" to go with stdin, stderr, stdin. How come 
print('hello world')
is possible in every language but 
draw('circle', 10)
is hours of configuration and/or dozens of lines of code
☝️ 4
💯 2
The appeal of Electron et al is the standardisation and immediacy; the mountain of hacks beneath is far secondary to this
s
One of Jon Blow's major complaints is that he wants the lowest level (but I guess not too complex?) possible access to hardware. He might be happy with stdframebuffer that gave framebuffer access, he would not be happy at all with a stdcanvas that emulated canvas2d on the web or Processing or whatever
In fact he blocked people in that thread for suggesting that canvas (html5 version) was a reasonable way to get graphics on screen with little code
🙄 1
And got into a battle with Angelo Pesce (tech director at Roblox and one of the more respected graphics engineers in the industry), mostly over semantics and pedantic shit (Angelo was trolling him)
So there are some problems that are created by vendor politics and lock in (problems that people believe would be solved if Apple supported Vulkan)
But regardless it doesn't fix his main complaint, that modern graphics APIs are complex
Vulkan needs 1000 lines for hello triangle
Etc
Some of that is because modern GPU hardware is really complex, some of it is overly complex API design . Vulkan with a few sane defaults that are optionally changeable would fix some of that, but that's also been a major source of headache in past APIs due to poor implementation or other reasons
When him and Casey Muratori go on these rants, what I really think is they probably should redesign the whole stack to be simpler, I see some people doing parts of that, that's the explicit goal of projects of some members of this group
👍 2
Like maybe Jon should make a BlowBox, that runs a custom minimal OS, and everything is written in Jai
😀 2
And he kick starts it with Braid, the Witness and his new game as launch titles? IDK, I empathize with the frustration around complexity in various software stacks, I think some of that is actually driven by hardware complexity, but now the options are either add more abstractions (which he is strongly against) or throw everything out and start over
c
I would wager that a very large amount of the complexity in the modern graphics stack is necessary to support performance.
I would generally be on the side of sacrificing performance for an understandable stack, but JB seems to suggest that there's no tradeoff, you can have both and the only reason things are complicated is because everyone is an idiot except him
s
Well at some point you have an actual hardware interface that represents some subset of features that are widely represented in hardware, those features might not be implemented in hardware for all hardware, and are probably an abstraction, but a low level one
Something like draw circle is very high level, it's not an operation that GPUs have natively
Although certainly some hardware has probably supported draw circle
(maybe an old-school 8-bit computer or some embedded thing or console)
But the actual implementation of draw circle in most environments is do it on the CPU and upload as a texture, and render it as two textures triangles
Or maybe draw it as a tesselated triangle list, also probably generated on the CPU
There are many other ways to do it, but they're all not directly interfacing with the hardware, I think Blow's point is that the lowest level interface to the hardware should be simple and work across platforms and maybe hardware implementations reasonably well, which implies abstraction but maybe something more minimal or direct than what we have? No idea
🤔 1
s
I think Blow is mainly nostalgic about a past of standardization in graphics APIs perceived as almost working (which was an illusion mostly based on a Windows monopoly and long-term console release cycles), which we left when Mobile started to take off and OpenGL couldn’t catch up with innovation in graphics hardware anymore. You can only have standards when the underlying technology is relatively stable and there isn’t much demand for change. That’s not where we are in graphics now. There’s too much going on and everyone tries to differentiate so standardization just isn’t a priority at the moment. That’s bad for us developers, who don’t necessarily care about the differentiating factors and who just want to reach the broadest possible audience. We can complain about it, or we can accept these dynamics and enjoy the diversity of different approaches and design decisions being made and pick the one that best suits our needs.
s
His nostalgia seems to go back to before then when mov ax, 13h int 10 (or thr C64 equivalent) was all you needed to start graphics
He doesn't seem nostalgic for GL 1.1 style graphics although certainly mainly people are
😀 2
It's funny because I think eventually we'll settle there
The GPU will be a relatively complex multiprocessor system, perhaps with some fixed function units for rasterization, texture sampling, wide low precision matrix multiplication (ML/DL), video decode and encode and raytracing
But the graphics pipeline will mostly go away and be replaced with something that looks like a combination of mesh and rayshader pipelines
Spawn threads that spawn other threads and occasionally generate work for fixed function hardware
Tessellation and geometry shaders will definitely go away in future graphics APIs, but one day vertex shaders might be gone also
🤔 1
It will be interesting to see where GPUs go in 15-20 years
w
I'll be surprised to find any notion of threads.
s
So are you saying GPUs will be single threaded?
Or move away from SPMD?
g
I don't agree with Blow's point and I think he's hypocritical. He thinks there should be one way to talk graphics but he doesn't think there should be one way to make games. If there is one true graphics API (meaning a committee of people arguing forever and coming up with compromises and less the perfect solutions for trying to abstract across hardware) then the same logic applies elsewhere. There should be one assembly language and one processor design. There should be one higher level language. There should be one game engine. Etc... The fact is GPU hardware is actually different with different features and tradeoffs. The biggest different might be tiled renderers vs non tiled but even AMD vs NVidia there are vast differences in whats going on underneath so there are abstractions (Metal, DirectX, Vulkan) all of which make different tradeoffs (passing differences in hardware back up to the dev or hiding the differences). Further there are 8 billion people on the planet. The reason there are multiple APIs is because you can't possible get 8 billion people to all work and coordinate on the same thing in any reasonably efficient manner. So, different people have different ideas of what's best hence someone came up with Vulkan, different people came up with Metal, others came up with DirectX etc...
👍 2
i
Yeah, it's not like we use UDP for everything.
2 Views
Open in Slack
PreviousNext
Powered by