4 ms·
As soon as you clear up that GPU bottleneck guess what's going to be your next one? (Here's a hint, it's the thing that's dispatching to your GPU). Another asp
by vvanders 10y ago
As soon as you clear up that GPU bottleneck guess what's going to be your next one? (Here's a hint, it's the thing that's dispatching to your GPU).
Another aspect that scares me about this is the security implications of exposing compute to the browser. Esp when you start talking about unified memory architectures. There's been more than a few exploits from a clever soul calling glReadPixels in the right circumstances. Increasing the surface area here doesn't seem like a great idea. Shader compilers are also great targets for instability and obscure bugs.
- JoshTriplett 10y ago> As soon as you clear up that GPU bottleneck guess what's going to be your next one? Memory bandwidth for your textures, geometry, and other data, quite often. Or nothing at all, if you can successfully reach your desired target framerate. But if CPU turns out to be an issue, that's what WebAssembly is for.
- vvanders 10y ago> Memory bandwidth for your textures, geometry, and other data, quite often. So in other words a GPU bottleneck?
- JoshTriplett 10y agoNo, a memory bottleneck. (That may be GPU memory or system memory, depending on the architecture of your graphics stack.) That's not the same as a GPU processing bottleneck. You can have a bottleneck in GPU processing, or a bottleneck in getting enough data to the GPU.
- vvanders 10y agoOh I see, we're getting pedantic over semantics. If your GPU is designed with a small bus between system and GPU memory, that's still a GPU issue. You could make the same argument on the CPU side for caches and DRAM if you want to go that far. I appreciate the education lesson but I think you'll find most graphics programmers will consider it a GPU problem :). At the end of the day though here's the thing. The intersection of users that have a GPU capable of discrete pipelines, compute shaders and all the other things that make this interesting but won't go through the effort of installing a native app is relatively small. You can't polyfill(otherwise why use the GPU in the first place?) on the users don't have a cutting edge machine so you're going to have a swath of people that your WebApp won't work for. From a value proposition it just doesn't make sense.
- JoshTriplett 10y agoThe reason for the distinction is that that's one of the specific things Vulkan helps with: keeping the GPU well-fed with work to do. (Also, keep in mind the architectural differences between integrated graphics and discrete graphics.) You potentially can polyfill, if you have a graphics engine with a higher-performance Vulkan/WebVulkan backend and a lower-performance GL/GLES/WebGL backend. The Vulkan version will make better use of resources and allow you to turn up the quality higher while still hitting the all-important framerate targets. All the same problems apply just as much if you go native as if you go web. You either have to work with older APIs (often via an engine), or write off older GPUs and some subset of users. Whether you can do that depends on what you're doing.
- jolux 10y ago>You can't polyfill(otherwise why use the GPU in the first place?) on the users don't have a cutting edge machine so you're going to have a swath of people that your WebApp won't work for. I'm pretty sure you just argued in favor of creating a new API instead of using Vulkan...
- om2 10y agoModern graphics APIs help you reduce the CPU bottleneck for CPU-bound graphics code. Parallelism, command buffers and generally thinner drivers all help reduce the CPU overhead.
- JoshTriplett 10y agoExactly. They also help you keep the GPU saturated, and minimize round-trips between the GPU and CPU.