Skip to content
This repository has been archived by the owner on Oct 22, 2020. It is now read-only.

New syntax for entry points #26

Closed
MaikKlein opened this issue Feb 12, 2018 · 1 comment
Closed

New syntax for entry points #26

MaikKlein opened this issue Feb 12, 2018 · 1 comment

Comments

@MaikKlein
Copy link
Owner

MaikKlein commented Feb 12, 2018

The current syntax is just a proof of concept but it is missing a lot of information. Two options come to mind

We use a macro. This macro then generates some code under the hood so that RLSL can retrieve the necessary information.

vertex!(
    input(location=0) pos_in: Vec4<f32>,
    input(location=1) color_in: Vec4<f32>,
    uniform(set = 0, binding = 0) foo: Foo,
    output(location=0, flat) mut color: Vec4<f32>,
    output(location=1) mut color: Vec4<f32>, // smooth default
    output(location=2, noperspective) mut color2: Vec4<f32> {
    }
)

Because macros are severally limited, so we pass everything explicitly with types. Alternatively I could generate many custom attributes with a proc_macro.

The more explicit alternative would be.

type VertexOut =(Output<Flat, 0, Vec4<f32>>,
                 Output<1, Vec4<f32>>,
                 Output<NoPersp, 2, Vec4<f32>>);

#[spirv(vertex)]
fn vertex(pos_in: Input<0, Vec4<f32>>,
          color_in: Input<1, Vec4<f32>>,
          foo: Descriptor<0, 0, Foo>) -> VertexOut {

}

I think under the hood, I need to pass types anyways. Also currently Rust doesn't have const generics so the code above would look like

type VertexOut =(Output<Flat, N0, Vec4<f32>>,
                 Output<N1, Vec4<f32>>,
                 Output<NoPersp, N2, Vec4<f32>>);

#[spirv(vertex)]
fn vertex(pos_in: Input<N0, Vec4<f32>>,
          color_in: Input<N1, Vec4<f32>>,
          foo: Descriptor<N0, N0, Foo>) -> VertexOut {

}

Where the constants will be defined like this

#[spirv(CONST0)]
pub struct N0;
#[spirv(CONST1)]
pub struct N1;
#[spirv(CONST2)]
pub struct N2;
...

I am currently in favor of the function like syntax with explicit types.

Note: I also want do redesign PerVertex which is why it doesn't appear in this issue.

What are your thoughts? Any feedback is greatly appreciated. Of course if you have a completely different idea, I would like to hear it.

@MaikKlein
Copy link
Owner Author

Another alternative would be

#25 (comment)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant