Regenerate with SPIRV-Headers sdk-1.2.198 #226
Conversation
|
I really don't remember if we should update |
|
I noticed that (sorry my finger slipped..) |
|
@msiglreith I think with "module header" you are referring to It seems this operand best fits the constants, it's not really a type but simply representing a constant Any other such ops I should be aware of? Seems there's a lot of new spec to go through :( |
|
Actually, a type is better since this operand doesn't have a |
Looking trough the latest extensions since the raytracing stuff, I didn't see something requiring special attention so far.
IMO this instruction requires a bit of special treatment similar to |
|
@msiglreith Looks like You're right that this requires more changes - seems I only updated the data-representation builder part but not the loader/parser in |
This op is not a normal instruction nor does it fit any of the other categories such as a constant or type. Ignore it for now and allow someone to make a custom implementation down the line. gfx-rs#226 (comment)
This op is not a normal instruction nor does it fit any of the other categories such as a constant or type. Ignore it for now and allow someone to make a custom implementation down the line. gfx-rs#226 (comment)
This op is not a normal instruction nor does it fit any of the other categories such as a constant or type. Ignore it for now and allow someone to make a custom implementation down the line. gfx-rs#226 (comment)
|
@msiglreith Completely ignoring the type for now. Shall we get #223 in and then get this PR on top? |
|
Does this pass the clippy checks introduced in #223? |
This op is not a normal instruction nor does it fit any of the other categories such as a constant or type. Ignore it for now and allow someone to make a custom implementation down the line. gfx-rs#226 (comment)
|
@msiglreith Yeah it does, I just wanted to make sure that both PRs were merged separately :) |
Since inheriting the `spirv` crate and dropping the `spirv_headers` crate in #204, and following up on a choice in #197 to no longer have the SPIR-V major/minor version in our crate version which disallows us from making any breaking changes to the crate, we reset the version to `0.1.0` and embedded the SPIR-V version via _version metadata_ instead. This stale comment in the README was still indicating as such though, confusing users in e.g. #252 that our `spirv` crate was somehow exposing SPIR-V 1.3 (should have been 0.3 by that logic which is the current latest version). Remove it entirely. Note also that since #225 / #226 our version metadata is no longer the SPIR-V version/revision but the Vulkan SDK tag that it was released with. The SPIR-V version isn't bumped often enough to match extensions in new SDK releases, making the SDK tag more indicative of the included API surface instead.
No description provided.