[serialization] Add support to serialize to memory, and a basic serialization tutorial

[derek-gerstmann]

No description provided.

[abadams]

A Julia set is a cool example, but I don't think it belongs in a tutorial about serialization. The tutorial about serialization shouldn't have anything that a reader needs to try to understand in it that's not either introduced in an earlier lesson or directly related to serialization (e.g. the Complex struct). It would be better to use e.g. the simpler blur pipeline from lesson 7, but using an ImageParam instead of the direct Buffer reference so that the tutorial can also handle reconnecting parameters.

[derek-gerstmann]

A Julia set is a cool example, but I don't think it belongs in a tutorial about serialization. The tutorial about serialization shouldn't have anything that a reader needs to try to understand in it that's not either introduced in an earlier lesson or directly related to serialization (e.g. the Complex struct). It would be better to use e.g. the simpler blur pipeline from lesson 7, but using an ImageParam instead of the direct Buffer reference so that the tutorial can also handle reconnecting parameters.

Yeah, I went back and forth on this ... I'm happy to change it to a simple blur. My reasoning was that we should have a reasonably complex pipeline to serialize, but I agree that there's too much unrelated material for a tutorial about serialization. I'll change it!

[derek-gerstmann]

I discovered that the deserialize_pipeline(...) doesn't work on pipelines that have parameters, unless the parameters are populated. So passing an empty params map to the deserialize_pipeline(...) method when there are (eg) ImageParams used in the pipeline triggers an error in deserialize_expr. So we may need to rethink the API to allow introspection or some way of knowing what params exist, etc.

[abadams]

My understanding was that it was supposed to create new Parameters for you in that case.

[abadams]

Looks like Param<> acts as a scalar Param with a dynamic type, so for the Internal::Parameter API issue I think the methods should take separate maps for scalar and buffer params, e.g:

Pipeline deserialize_pipeline(const std::string &filename, 
    const std::map<std::string, OutputImageParam> &external_buffer_params, 
    const std::map<std::string, Param<>> &external_scalar_params);

Open to other opinions though. What we discussed in the dev meeting was just making Internal::Parameter public, but that increases our public API surface.

[TH3CHARLie]

That sounds like a good plan, and can be implemented with minimal changes

[steven-johnson]

Can we please introduce aliases for these maps and use them everywhere, since these are unwieldy, eg

using BufferParamMap = std::map<std::string, OutputImageParam>;
using ScalarParamMap = std::map<std::string, Param<>>;

Pipeline deserialize_pipeline(const std::string &filename, 
    const BufferParamMap &external_buffer_params, 
    const ScalarParamMap> &external_scalar_params);

[steven-johnson]

Open to other opinions though. What we discussed in the dev meeting was just making Internal::Parameter public, but that increases our public API surface.

I'm starting to think that might be preferable, assuming we do the relevant API cleanup on Parameter per the discussion

[steven-johnson]

This PR doesn't appear to be very close to ready -- decisions about making Parameter a public API are up in the air, and the bots are largely broken. Should it be converted to draft?

[derek-gerstmann]

Yes, I’ll make this to a draft until we sort out the API changes.

[derek-gerstmann]

Added issue to track missing ImageParams during deserialization #7862

[derek-gerstmann]

Updated to include changes to make parameter map optional for serialize(...) #7849

[derek-gerstmann]

Ready to merge ... we'll address #7862 in another PR.

[derek-gerstmann]

@alexreinking @abadams Friendly ping for approval