I'm a fair bit behind, so forgive me if you covered this...
... and I haven't even looked at the code, so I'm really not sure...
but (ep 160) I think you were right the first time... you now have the potential to evict an asset for which a reference exists within the push buffer.
It may be unlikely that you evict such a recently used asset... heck, it may even be impossible... but stranger things do happen :)
I'll make a note to go over this on Monday - I think you're correct, because I forgot about this and moved the asset eviction into the allocator :/ When it was outside the allocator, it was fine because it only happened at a prescribed time.
So I don't remember if that was true of 160 but it's definitely true of later episodes, whenever I got rid of EvictAssetsAsNecessary.
An alternative to the generation numbers is to place a "barrier" marker in the lru list.
BeginRender could place a barrier at the front of the list, then any referenced assets would be moved past the barrier when used (moveheadertofront) Eviction would then only occur up until a barrier is reached. EndRender removes the barrier and eviction recommences.
I also found that including the empty blocks in the lru list (essentially merging the asset_header and memory_block) streamlines the allocation process (as empty blocks naturally migrate to the end of the list, collapsing the eviction and free block search code paths)
Anyway, just food for thought. Your code of course works perfectly well.
raxfale I also found that including the empty blocks in the lru list (essentially merging the asset_header and memory_block) streamlines the allocation process (as empty blocks naturally migrate to the end of the list, collapsing the eviction and free block search code paths)
That is a really good idea! We should totally check that out...