alex/vello
1
0
Fork 0
mirror of https://github.com/italicsjenga/vello.git synced 2024-10-17 15:01:31 +11:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #22 from kant/patch-1

Browse source 
Minor fix on paragraph 35
This commit is contained in:
Raph Levien 2020-06-29 07:21:59 -07:00 committed by GitHub
parent 258bf6890a 9b87de055f
commit 46d0e7cea2
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
README.md
View file

@ -32,7 +32,7 @@ A more detailed explanation will come. But for now, a few notes.
It makes a lot of sense to use gfx-hal, as it addresses the ability to write kernel and runtime code once and run it portably. But in exploring it I've found some points of friction, especially in using more "advanced" features. To serve the research goals, I'm enjoying using Vulkan directly, through [ash], which I've found does a good job tracking Vulkan releases. One example is experimenting with `VK_EXT_subgroup_size_control`.
The hal layer in this repo is strongly inspired by gfx-hal, but with some differences. One is that we're shooting for a compile-time pipeline to generate GPU IR on DX12 and Metal, while gfx-hal ships [SPIRV-Cross] in the runtime. To access [Shader Model 6], that would also require bundling [DXC] at runtime, which is not yet implemeted (though it's certainly possible).
The hal layer in this repo is strongly inspired by gfx-hal, but with some differences. One is that we're shooting for a compile-time pipeline to generate GPU IR on DX12 and Metal, while gfx-hal ships [SPIRV-Cross] in the runtime. To access [Shader Model 6], that would also require bundling [DXC] at runtime, which is not yet implemented (though it's certainly possible).
### Why not wgpu?