It's a lifetime management system for short-lived objects, same idea as memory arenas but for manually refcounted objects you got out of an API. It keeps the object alive until the end of the autorelease scope without anybody having to explicitly call the release method (the autoreleasepool does this instead). Not sure if the concept still makes sense with ARC though, it's probably just a no-op there - or probably not seeing that Swift seems to have inherited autoreleasepools from ObjC).
There's an autoreleasepool around the per-frame code - which seems to be standard procedure for Metal code - so any object within a render frame that has been created with autorelease will be released at the end of a frame.
Metal has a couple of 'frame transient' objects (like MTLRenderPassDescriptor and MTLRenderCommandEncoder) which have a new instance created in each frame, and I guess the main job of the autoreleasepool is to clean up those transient objects (along with any other 'short-lived-junk' that might be returned from Metal API methods).
And my guess for why this is still needed in the age of ARC: I guess that ARC has a 'autorelease-blindness', e.g. it cannot figure out at compile time what objects are registered with autorelease pools (especially when the objects are passed across DLL boundaries) - it can only add retain/release calls on top. Just speculation on my part though.
The render thread is running an infinite loop. You need to manually drain the autorelease pool, otherwise autoreleased objects created during rendering won't be released until the thread exits (there's an implicit top-level pool in each NSThread which is drained on exit). In UIKit/AppKit, the autorelease pool is drained at the end of each NSRunLoop iteration by the framework, so you don't typically drain it yourself. Here they created their own runloop - an infinite `while` loop that calls `onRender()` - so they must drain the pool themselves.
