DGC preprocessing is disabled for VBOs, so the dynamic vertex input
should always be initialized. Null VBO descriptors are slightly
different when used with dynamic VS inputs.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29831>
This feature is marginal but VKCTS recently got coverage and most of
the implementations were broken, including RADV.
Fixes recent tests
dEQP-VK.pipeline.pipeline_library.graphics_library.misc.other.view_index_from_device_index_.*
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30642>
Add a tool that programs the hardware the minimum amount to be
able to execute compute shaders and then executes a script that
can perform data manipulation and dispatch execution of the shaders
(written in Xe assembly).
The goal is to have a tool to experiment directly with certain
assembly instructions and the shared units without having to
instrument the drivers.
To make more convenient to write assembly, a few macros (indicated by
the @-symbol) will be processed into the full instruction.
For example, the script
```
local r = execute {
data={ [42] = 0x100 },
src=[[
@mov g1 42
@read g2 g1
@id g3
add(8) g4<1>UD g2<8,8,1>UD g3<8,8,1>UD { align1 @1 1Q };
@write g3 g4
@eot
]]
}
dump(r, 4)
```
produces
```
[0x00000000] 0x00000100 0x00000101 0x00000102 0x00000103
```
There's a help message inside the code that describes the script
environment and the macros for assembly sources.
Acked-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30062>
Lua is used for unittests in Freedreno. When this was added, 5.3 was too new,
now this version is available in debian stable (and oldstable). A notable
improvement in Lua 5.3 is better handling for integers. Note the wrap provided
in subprojects/ already uses 5.4.
Also move the dependency up so other tools/tests can use it.
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Acked-by: Rob Clark <robclark@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30062>
strictly I think there's a bug fix here. I don't see the old code handling
swizzles anywhere!
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30567>
rewrote most of the impl but shrug.
regresses code gen for mediump but I'm not too bothered given the lackluster
perf of fp16 on bifrost :(
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30567>
Today, on i915.ko, if Sparse Resources is disabled and the Kernel is
new enough to confirm to us that the GuC version is good, we'll expose
non-render engines, otherwise we don't.
Ever since we merged 5ca224aa0c ("anv/trtt: make all contexts have
the same TR-TT programming"), TR-TT is not anymore the reason why
we're not enabling non-render engines. Our performance team has
analyzed workloads and concluded enabling non-render engines is not
worth it on i915.ko today.
So here we adjust the code to do three things:
- Stop blaming TR-TT
- Unify the default behavior for i915.ko
- Don't disable non-render engines when TR-TT is being used on xe.ko.
v2:
- Comments (José)
Acked-by: Felix DeGrood <felix.j.degrood@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30627>
The ideal place to store the halti value is in struct etna_core_info.
Let's put it there and the determination of it into etna_gpu_new(..).
This makes it possible to reuse the halti level outside of gallium.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30394>
It has been a while that the GuC version with the compute engine fix
was released, same for the KMD uAPI to query the GuC firmware version.
So at this point this parameters do more harm than good.
Also just setting those don't enable the async compute and copy engines
this is not enabled by default on i915.
If user wants to disable or enable usage of those engines a better
approach would be use ANV_QUEUE_OVERRIDE.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30593>
The `capture_not_overwritten` unit test captures and compares two
backtraces -- one from inside a call to `func_c` and one outside -- and
confirms that they are not identical. That is, that `func_c` is in the
backtrace.
On 32-bit x86, without `-fno-omit-frame-pointer`, the function will not
emit a stack frame. As a result, the unit test fails.
The fix is to compile `func_c` with the flag `-fno-omit-frame-pointer`
to prevent the compiler from optimizing out the stack frame which is
otherwise unneeded.
Bug: https://bugs.gentoo.org/823774
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4091
Fixes: d0d14f3f64 ("util: Add unit test for stack backtrace caputure")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30622>
Bspec 64643: Structure_TraceRayPayload::Trace Ray Control
Bit field moved from 9-8 to 10-8 on Xe2.
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30600>
Bspec 57508: Structure_SIMD16TraceRayMessage:: RayQuery Enable
"When this bit is set in the header, Trace Ray Message behaves like a
Ray Query. This message requires a write-back message indicating
RayQuery for all valid Rays (SIMD lanes) have completed."
If we don't pass the write-back register, somehow it was stepping on
over R0 register and can mess up the scratch space accesses which could
potentially lead to GPU hang. It can be noticed while running it under
simulator trace.
send.rta (16|M0) null r124 r126:1 0x0 0x02000100 {$15} // wr:1+1, rd:0; simd16 trace ray
R0 = 00000001 00000000 00000000 00000001 00000000 00000000 00000001 00000000 00000000 00000001 00000000 00000000 00000001 00000000 00000000 00000001
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Suggested-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30600>
* the damage region was not being used correctly (this is a normal rect)
* use_damage was never unset at frame boundary
* original renderArea was never re-set
Fixes: 3d38c9597f ("zink: hook up KHR_partial_update")
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30625>
When splitting spills/reloads into to multiple separate spills/reloads,
the src/dst registers where not adjusted. This caused the separate
instructions too all refer to the same register.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30613>
This enables some algebraic optimizations.
No changes in shader-db, but it does cause some CTS tests to
produce less instructions.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30614>
When closest hit shader is called, the BVH object level
brw_nir_rt_load_mem_ray origin/direction is 0. What we should be using
is the ray origin/direction and apply the transform of the current
instance.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 9ba7d459a3 ("intel/rt: Implement the new ray-tracing system values")
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30578>
The main change here is that instead of having two vectors for API and
internal arguments, there is just one per built kernel.
Some of the API level information is still in its own structure and
referenced by the above mentioned merged vector, but with this change each
device and also each kernel variant can have arguments placed at different
locations or even have a different set of arguments.
This rework will be necessary to add kernel variants in a non messy way.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30602>
