You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I ran into this while upgrading an old project to vulkano 0.29. This code fails to compile because the generated motion_shader::ty::Agent doesn't implement bytemuck::Pod. Here's the types generated by the shader macro:
In this case, it seems logical that Agent should implement Pod (and Zeroable), and it's initially very surprising that shader-defined types can't be used in a CpuAccessibleBuffer. Of course the types are actually defined by macro-generated rust code, but the intuition is that they're defined in the shader itself.
Manually adding the impls is a good workaround and works:
but requires adding a dependency on bytemuck myself, and it's the weird sort of dependency that has to match the version depended on by a different dependency. Unfortunately the types_meta option of the shader macro doesn't work either since these are unsafe impls, which aren't recognized by the macro.
Manually implementing BufferContents for Data would work as well, but that requires writing a bunch of error-prone code and shouldn't be necessary.
A few possible improvements I can think of:
Re-export Pod and Zeroable from vulkano to avoid needing to take another dependency
Adding the ability to impl unsafe traits (or maybe just Pod and Zeroable in particular) via the types_meta option of the shader macro
Document this unexpected behavior, and how to get it to work, on either vulkano-shaders or the CpuAccessibleBuffer type in vulkano (or both) - or maybe even provide an example demonstrating this scenario.
The text was updated successfully, but these errors were encountered:
I agree that modifying the shader! macro would be ideal, but I note that I have been able to use #[derive(Zeroable, Pod)] in the types_meta for my shaders without issue. I think that is the current best approach to solving this problem.
I agree that re-exporting the Bytemuck macros would be ideal, but unfortunately I ran into Lokathor/bytemuck#93 when I tried. I can see about automatically adding these traits though.
main.rs
file that demonstrates the issue:Issue
I ran into this while upgrading an old project to vulkano 0.29. This code fails to compile because the generated
motion_shader::ty::Agent
doesn't implementbytemuck::Pod
. Here's the types generated by the shader macro:In this case, it seems logical that
Agent
should implementPod
(andZeroable
), and it's initially very surprising that shader-defined types can't be used in aCpuAccessibleBuffer
. Of course the types are actually defined by macro-generated rust code, but the intuition is that they're defined in the shader itself.Manually adding the impls is a good workaround and works:
but requires adding a dependency on
bytemuck
myself, and it's the weird sort of dependency that has to match the version depended on by a different dependency. Unfortunately thetypes_meta
option of theshader
macro doesn't work either since these are unsafe impls, which aren't recognized by the macro.Manually implementing
BufferContents
forData
would work as well, but that requires writing a bunch of error-prone code and shouldn't be necessary.A few possible improvements I can think of:
Pod
andZeroable
fromvulkano
to avoid needing to take another dependencyPod
andZeroable
in particular) via thetypes_meta
option of the shader macrovulkano-shaders
or theCpuAccessibleBuffer
type invulkano
(or both) - or maybe even provide an example demonstrating this scenario.The text was updated successfully, but these errors were encountered: