3 ms·

Oh 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 ma

Oh 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 ago
The 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...

JoshTriplett 10y ago

The 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...