Add SimpleVramAllocator::free_all and attach a lifetime to VRAM chunks

[ayrtonm]

This allows the borrow checker to work with VRAM allocations like I mentioned on discord. I don't think it's super-useful with the current sceGu API, but it doesn't seem any more cumbersome to use which is what I was mainly concerned about. The issue with sceGu is that it takes pointers as arguments so the VRAM chunk lifetime provides no benefit in this particular case

// Borrow the allocator for 'a, get a VRAMChunk<'a> then get a pointer to the
// chunk and drop the VRAMChunk<'a>
let chunk_ptr = allocator.alloc(size).as_mut_ptr();

// Mutably borrowing the allocator for 'b is fine since VRAMChunk<'a> was
// already dropped
allocator.free_all();

// Allocates another chunk overlapping the first one. This is allowed because
// chunk_ptr doesn't have a lifetime and VRAMChunk<'a> was dropped.
let new_chunk = allocator.alloc(size);

// Use-after-free
sceGuDrawBuffer(chunk_ptr);

For this to be useful, you'd have to keep the VRAMChunk<'a> until it's passed to sceGuDrawBuffer like in the PR example. Or we could make a sceGu API that accepts VRAMChunks and calculates the pointer internally.

Also the AtomicU32 in the allocator is just for interior mutability (could've been Cell or RefCell). It doesn't inherently make the allocator thread-safe, but the demos use a singleton anyway so it doesn't matter.

[ayrtonm]

Also @MrAwesome @overdrivenpotato do you remember why the dealloc methods were dropped before #60 was merged? I imagine no one's bumping into the 8MB VRAM limit so it's probably not that useful, but I couldn't find an explanation on that PR.

[overdrivenpotato]

The realloc and dealloc methods in that PR were just stubs with an unimplemented!() body.

[ayrtonm]

I should probably remove the comments in examples/cube, but there's no reason this needs to be a draft.

[zetanumbers]

I will make a pr to address my issues

[zetanumbers]

I see a good old race condition right there.

[zetanumbers]

Is this intentional btw? Perhaps this was written as a singlethreaded code?

[ayrtonm]

SimpleVramAllocator is used as a singleton, so I was treating this like singlethreaded code. The AtomicU32 is only for interior mutability and I went with that over Cell to make it easier in case anyone wants to try using the allocator from multiple threads (though that would require a few more changes).

[zetanumbers]

But the problem is SimpleVramAllocator implements Sync, which means you can share references of it between different threads, and function in question (alloc) requires just a shared reference, so alloc can be simultaneously run on multiple different threads. in that case alloc can return two aliasing mem chunks.

[ayrtonm]

In bumpalo thread support is provided by a "herd" which is roughly a Mutex<Vec<Bump>> that creates a new bump allocator with its own pool of memory for each thread. Splitting VRAM per thread seems impractical and I don't think there's a safe way to use one bump allocator from multiple threads. So I'd say let's just add impl !Sync for SimpleVramAllocator in #120 for now.

[zetanumbers]

let's just add impl !Sync for SimpleVramAllocator

No, i think have figured atomics out. It's just nvidia-driver-390 killed my os, so i am on windows for now, that takes it this long and i am back on linux.