Spencer Fricke

@aleksandar-todorovic I finally got around to working on this repo, I have worked a lot with both Awesome-WebGL and Awesome-Vulkan and would be happy to keep this on tabs and...

@aleksandar-todorovic ^

@wolfviking0 I actually was in need of blend shapes for another project of mind, I took this project template and adjusted it with implementation for blend shapes https://github.com/sjfricke/Vulkan-glTF-Morph-Target

> but not having to handle fallback paths would keep the entire stack (compiler + runtime) simpler. So something I haven't seen explicitly spelled out anywhere is what is the...

> Falling back from GPU to CPU is currently left up to applications to handle. If I have a device with only 1.0 Vulkan, IREE will fail to create a...

> I'm not sure I follow what you're getting at? So if there are the required extensions, and 1.1 and 1.2 only difference is just wrapping some ext to core...

> it's not good to have a lot of difficult to test code around extension management So for `timelineSemaphore` sure that can be assumed on 1.2, but if you want...

> Are you arguing that we should support Vulkan 1.0 That is a fair counter argument > here's definite tradeoffs here / I'm not sure I know what you're expecting?...

**My personal opinion/inference** is that when 1.0 came out, there were formats (ASTC/ETC/BC) that not everyone would support, but wanted to be part of "core Vulkan" and so the original...

So the original goal of this chapter was to answer the last section question of `## Pushing data with non-compatible layouts`... the internal issue hit many problems and wasn't much...