Is there a way to inspect uniforms (e.g. sizes, strides, offsets) within a uniform buffer? about spirv_cross HOT 13 CLOSED

Thanks for the prompt reply. If I get a chance I'll take a closer look at the internals. If I start looking in earnest I'll assign this issue to myself to avoid duplication. Cheers!

EDIT: Ah, yes, I won't be able to assign it. I'll just comment here instead.

from spirv_cross.

I started adding some member reflection in #44 (the diff has some unrelated changes, you can ignore them).

For now I have get member names and get/set member decorations for uniform buffer members, so I believe you should be able to get strides/offsets with these changes. Is that sufficient for what you're trying to do?

from spirv_cross.

To get the number of members, I believe we will just need to expose member_types on Type::Struct (mapped directly from the C++ side), so member_types.len() will give us the member count (see comment in KhronosGroup/SPIRV-Cross#49). This should be relatively straightforward.

For the second point, we'll just need to add the binding for get_declared_struct_size which should also be straightforward.

from spirv_cross.

@StrayLightning Sorry for the long delay! If you're still interested in this, the changes in #53 should address the points you mentioned

from spirv_cross.

Ah, thank you. I shall try to get back to it soon, as I am still interested. I have been distracted by other stuff recently.

from spirv_cross.

Yeah, sounds good to me! The enum is just meant to limit the visibility of fields from SPIRType which don't apply to all of the enum variants. But we could always expose a struct instead if it becomes an issue.

from spirv_cross.

Hi! This is possible in the C++ SPIRV-Cross API that we use (see example usage), but I don't think we've created a Rust wrapper for the member methods yet. Some of the C++ API hasn't been wrapped yet (at the moment we've usually expanded the wrappers whenever gfx-rs needs them).

The relevant part of the C++ API should be the *member* methods listed on the base Compiler class (or whichever methods are interesting for your use case). Feel free to submit a pull request if you'd like to try adding a wrapper for any of these methods (following the pattern we use for similar methods), otherwise I can try to take a look soon.

from spirv_cross.

Thanks. I shall have a go at getting the strides etc out of my shaders.

from spirv_cross.

Thanks again. I can query uniform block members and their decorations now, but it's not clear to me how to get the number of members in the block.

The other thing I would like to get is the overall size of the uniform block, i.e. get_declared_struct_size(type).

I shall try and take another look when I get a chance.

from spirv_cross.

Thanks, that great! I've used this in StrayLightning/aeolius@ed0198515444e86b10892e766e50c11455afb7c0. I feel like I should look at adding the array field of the SPIRV-Cross SPIRType, which is the last piece of the puzzle that I currently rely on. I have taken a look at f7e07fa: Pattern matching this ought to be fairly easy. But unlike member_types, which only applies to structs, array applies to everything apart from Unknown and Void.

So, for example, my proposed from_raw() implementation in compiler.rs might look like:

impl spirv::Type {
    pub fn from_raw(ty: spirv_cross::SPIRType_BaseType, member_types: Vec<u32>, array: Vec<u32>) -> Type {
        use bindings::root::spirv_cross::SPIRType_BaseType as b;
        use spirv::Type::*;
        match ty {
            b::Unknown => Unknown,
            b::Void => Void,
            b::Boolean => Boolean { array },
            b::Char => Char { array },
            b::Int => Int { array },
            b::UInt => UInt { array },
            b::Int64 => Int64 { array },
            b::UInt64 => UInt64 { array },
            b::AtomicCounter => AtomicCounter { array },
            b::Float => Float { array },
            b::Double => Double { array },
            b::Struct => Struct { member_types, array },
            b::Image => Image { array },
            b::SampledImage => SampledImage { array },
            b::Sampler => Sampler { array },
        }
    }
}

Is that the correct approach to take?

from spirv_cross.

Just a quick update on progress: I've got a commit that surfaces SPIRType array. It's a breaking change, and I'd like to think of ways around this. Although I've updated the unit tests, it requires some more coverage. I might push to my fork this evening, but possibly won't submit it as a formal PR just yet.

from spirv_cross.

Great, glad you were able to figure it out!

I'm fine with breaking changes at this point, especially if they're easy to fix -- I'll just release another minor version (this crate isn't used too widely yet, mostly with gfx).

from spirv_cross.

The merge of PR #58 addresses the remaining desired functionality: Closing this issue.

Thanks!

from spirv_cross.