| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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 has always been a bit sketchy and neither Kristian nor I have ever
really liked it.
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, our location handling was focussed on either no location
(usually implicit 0) or a builting. Unfortunately, if you gave it a
location, it would blow it away and just not care. This worked fine with
crucible and our meta shaders but didn't work with the CTS. The new code
uses the "data.explicit_location" field to denote that it has a "final"
location (usually from a builtin) and, otherwise, the location is
considered to be relative to the base for that shader stage.
|
| | |
|
| |
| |
| |
| | |
Probably incomplete but it should do for now
|
| |
| |
| |
| | |
It shouldn't matter since we shut off the VS but it's at least clearer.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
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 simply breaks the monotonicity check out into its own function
|
| | |
|
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| | |
gen8_image_view_init() now supports 1D, 2D, and 3D image views.
|
| |
| |
| |
| |
| | |
Calling vkCreateImage() with VK_IMAGE_TYPE_1D now succeeds and computes
the surface layout correctly.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.*
|
| |
| |
| |
| |
| | |
Rename src -> src_view and dest -> dest_view. This reduces noise in the next
patch's diff, which adds new params to the function.
|
| | |
|
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| | |
Move the code that calculates the layout of 2D surfaces into a switch case.
|
| | |
|
| | |
|
| |
| |
| |
| | |
This commit just adds the NIR pass but does none of the uniform setup
|
| | |
|
| |
| |
| |
| |
| | |
This makes more sense to me and it's more consistent with
anv_descriptor_set_layout.
|
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
|\| |
|
| |
| |
| |
| |
| | |
Assuming this all works, about the only thing left should be some
corner-cases for tg4
|
| |
| |
| |
| |
| |
| | |
There were merge conflicts in spirv.h that got missed because they were in
a comment and so it still compiled. This gets rid of them and we should be
on-par with upstream spirv->nir.
|
|\| |
|
| | |
|