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.
Partially implement the below functions for 3D images:
vkCmdCopyBufferToImage
vkCmdCopyImageToBuffer
vkCmdCopyImage
vkCmdBlitImage
Not all features work, and there is much for performance improvement.
Beware that vkCmdCopyImage and vkCmdBlitImage are untested. Crucible
proves that vkCmdCopyBufferToImage and vkCmdCopyImageToBuffer works,
though.
Supported:
- copy regions with z offset
Unsupported:
- copy regions with extent.depth > 1
Crucible test results on master@d452d2b are:
pass: func.miptree.r8g8b8a8-unorm.*.view-3d.*
pass: func.miptree.d32-sfloat.*.view-3d.*
fail: func.miptree.s8-uint.*.view-3d.*
The field's meaning depends on SURFACE_STATE::SurfaceType.
Make that correlation explicit by switching on VkImageType.
For good measure, add some PRM quotes too.
Calling vkCreateImage() with VK_IMAGE_TYPE_3D now succeeds and computes
the surface layout correctly. However, 3D images do not yet work for
many other Vulkan entrypoints.
Previously, we simply had a big blob of stuff for "driver constants". Now,
we have a very specific data structure that contains the driver constants
that we care about.
