For unspills (scratch reads), we can just set WE_all all the time because
we always unspill into a new GRF. For spills, we have two options: If the
instruction has a 32-bit-per-channel destination and "normal" regioning,
then we just do a regular write and it will interleave channels from
different control-flow paths properly. If, on the other hand, the the
regioning is non-normal, then we have to unspill, run the instruction, and
spill afterwards. In this second case, we need to do the spill with
we_ALL.
Perform a copy when the copy_size matches the HW limit (max_copy_size).
Otherwise the current behavior is that we fail the following assertion:
assert(height < max_surface_dim);
because the values are equal.
MinimumArrayElement carries the same meaning for BDW and SKL.
Suggested by Jason.
No regressions in dEQP-VK.pipeline.image.view_type.cube_array.*
Fixes a number of cube tests, including cube_array_base_slice
and cube_base_slice tests.
This makes it act like the address mode is set to TEXCOORDMODE_CUBE
whenever this sampler is combined with a cube surface. This *should* be
what we need for Vulkan. Interestingly, the PRM contains a programming
note for this field that says simply, "This field must be set to
CUBECTRLMODE_PROGRAMMED". However, emprical evidence suggests that it does
what the PRM says it does and OVERRIDE is just fine.
These fields are ignored for non-cube surfaces. For cube surfaces
these fields should be enabled when using TEXCOORDMODE_CLAMP and
TEXCOORDMODE_CUBE.
TODO: Determine if these are the only two modes used in Vulkan.
Some fields of the surface state template were dependent on the
surface type, which is dependent on the usage of the image view, which
wasn't known until the bottom of the function after the template had
been constructed. This caused failures in all image load/store CTS
tests using cubemaps. Refactor the surface state calculation into a
function that is called once for each required usage.
We don't want to do this in the long-run but it's needed for passing the
NoContraction tests at the moment. Eventually, we want to plumb this
through NIR properly.
Relocations are 64 bits on Gen8+. Most CTS tests that send
non-trivial work to the GPU would fail when run from a single deqp-vk
invocation because they were effectively relying on reloc presumed
offsets to be wrong so the kernel would come and apply relocations
correctly.
Before we were asuming that a deref would either be something in a block or
something that we could pass off to NIR directly. However, it is possible
that someone would choose to load/store/copy a split structure all in one
go. We need to be able to handle that.
Ben Widawsky