We're required to expose a host-visible, coherent memory type. On big
core GPUs that share, LLC, we can expose one such memory type that's
also cached. However, on non-LLC GPUs we can't both be cached and
coherent. Thus, we expose both the required coherent type and the cached
but non-coherent combination.
By and large, this is just moving enum values around. However, it also
removed VK_UNSUPPORTED which we were returning a number of places. Those
places now return VK_ERROR_INCOMPATABLE_DRIVER.
The stuff to take descriptor sets and turn them into binding tables and
sampler tables is still in anv_cmd_buffer.c. We may want to consider
putting it in anv_descriptor_set.c eventually.
Previously, we were including gen7_pack.h, gen75_pack.h, and gen8_pack.h
in anv_private.h. As we add more gens, this is going to become untenable.
This commit moves things around so that we only use the pack headers when
and if we need them.
There is a bug in some versions of the i915 kernel driver where it will
return immediately if the timeout is negative (it's supposed to wait
indefinitely). We've worked around this in mesa for a few months but never
implemented the work-around in the Vulkan driver.
I rediscovered this bug again while working on Ivy Bridge becasuse the
drive in my Ivy Bridge currently has Fedora 21 installed which has one of
the offending kernels.
The new mechanism should be able to handle SSBOs as well as properly handle
emitting surface state on gen7 where we need different strides depending on
shader stage.
We never *actually* supported them, we just used them for binding UBOs.
Now that we have BufferInfo and we aren't supporting texture buffers yet,
we should get rid of them until we can do them properly.
Right now, Broadweel and Ivy Bridge are the only supported platforms.
Hopefully, this reduces the chances that someone will try the driver on
unsupported hardware and be confused that it doesn't work.
My original understanding of VkAttachmentDescription::loadOp,
stencilLoadOp was incorrect. Below are all possible combinations:
VkFormat | loadOp=clear stencilLoadOp=clear
---------------+---------------------------
color | clear-color ignored
depth-only | clear-depth ignored
stencil-only | ignored clear-stencil
depth-stencil | clear-depth clear-stencil
If the user called vkDestroyDevice but never called
vkEnumeratePhysicalDevices, then the driver tried to ralloc_free() an
unitialized anv_physical_device.
Fixes test 'dEQP-VK.api.device_init.create_instance_name_version'.
