- Sep 24, 2015
-
-
Faith Ekstrand authored
-
Faith Ekstrand authored
-
Faith Ekstrand authored
-
Faith Ekstrand authored
-
Faith Ekstrand authored
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.
-
Faith Ekstrand authored
-
Faith Ekstrand authored
This has always been a bit sketchy and neither Kristian nor I have ever really liked it.
-
Faith Ekstrand authored
-
Faith Ekstrand authored
-
Faith Ekstrand authored
- Sep 21, 2015
-
-
Faith Ekstrand authored
-
- Sep 18, 2015
-
-
Faith Ekstrand authored
-
Faith Ekstrand authored
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.
-
Faith Ekstrand authored
-
Faith Ekstrand authored
Probably incomplete but it should do for now
-
Faith Ekstrand authored
It shouldn't matter since we shut off the VS but it's at least clearer.
-
Faith Ekstrand authored
-
Faith Ekstrand authored
-
Faith Ekstrand authored
-
Faith Ekstrand authored
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.
-
Faith Ekstrand authored
This simply breaks the monotonicity check out into its own function
-
Faith Ekstrand authored
-
Faith Ekstrand authored
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.
-
Faith Ekstrand authored
-
Faith Ekstrand authored
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.
-
Faith Ekstrand authored
-
- Sep 14, 2015
-
-
Lina Versace authored
gen8_image_view_init() now supports 1D, 2D, and 3D image views.
-
Lina Versace authored
Calling vkCreateImage() with VK_IMAGE_TYPE_1D now succeeds and computes the surface layout correctly.
-
Lina Versace authored
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.*
-
Lina Versace authored
Rename src -> src_view and dest -> dest_view. This reduces noise in the next patch's diff, which adds new params to the function.
-
Lina Versace authored
-
Lina Versace authored
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.
-
Lina Versace authored
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.
-
Lina Versace authored
Move the code that calculates the layout of 2D surfaces into a switch case.
-
- Sep 11, 2015
-
-
Faith Ekstrand authored
-
Faith Ekstrand authored
-
Faith Ekstrand authored
This commit just adds the NIR pass but does none of the uniform setup
-
Faith Ekstrand authored
-
Faith Ekstrand authored
This makes more sense to me and it's more consistent with anv_descriptor_set_layout.
-