3 ms·
> In the increasingly multi-core world you desperately want as much concurrent processing as possible and it's much easier to run several clients in parallel th
by sprash 7y ago
> In the increasingly multi-core world you desperately want as much concurrent processing as possible and it's much easier to run several clients in parallel than it is to parallelize a single server.
There is nothing more multi-core than a modern GPU. Actually the existence of modern GPUs is an argument FOR toolkit-in-server windowing systems. All you do is writing shaders that help you to keep the communication over the PCIe bus (and potentially network, if you want network transparency) as minimal as possible.
The NeWS system failed for none of the reasons described in the article. It failed because of bad performance. There never was custom silicon out there to render Postscript. Unlike today where you have vastly underused GPUs at your disposable just waiting to be stuffed with intelligence in form of shaders. Just have a look at https://shadertoy.com https://shadertoy.com to see what is possible even on low-end GPUs.
Edit: as cpach pointed out shadertoy.com and not .org
- cpach 7y agoI think you meant shadertoy.com, right? :)
- fulafel 7y agoIn modern graphics applications (=games) people do try to reduce CPU-GPU communication, but it is still done a lot and is frequently a bottleneck. Increasing GPGPU work means CPU and GPU code communicate in both directions. Making it slower than it already is doesn't make sense from performance engineering POV unless there are some dramatic advantages from the tradeoff.
- sprash 7y ago> Increasing GPGPU work means CPU and GPU code communicate in both directions. Only if you make the wrong abstractions. Using a shader based toolkit is not about increasing the GPGPU work but to use the GPU for things that it is intended to do namely drawing. And if you make the right abstractions you can severely reduce CPU-GPU communications. In fact a toolkit is exactly the perfect type of abstraction in that scenario. Most of the input is mouse and keyboard data and a bunch of drawing commands which means extremely low bandwidth, less CPU-GPU communication, more performance and faster applications. I'm not sure what you mean by "tradeoff". Look for example at the shaders of sahdertoy. For the most part the only data they receive from the CPU is a timestamp of the current frame and occasionally mouse and keyboard data which is in the worst case literally just a bunch of bytes per frame.
- fulafel 7y agoShadertoy is pretty far removed from actual games. Both in tje problem domain and technological complexity, not to mention the time capsule of webgl. I'm not sure what you mean by shader based toolkit. Anyway in games the GPU is not just for graphics anymore (since many years) and this naturally leads to tight coupling.
- gnufx 7y agoI didn't notice performance was a problem on something like a SPARCstation 1+, though it was definitely slower than the blindingly-fast GEC4000-driven vector displays we needed to replace.