Comments (13)
No, evaluating/running the SPIR-V module is not on my plate in the foreseeable future. :) I'm basically only interested at the IL level (SPIR-V and its manipulation, optimization, validation, etc.) and up (frond-end language GLSL/HLSL compilation to SPIR-V).
Evaluating/running SPIR-V modules requires Vulkan environment set up. That's a whole lot of new stuff to handle (managing resources, etc.). vulkano comes into the picture here but it's real GPU backed; I cannot only run a single shader for, like, geometry stage. You'll have to set up the whole pipeline. A software implementation of Vulkan is more handy for this case. So cendre is naturally more aligned to that purpose.
But I'd definitely like to help on my rspirv side if you'd like some new features. :)
from rspirv.
Looking from http://llvm.org/docs/tutorial/BuildingAJIT1.html, writing a JIT compiler seems manageable. I'll have to write some C++ I think, though. The more difficult part would be to convert SPIR-V to LLVM IT, I think. https://github.com/KhronosGroup/SPIRV-LLVM seems to be able to do that, so it could be included in this crate ;)
from rspirv.
Ah, I didn't see your edited text previously. Sorry.
Now that sounds interesting to me. But going through SPIRV-LLVM may not be the way I'd prefer. As indicted in KhronosGroup/SPIRV-LLVM#202, SPIRV-LLVM makes assumptions of the OpenGL environment, and it is a little bit difficult to add Vulkan backend to it. Actually I do intend to write a SPIR-V to LLVM translator from the very beginning of this project (see README.md). And there are several llvm library bindings existing on creates.io. I just need to traverse the memory representation defined in this crate and call into llvm builders in the Rust bindings and generate LLVM IRs. Seems doable. :) (Yep, I know there will be lots of obstacles along the way, e.g., structured control flow, storage class, etc.) I'll take on it then!
from rspirv.
Sorry, wrong phrasing: I didn't meant to include spirv-llvm in rspirv, I meant to add a spirv-llvm IR converter to rspirv ^^
I'm motivated to work on it, since I'll have to do it anyway for cendre, so we could do it together.
from rspirv.
Yep, definitely!
from rspirv.
As I see it, we can either do a direct mr::Module
-> LLVM IR transformation, or first transform mr::Module
to a tree IR and then convert it to LLVM's one. What do you prefer?
from rspirv.
@Yamakaky: sorry for the late reply. I think first translating the current representation into a new structured IR would be the preferred way. The current memory representation is essentially just a data representation, without any interconnections between various instructions. It is not convenient to use for future tasks like validation (cendre would also need this to sanitize the input I think), optimization, etc. I've been wanting to add such a new representation for translating front end language, too. So multiple future tasks would benefit from it. It would be nice to go that way.
I'll write up my thinking about the new structured representation and also how to translate various SPIR-V instructions in LLVM in two new issues and we can discuss there. :)
from rspirv.
In fact, there are a lot of things I don't have to check. See https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#shader-modules, "Valid Usage" section. There are layers (provided by khronos) that verify the correct usage of the API, including SPIR-V shaders.
I agree for the rest.
from rspirv.
I'm starting with the types.
from rspirv.
@Yamakaky: right, the driver is allowed to crash on spotting invalid usages of the API and also SPIR-V. However I would think if we can do more than just crashing in cendre it would be quite helpful for developers. A software implementation of Vulkan is more flexible; if it can print more diagnostics and pinpoint exactly what is wrong with my shaders that would be awesome for me as a developer.
from rspirv.
The driver don't have to verify it because you can enable validation layers during testing. See https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/loader/LoaderAndLayerInterface.md#layer-library-interface.
from rspirv.
@Yamakaky: Yep, you are right.
However, current existing validation layers are basically for catching API usage errors. SPIR-V validation is mainly done via spirv-val in SPIRV-Tools. AFAIK, there is no validation layer wrapping around spirv-val to provide SPIR-V validation to Vulkan devs yet.
My previous suggestion was to integrate the SPIR-V validation inside cendre, which could provide more detailed useful information when something goes wrong. (And that can be turned on with some options maybe.) But on a second thought, this indeed goes against Vulkan's layered design. And SPIR-V validation should be no difference with API usage validation. It should be outsourced to its dedicated layer. :)
Another benefit that can be provided by cendre but not from validation layers may be inspecting internal running status of SPIR-V (e.g., to know the values of various variables in my SPIR-V at a certain point of execution) for debugging purposes. Since that requires dynamic information.
Forgive me for throwing random thoughts on how cendre should evolve. I just feel that it has great potential to improve dev experiences from various points. :)
from rspirv.
Fun fact: we also can do a validation layer around rspirv ;) Like the object lifetime layer, it could keep track of dynamic information. Indeed, that would be a nice addition to the vulkan dev toolkit.
Please continue suggesting thinks for cendre, including issues.
from rspirv.
Related Issues (20)
- Floating-point literals should store bits in integers, not use host f32/f64. HOT 2
- New spirv_headers release HOT 1
- ImageFormat::Rgb10a2ui uses inconsistent casing. HOT 4
- Published 1.5.1 broke public API HOT 8
- Switch spirv_headers to SemVer HOT 5
- Rename "required_capabilities" for clarity
- `IdResult` and `IdResultType` on SR?
- Publish rspirv 0.8 ? HOT 1
- LiftContext::convert struggles with linked multi-stage SPIRV
- Unable to retrieve decorations in structured representation HOT 3
- Store all instructions in one `Vec`?
- LiftContext::lift_op responsible for ~25% of the generated llvm ir
- spirv: Vulkan SDK based versioning HOT 6
- Disassembling constant literals is broken HOT 2
- LICENSE files in package subdirs HOT 3
- Update spirv's version of bitflags to 1.0.4
- Multiple operations with same opcode HOT 4
- Bug: selection_merge ends block.
- Release `spirv:0.3.0+sdk-1.3.243.0` not on crates.io HOT 17
- Removal of `FromPrimitive` in enums broke instruction parsing in spirq HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rspirv.