feat: feed shape info to initializer

[zimond]

fixes #66

Turns out that initializer inited info proto will not include the shape info. This PR forces callers to provide shape information to ensure that any shaders using the info would not crash

[pixelspark]

Thanks for the PR @zimond!

The only issue I have with this is that we are now repeating dimensions twice for an initializer (first in the 'infos' list and next in the 'initializers' list). This could lead to errors if the dimensions passed to tensor(..) are different from the dimensions passed to initializer(...). From e.g. the test for BatchNormalization:

let bn_model = model(graph(
        vec![tensor("X", &shape)],
        vec![tensor("Y", &shape)],
        vec![
            tensor("scale", &[channels as i64]),  // First here...
            tensor("B", &[channels as i64]),
            tensor("input_mean", &[channels as i64]),
            tensor("input_var", &[channels as i64]),
        ],
        vec![
            initializer("scale", scale, vec![channels as i64]), // Then here again
            initializer("B", b, vec![channels as i64]),
            initializer("input_mean", mean, vec![channels as i64]),
            initializer("input_var", var, vec![channels as i64]),
        ],
        // ...
    ));

I would suggest to auto-generate the 'infos' for each initializer, so you can omit the 'infos' for initializers. This should be quite an easy fix (and save a few lines in the test code).

[pixelspark]

See above

[zimond]

How could you auto-generate the infos as initializer is just accepting 1-d arrays?

[pixelspark]

How could you auto-generate the infos as initializer is just accepting 1-d arrays?

The infos just takes the name and dimensions, which you are both also supplying to initializer(..). My suggestion is to have graph(..) automatically generate the infos for initializers, so you don’t have to call info(..) for those (and potentially make the mistake of calling info and initializer with different dimensions for the same tensor).

[pixelspark]

See #80