GEN:BUG:1604601757 prevents source modifiers for multiplication of
lower precision integers.
lower_mul_dword_inst() splits 32x32 multiplication into 32x16, and
needs to eliminate source modifiers in this case.
Closes: #3329
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Lowering source modifiers will convert a 16bit source to a 32bit
value. In the case of integer multiplication, this will reverse
previous lowering performed by lower_mul_dword_inst.
Assert to prevent an illegal DxD operation (and GPU hang).
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
It's a lot easier to deal with them in RenderDoc when they are
in some meaningful order.
Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5788>
Move oa_metrics_available out of load_oa_metrics and call
build_unique_counter_list outside.
This change is a preparation for the next patch. It should
not have any functional impact.
Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5788>
Currently Linux kernel gathers performance counters at fixed
intervals (~5-10ms), so if application uses AMD_performance_monitor
extension and immediately after glFinish() asks GL driver for HW
performance counter values it might not get any data (values == 0).
Fix this by moving the "read counters from kernel" code from
"is query ready" to "get counter values" callback with a loop around
it. Unfortunately it means that the "read counters from kernel"
code can spin for up to 10ms.
Ideally kernel should gather performance counters whenever we ask
it for counter values, but for now we have deal with what we have.
Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5788>
It matters only when counters are not ordered by offset.
Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5788>
It matters only when counters are not ordered by offset.
Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5788>
We use the driver identifier buffer to get the information about the
current frame.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2201>
This option allows for smaller aub files to be generated by only
storing the BOs flagged with EXEC_OBJECT_CAPTURE.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2201>
We can go further in tracking what BOs are written to by the driver by
tracking when a buffer in unmapped. A BO could be mmap, written, unmap
and never be written to again. In such case we can just write the BO's
content on the first exec buf after unmap and never write it again.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2201>
Track what BOs are mapped by the driver and only write those. We can
safely assume that when not mapped there is no data to save.
v2: Don't forget to return the ret (Rafael)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2201>
We don't want to leak in case of failure.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reported-by: Ivan Briano <ivan.briano@intel.com>
Fixes: 246261f0ad ("anv: prepare the driver for delayed submissions")
Fixes: 34f32a6d66 ("anv: implement VK_KHR_timeline_semaphore")
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6200>
We advertised the extension string but never the feature bit. Doh!
Fixes: c57338b924 "anv: Enable SPV_INTEL_shader_integer_functions2..."
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6033>
Turns out that respecting the order of parameters is important.
Reported-by: Michael Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Fixes: 5425968d2e ("anv: Implement VK_EXT_custom_border_color")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6175>
This manages to make some extra vec operations that would turn into movs
go away.
brw shader-db:
total instructions in shared programs: 3895037 -> 3893221 (-0.05%)
total cycles in shared programs: 113832759 -> 113792154 (-0.04%)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6050>
We only support the ARGB format, not the ABGR one. Fortunately, the
ARGB is the one required by D3D11.
Reviewed-by: Joshua Ashton <joshua@froggi.es>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6158>
If pStrides or Psizes are NULL we should use the values defined by the
pipeline.
v2: fix commit message and fix the code to set explicitly if we are
using dynamic stride/size
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5604>
This is done using 3DSTATE_VF_TOPOLOGY packet that overrides topology
used in subsequent 3DPRIMITIVE commands. For gen7[5] we override the
pipeline topology when emitting draw commands.
v2: fix the way gen7[5] is handled (Lionel)
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5604>
Emit 3DSTATE_CLIP during cmd_buffer_flush_state so that we can change
the max viewport count dynamically.
v2: use one common clip state as size is the same for all gens (Lionel)
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5604>
Leave default state values as zero so that when we OR them later
it is only the dynamic state value that matters.
v2: code cleanup + skip topology emit in base batch
when topology is dynamic (Lionel)
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5604>
This is needed to ensure the function prototypes are declared.
v2: tweak commit message (Jason)
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5604>
Previously we parsed a src non-terminal but did nothing with it. Since
the WAIT instruction is kind of weird, in that you have to give it the
same notification subregister for both destination and source, and it
always has an exec size of 1, let's parse a destination instead of a
source. This way, we can parse a writemask rather than a swizzle in
align16 mode, and easily convert the writemask to a swizzle to create
the source register.
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5956>
brw_reg::subnr is in bytes, like the subnr field in the instruction
word, but we disassemble the subregister number in units of the type.
For example g0.3<1>F would have a subnr=12.
These non-terminals produce a brw_reg and feed into other non-terminals
that call brw_reg(), where they are passed the subnr that we set here.
brw_reg()'s subnr parameter is expected to be in terms of the register
type, and it is multiplied by the type size to calculate the subnr in
bytes.
In these non-terminals, we don't know the register type yet, so we
must store the subregister number as it was given to us in the .subnr
field and let the brw_reg() constructor handle the conversion to the
canonical byte-based subnr form when it knows the type.
Before this patch, subregister numbers applied to these registers would
be multiplied with the type size twice.
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5956>
That's more future proof than setting each bit manually. Looks like we
already miss nir_lower_ufind_msb64 because of that.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5588>
This information is exposed through shader->options->lower_int64_options.
Removing the extra arg forces drivers to initialize this field correctly.
This also allows us to check the int64 lowering options from each int64
lowering helper and decide if we should lower the instructions we
introduce.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5588>
