vk: Use vk* entrypoints in meta, not driver_layer pointers
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>
vk/meta: Partially fix vkCmdCopyBufferToImage for S8_UINT
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'.
In Vulkan, VertexId and InstanceId will be zero-based and new intrinsics,
VertexIndex and InstanceIndex, will be added for non-zer-based. See also,
Khronos bug #14255
Merge remote-tracking branch 'fdo-personal/nir-spirv' into vulkan
From now on, the majority of SPIR-V improvements should happen on the spirv
branch which will also be public. It will be frequently merged into the
vulkan driver.
nir/builder: Use nir_after_instr to advance the cursor
This *should* ensure that the cursor gets properly advanced in all cases.
We had a problem before where, if the cursor was created using
nir_after_cf_node on a non-block cf_node, that would call nir_before_block
on the block following the cf node. Instructions would then get inserted
in backwards order at the top of the block which is not at all what you
would expect from nir_after_cf_node. By just resetting to after_instr, we
avoid all these problems.
nir/spirv: Make the global constants in spirv.h static
I've been promissed in a bug that this will be fixed in a future version of
the header. However, in the interest of my branch building, I'm adding
these changes in myself for the moment.
We don't actually use it to create all the instructions but we do use it
for insertion always. This should make things far more consistent for
implementing extended instructions.
We do control-flow handling as a two-step process. The first step is to
walk the instructions list and record various information about blocks and
functions. This is where the acutal nir_function_overload objects get
created. We also record the start/stop instruction for each block. Then
a second pass walks over each of the functions and over the blocks in each
function in a way that's NIR-friendly and actually parses the instructions.