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.
Pulling in libwayland causes undefined symbols in applications that are
linked against vulkan alone. Ideally, we would like to dlopen a platform
support library or something like that. For now, this works and should get
crucible running again.
We do this for two reasons: First, because it allows us to simplify WSI and
compiling in/out support for a particular platform is as simple as calling
or not calling the platform-specific init function. Second, the
implementation gives us a place for a given chunk of the WSI to stash
stuff in the instance.
Unfortunately, this is a very large commit and removes the old LunarG WSI
extension. This is because there are a couple of entrypoints that have the
same name between the two extensions so implementing them both is
impractiacl.
Support is still incomplete, but this is enough to get vkcube up and going
again.
Now that we don't compile GLSL, we can roll back a few more hacks and
unexport some things from the backend compiler.
Signed-off-by: Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com>
We used to always just do a one-level fallback from genX_* to anv_*
entry points. That worked for gen7 and gen8 where all entry points were
either different or could be made anv_* entry points (eg
anv_CreateDynamicViewportState). We're about to add gen9 and now need to
be able to fall back to gen8 entry points for most things.
Signed-off-by: Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com>
We'll change the dispatch mechanism again in a later commit. Stop using
the driver_layer function pointers and just use the public entry points.
Signed-off-by: Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com>
Print out file and line number and translate the error code to the
symbolic name.
Signed-off-by: Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com>
Create R8_UINT VkAttachmentView and VkImageView for the stencil data.
This fixes a crash, but the pixels in the destination image are still
incorrect. They are not properly tiled.
Fixes crashes in Crucible tests func.miptree.s8-uint.aspect-stencil.* as
of crucible-7471449. Test results improve 'lost' -> 'fail'.