Are there any types you'd like to serialize that are in wgpu-rs as opposed to wgpu-types? Having serde feature would conflict with depending on servo in this case.

also, this would probably need to include "wgc/serde" as well

@kvark assuming you meant serde instead of servo, I think we can do have both serde as a feature and a dependency using the same strategy we use in wgpu-types (rust-lang/api-guidelines#180 (comment))

Fortunately, I don't think this is going to be a problem, see gfx-rs/wgpu#619

Are there any types you'd like to serialize that are in wgpu-rs as opposed to wgpu-types? Having serde feature would conflict with depending on servo in this case.

In my usecase I have a material description file that is very close to the pipeline. Like required primitive_topology, some settings for the color_stage, vertex attribute that can be turned into
RenderPipeline. Without the serde feature I'd have to duplicate all these types and write some wrappers and/or From implementations.

To be more specific:
geometry read from file (ex FBX, obj etc) has a vertex format desc, like: Position(Float3, offset), Normal(Float3, offset), etc.
Material(pipeline) has shader descriptions, binding info, uniforms, etc.

In the "engine" there is a map from (material + vertex_format) -> RenderPipeline. During the population of this map the pipeline requirements and vertex formats are matched and thus the same geometry can be used for multiple pipeline. And the connection (binding) b/n the pipeline and geometry is mostly automatic:

let m = materials::<VertexPos2Normal3>::create("Z-pass").
let command_buffer = m.render(encoder, geometry_with_pos2_norm3);

I've wanted to (de)serialize BindGroupLayoutEntry.
Although I wonder why it isn't part of wgpu-types in the first place.

we may ask @grovesNL . In general, only those types go into wgpu-types that can be re-used directly for the Web target.

wgpu-rs defines its own BindGroupLayoutEntry, so we shouldn't need to share the BindGroupLayoutEntry from wgpu-core