The code shouldn't serialize to disk any shader binary larger than the memory pool. I've added the check anyway, though.
Ok, I've updated it since as you mention, it won't cause any harm. But I really don't see how a single Blender session could request over 4 billion compilation batches and never request them.
@MVPuccino I don't think we will be able to have that granularity with the already existing BSDF nodes. But I agree that for NPR nodes having per-node control of light groups is a must-have. Per-…
The problem with BLI_file_read_binary_as_mem is that it allocates memory, while this is loading the file contents directly into the already allocated shared memory pool.
Ah, thanks for the explanation.
Of course, it wouldn't be the std without some stupid landmines in it.
I don't get why this is a problem.
Do we target any platform where int is not 32 bits?
ints are used all over the place, what makes this different?
The thing is, it blocks for Metal and Vulkan.
But this only needs to run once per Blender session, just like the constructor.
Unless you're not suggesting calling this init function from Instance::init?
And yes, as we already discussed,…
I've updated it to use blender::fstream, I assume that's fine as well?
I think filesystem::path uses wchar on Windows, so in that sense I think it should work.
Anyway, better take the safe route.
I've updated all the path/file related code to use the Blender APIs.