From the bspec docs for "Indirect State Pointers Disable":
"At the completion of the post-sync operation associated with this
pipe control packet, the indirect state pointers in the hardware are
considered invalid"
So the ISP disable is a post-sync type of operation which means that it
should be combined with a CS stall. Without this, the simulator throws
an error.
Fixes: 766d801ca "anv: emit pixel scoreboard stall before ISP disable"
Fixes: f536097f6 "i965: require pixel scoreboard stall prior to ISP disable"
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Out of tree builds can try to write into a directory that doesn't exist yet:
| Traceback (most recent call last):
| File "../../../mesa-18.0.2/src/intel/vulkan/anv_icd.py", line 46, in <module>
| with open(args.out, 'w') as f:
| IOError: [Errno 2] No such file or directory: 'vulkan/intel_icd.x86_64.json'
| Makefile:4882: recipe for target 'vulkan/intel_icd.x86_64.json' failed
Add missing MKDIR_GEN calls to solve this.
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
We want to make sure that all indirect state data has been loaded into
the EUs before disable the pointers.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
Fixes: 78c125af39 ("anv/gen10: Ignore push constant packets during context restore.")
On CNL and above, CCS_E supports 1010102 formats and R11G11B10F. We had
shut them off during early enabling because blorp_copy couldn't handle
them. Now it can handle 1010102 formats so we can turn them back on.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
nir_format_bitcast_uint_vec_unmasked can only be used to cast between
formats with uniform channel sizes. In particular, it cannot handle
10_10_10_2 formats. By making use of the NIR helper for uint vector
casts, we should now be able to bitcast between any two uint formats so
long as their channels are in RGBA order (possibly with channels
missing). In order to do this we need to rework the key a bit to pass
the actual formats instead of just the number of bits in each.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This adds helpers to ISL to convert an isl_color_value to and from
binary data encoded with a given isl_format. The conversion is done
using ISL's built-in format introspection so it's fairly slow as format
conversions go but it should be fine for a single pixel value. In
particular, we can use this to convert clear colors.
As a side-effect, we now rely on the sRGB helpers in libmesautil so we
need to tweak the build system a bit. All prior uses of src/util in ISL
were header-only.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Alpha-only formats are just linear. There's no need to specially
deliminate them as being in their own colorspace.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Now that blorp handles all the cases, why not? The only real change we
have to make is to stop using anv_swizzle_for_render() in blorp_blit
because it doesn't work for B4G4R4A4 and blorp now natively handles that.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Previously we only supported UINT formats because that's what blorp_copy
required. If we want to use it in blorp_blit, however, we need to
support everything.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This commit adds support for the following formats as destination
formats even though the hardware does not support rendering to them:
- ISL_FORMAT_R24_UNORM_X8_TYPELESS
- ISL_FORMAT_A4B4G4R4_UNORM
- ISL_FORMAT_L8_UNORM_SRGB
- ISL_FORMAT_R9G9B9E5_SHAREDEXP
This is done by using a different format and emitting shader code to
fake it the rest of the way.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
nir_mask_shift_or is now defined in nir_format_convert.h so we can
delete the copy in blorp_blit.c.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This commit makes blorp capable of swizzling anything even on hardware
that doesn't support texture swizzle.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This helper encodes more details, specifically about Haswell, than the
previous asserts in isl_surface_state.c.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The previous version was sort-of strapped on in that it just adjusted
the blit rectangle and trusted in the fact that we would use texelFetch
and round to the nearest integer to ensure that the component positions
matched. This new version, while slightly more complicated, is more
accurate because all three components end up with exactly the same
dst_pos and so they will get interpolated and sampled at the same
texture coordinate. This makes the workaround suitable for using with
scaled blits.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
It's just not possible to have a device with no subslices.
CID: 1433511
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
According to Vulkan spec:
"pColorBlendState is a pointer to an instance of the
VkPipelineColorBlendStateCreateInfo structure, and is ignored if the
pipeline has rasterization disabled or if the subpass of the render pass the
pipeline is created against does not use any color attachments."
Fixes tests from CL#2505:
dEQP-VK.renderpass.*.simple.color_unused_omit_blend_state
v2:
- Check that blend is not NULL before usage.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
I forgot to change the assert in the second helper function in a
previous change.
This hit the assert() on a Broadwell platform with 1 slice, 3
subslices but all EUs disabled in subslice 1 & 2.
Fixes: c1900f5b0f ("intel: devinfo: add helper functions to fill fusing masks values")
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Chris recently fixed a bunch of genxml end < start bugs, as well as
booleans that are wider than a bit. These are way too easy to write, so
asserting that the fields are sane is a good plan.
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
None of these are actually booleans. Tile Parameter is a tiling mode
enum. Display pipes take plane numbers. Predicate Enable has some
operations (and the default value of 6 was particular bogus).
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Python's assert can take both a condition and a string, which will cause
it to print the string if the assertion trips. (You can't use parens as
that creates a tuple.) Doing "condition and string" works in C, but
doesn't have the desired effect in Python.
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
A couple of typos found by inspecting field.end - field.start, revealed
a few wide integers declared as bool and some that ended before they
started.
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
This rollbacks the revert of this patch introduced with
commit 7cf284f18e.
Tested-by: Mark Janes <mark.a.janes@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This rollbacks the revert of this same patch introduced in
commit 7b9c15628a.
And also squahes the following patch to prevent a piglit regression caused
by this change:
intel/compiler: Fix lower_conversions for 8-bit types.
Author: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
For 8-bit types the execution type is word. A byte raw MOV has 16-bit
execution type and 8-bit destination and it shouldn't be considered
a conversion case. So there is no need to change alignment and enter
in lower_conversions for these instructions.
Fixes a regresion in the piglit test "glsl-fs-shader-stencil-export"
that is introduced with this patch from the Vulkan shaderInt16 series:
'i965/compiler: handle conversion to smaller type in the lowering
pass for that'. The problem is caused because there is already a case
in the driver that injects Byte instructions like this:
mov(8) g127<1>UB g2<32,8,4>UB
And the aforementioned pass was not accounting for the special
handling of the execution size of Byte instructions. This patch
fixes this.
v2: (Jason Ekstrand)
- Simplify is_byte_raw_mov, include reference to PRM and not
consider B <-> UB conversions as raw movs.
v3: (Matt Turner)
- Indentation style fixes.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106393
Tested-by: Mark Janes <mark.a.janes@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
These are subject to the general restriction that anything that is converted
to 64-bit needs to be aligned to 64-bit. We had this already in place for
32-bit to 64-bit conversions, so this patch generalizes the implementation
to take effect on any conversion to 64-bit from a source smaller than
64-bit.
Fixes assembly validation errors in the following CTS tests in BSW:
dEQP-VK.spirv_assembly.instruction.compute.sconvert.int16_to_int64
dEQP-VK.spirv_assembly.instruction.compute.uconvert.uint16_to_uint64
dEQP-VK.spirv_assembly.instruction.compute.sconvert.int16_to_uint64
Tested-by: Mark Janes <mark.a.janes@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Remove the need of converting values that are documented in
hexadecimal. This patch would allow writing
<field name="3D Command Sub Opcode" ... default="0x1B"/>
instead of
<field name="3D Command Sub Opcode" ... default="27"/>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
NIR assumes that booleans are always 32-bit, but Intel hardware produces
16-bit booleans for 16-bit comparisons. This means that we need to convert
the 16-bit result to 32-bit.
In the future we want to add an optimization pass to clean this up and
hopefully remove the conversions.
v2 (Jason): use the type of the source for the temporary and use
brw_reg_type_from_bit_size for the conversion to 32-bit.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
These are not supported in hardware for 16-bit integers.
We do the lowering pass after the optimization loop to ensure that we
lower ALU operations injected by algebraic optimizations too.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
16-bit immediates need to replicate the 16-bit immediate value
in both words of the 32-bit value. This needs to be careful
to avoid sign-extension, which the previous implementation was
not handling properly.
For example, with the previous implementation, storing the value
-3 would generate imm.d = 0xfffffffd due to signed integer sign
extension, which is not correct. Instead, we should cast to
uint16_t, which gives us the correct result: imm.ud = 0xfffdfffd.
We only had a couple of cases hitting this path in the driver
until now, one with value -1, which would work since all bits are
one in this case, and another with value -2 in brw_clip_tri(),
which would hit the aforementioned issue (this case only affects
gen4 although we are not aware of whether this was causing an
actual bug somewhere).
v2: Make explicit uint32_t casting for left shift (Jason Ekstrand)
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "18.0 18.1" <mesa-stable@lists.freedesktop.org>
From Intel Skylake PRM, vol 07, "Immediate" section (page 768):
"For a word, unsigned word, or half-float immediate data,
software must replicate the same 16-bit immediate value to both
the lower word and the high word of the 32-bit immediate field
in a GEN instruction."
This fixes the int16/uint16 negate and abs immediates that weren't
taking into account the replication in lower and upper words.
v2: Integer cases are different to Float cases. (Jason Ekstrand)
Included reference to PRM (Jose Maria Casanova)
v3: Make explicit uint32_t casting for left shift (Jason Ekstrand)
Split half float implementation. (Jason Ekstrand)
Fix brw_abs_immediate (Jose Maria Casanova)
Cc: "18.0 18.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
