Async-friendly layer loading (let the host provide the bytes)

[bresilla]

Now that so much has moved into openusd, I want to restructure bevy_openusd properly and get it integrated way tighter with Bevy's AssetLoader / asset system. One thing's worth sorting out first.

Bevy reads files through its own async asset layer (folder, zip, remote, cache - whatever the app sets up), not straight off disk. Right now I dump the bytes into a tempfile just so Stage::open has a real path. It works but it's ugly, and openusd ends up reading every sublayer/reference/texture off disk itself instead of through Bevy, so I lose hot-reload, dedup, and loading from non-disk sources.

The ar::Resolver is already almost what I need, I can plug one in. The problem is it's sync and my bytes arrive async, so I'd have to block_on inside the loader, which I don't love.

What I'd want is some async way to drive layer collection where the host hands openusd the bytes, so it never reads from disk itself and doesn't tie in a specific async runtime.

Useful beyond just me too - anything reading from somewhere that isn't the local filesystem (an editor with unsaved layers in memory, a networked store, a custom resolver). And it's the same idea as the task-queue indexer you're doing, just on the I/O side: keep the logic pure, let something outside drive it.

Doesn't look like a big change either. open_layer already reads the whole file into memory and parses from a Cursor, so the async part only has to cover "get me the bytes for this layer" - no seeking, and pcp doesn't change since it runs on the layers after they're loaded. collect could split into a pure part, the current sync path as a thin driver, plus an async one for cases like mine.

Does this seem reasonable @mxpv? And does it clash with #103 at all? Based on quick view, it seems not, this is quite isolated.

[bresilla]

Also poked at the TODO(rayon) bits in the roadmap while I was in there, and the async thing here is really the same idea, just on a different phase. Both are "keep the logic pure, let something outside drive it" - this one's for I/O, the rayon one's for CPU.

Roughly three levels:

level	phase	now	wants
layer fetch (collect)	I/O	recursive inline open_asset	async driver
intra-prim (indexer)	CPU	already a task queue (you did this)	-
cross-prim (cache driver)	CPU	serial loop over pure build_with_cache	parallel driver

So the indexer is already that shape, and this async ask is the same move on the fetch side. The cross-prim one (TODO(rayon) in cache.rs/mod.rs) is separate - not asking for it here, just noting it's the same principle.

The big thing for me on both: no new dependencies. That's really the appeal of the executor-agnostic approach - it adds zero. No tokio for the async side, no rayon for the parallel side. The host brings its own executor (in Bevy that's IoTaskPool for the fetch, ComputeTaskPool for the compose), so the crate stays lean and isn't married to anyone's runtime.

Curious where you land though @mxpv - I half suspect you'd be happy to just pull in rayon for the parallel side? I'd lean toward keeping it dep-free, but it's your call and I won't push. Mostly want your take before I build around the dependency-light assumption.

[mxpv]

A couple of thoughts on this:

• I'm intentionally not touching this topic until 1.0. The goal right now is to implement the library correctly and make it compliant, then start optimizing. I keep a list of things I'd revisit post-1.0, and this is on it.
• For that same reason there's no async API. Async forces you to make all APIs async — you can't make just ar::Resolver async and keep everything else sync. It would force a choice, or a compile-time feature, and I don't want to introduce either while we're < 1.0.
• It's known that rayon and tokio don't play well together (1, 2) — each maintains its own thread pool and there are lots of surprising behaviors when mixing those. So it's a choice: either go with rayon, or embrace async and have all APIs return futures. Again, a post-1.0 decision.
• A few current impressions: we're not that I/O bound. Loading a layer is a single bulk read — the text parser reads the whole file into memory, and for the binary reader we could play tricks with memory-mapped I/O, which likely is going to be faster. The expensive part is everything after the bytes arrive: parsing (USDA especially), LZ4 decode on the crate format, and above all composition. The PCP layer is extremely complex and CPU-heavy, and that's where we'd likely benefit from running things in parallel — far more than from async I/O.
• I know Bevy is async-first. Post-1.0 I'd want to explore whether we could expose just a subset of the API async — the part that touches I/O — which, given the above, should be a pretty small surface ("get me the bytes for this layer").

[bresilla]

Yeah, all fair. Correctness before 1.0 is the right call.

And good point that it's not really I/O-bound - I was coming at it from "where do the bytes come from", but you're right the actual cost is parsing + composition, which is CPU. So async wouldn't buy me much speed anyway, it's really just about routing reads through Bevy's asset layer instead of disk. The tempfile bridge is fine for that for now, and since I/O isn't the bottleneck I'm not in a hurry.

The small async surface later (just "get me the bytes") is exactly what I was after, so happy to park it til post-1.0 and pick it up then. No need to settle rayon vs async now either.

I'll leave the openusd side alone and just do the bevy-side restructure meanwhile (asset graph, labeled sub-assets, etc.) - none of that needs anything from you.

[safetycoomer]

It sounds like both of you are describing a sans-io architecture. That wouldn't force viral async function coloring throughout any of the library or impose any requirements about "how the bytes arrive" at all, the library consumer could drive it with whatever I/O implementation they like, whether that's basic blocking std::io from a File, hooking it up to an async runtime, or just mmaping like you said and let the kernel deal with it instead of juggling buffers yourself