This was very useful to get us up-and-going. However, now that we can use
NIR directly for meta shaders, we don't need this anymore and we might as
well drop the glslc dependency.
These should all eventually be up-streamed. However, since they currently
have no upstream users, they would just bitrot there. We'll keep them
local for the time being.
We want to start using the surface state block pool for binding tables and
binding tables. In order to do this, we need to be able to set surface
state base address to the address of a block and surface state base address
has a 4K alignment requriement.
Binding tables will have a negative offset and we need a way to express
that. Besides, the chances of a state offset being larger than 2 GB is so
remote it's not worth thinking about.
Previously, there were a number of things we were doing wrong:
1) We weren't flushing the wl_display so dead-looping clients weren't
guaranteed to work.
2) We were sending the frame event after calling wl_surface.commit() so it
wasn't getting assigned to the correct frame
3) We weren't actually setting fifo_ready to false.
Unfortunately, we never noticed because (3) was hiding the other two. This
commit fixes all three and clients that use FIFO mode are now properly
refresh-rate limited.
Move the bulk of the function body to a new function
anv_physical_device_get_format_properties(). This allows us to reuse the
function when implementing anv_GetPhysicalDeviceImageFormatProperties()
without calling into the public entry point.
It's no longer used outside anv_batch_chain so we certainly don't need to
be exporting. Inside anv_batch_chain, it's only used twice and it can be
replaced by a single line so there's really no point.
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.
This has the unfortunate side-effect of making it so that we can't have a
block pool bigger than 1GB. However, that's unlikely to happen and, for
the sake of bi-directional block pools, we need to negative offsets.
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.
