mesa.git - Unnamed repository; edit this file 'description' to name the repository.

	Commit message (Collapse)	Author	Age	Files	Lines
*	anv/tests: Add some asserts for data integrity in block_pool_no_free	Jason Ekstrand	2015-09-17	1	-2/+22
\|
*	anv/allocator: Make the block pool double-ended	Jason Ekstrand	2015-09-17	1	-1/+10
\| \| \| \| \| \| \| \|	This allows us to allocate from either side of the block pool in a consistent way. If you use the previous block_pool_alloc function, you will get offsets from the start of the pool as normal. If you use the new block_pool_alloc_back function, you will get a negative index that corresponds to something in the "back" of the pool.
*	anv/tests: Refactor the block_pool_no_free test	Jason Ekstrand	2015-09-17	1	-20/+29
\| \| \| \|	This simply breaks the monotonicity check out into its own function
*	anv/allocator: Take the device mutex when growing a block pool	Jason Ekstrand	2015-09-17	4	-0/+10
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	We don't have any locking issues yet because we use the pool size itself as a mutex in block_pool_alloc to guarantee that only one thread is resizing at a time. However, we are about to add support for growing the block pool at both ends. This introduces two potential races: 1) You could have two block_pool_alloc() calls that both try to grow the block pool, one from each end. 2) The relocation handling code will now have to think about not only the bo that we use for the block pool but also the offset from the start of that bo to the center of the block pool. It's possible that the block pool growing code could race with the relocation handling code and get a bo and offset out of sync. Grabbing the device mutex solves both of these problems. Thanks to (2), we can't really do anything more granular.
*	vk: Add four unit tests for our lock-free data-structures	Jason Ekstrand	2015-08-14	7	-0/+456