The kernel exposes CHIP_ID, which consists of:
[63:48] const 0 / reserved
[47:32] speedbin (default 0xffff)
[31:0 ] actual gpu chip ID
Fix the 740 chip id to make it probe correctly.
Keep the existing entry for the downstream KGSL driver.
Fixes: cd3719be7d ("freedreno: Fully define a730 and a740 device properties")
Reported-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25204>
There is a guess that GPU may not be able to handle different values of
certain debug register between BR/BV. This one causes GPU to hang.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25098>
The set of magic regs is different between generations and even
sub-gens. Adding a new one and/or emitting one on specific generation
takes much more code than necessary. Doing this in a single place is
much nicer.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23217>
A bunch of our piglit fails were due to failing to compile shaders due to
a lack of spilling support. I used a simple shader with a large local
array with tunable size to determine the MEMSIZEPERITEM increment and the
location of HWSTACKOFFSET (matching a3xx locations). Unfortunately
fibers_per_sp I had to guess by taking a big spilling shader and cranking
it up until it rendered correctly. The value I found made HWSTACKOFFSET's
shift value match a6xx's, as a bit of confirmation.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24358>
Based on the previous commit, this isn't actually a bug and is expected
behavior. Turnip should already be handling it correctly for user
flushes, we just have to make sure to handle it for flushes we insert
ourselves in turnip and freedreno.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24162>
On these devices the actual thread size for compute shaders seems to be
controlled by REG_A6XX_HLSQ_FS_CNTL_0 rather than the CS-related
register.
Signed-off-by: Amber Amber <amber@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20991>
a610/a608 has less pipes, so we need to make it configurable.
In particular we need to program all of the VSC_PIPE_CONFIG_REG[n]
rather than leaving garbage values for the unused pipes. Pointing
multiple VSC pipes at the same bin makes the hw angry.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20991>
There is no .gmem field, there is a ccu color cache size field
which tells the size as a fraction of depth cache used in direct
rendering.
There is also GMEM_FAST_CLEAR_DISABLE flag which is set on a608/a610.
Since these values will stop being the same between models,
make them configurable.
Credits to Connor Abbott for deciphering color cache size meaning.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20991>
Defining regs to stomp as ranges in a separate header is a mistake
from maintenance standpoint. Now we have this information at the
point where reg is defined.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23881>
gpu_id is obsolete, chip_id doesn't encode the GPU generation.
Thus we have to manually specify the GPU gen instead of inferring it.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23828>
We already do _most_ of the tracking of rsc associated with a batch at
the batch level. If we manually add the handful of BOs that aren't part
of the resource tracking, we can drop the duplicate drm level tracking.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23149>
Commit 60bc7c0e22 ("freedreno: Specify GMEM tile alignment per GPU")
changed the tile_align_h from 32 to 16 (which _should_ be the correct
value). But this is causing failure in android 9 skqp dstreadshuffle.
(But not, seemingly, with the android 11 version of skia+skqp, which
picks the same tile size. So this is likely papering something over.)
For now, to unblock things, revert back to the previous tile_align_h.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22683>
This happened to work before because the arg to OUT_REG() was also
called 'ring' (or there was a suitable local var in scope!!)
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22646>
Previously when there was an & or | with two BitmaskEnums, the compiler
would try to cast the RHS and find a matching overload, but there were
many different casts (to the enum itself, to an integer, to a boolean,
etc.) each with a matching overload which meant that it couldn't pick
one and errored out due to an ambiguous overload. Fix this by
explicitly providing an overload that takes a BitmaskEnum on the RHS.
It has to also provide a BitmaskEnum output, so that subsequent
operators with the result on the LHS (e.g. when or'ing together three
BitmaskEnums without any parentheses tricks) also get the right
overload.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22224>
It is a pretty common pattern to allocate a non-zero sequence # for
lightweight checking if an object is the same, changed, for use in cache
keys, etc. (And also pretty common to forget to handle the rollover
zero case.) Add a helper for this.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21274>
MESA_VK_ABORT_ON_DEVICE_LOSS=1 \
TU_DEBUG_STALE_REGS_RANGE=0x00000c00,0x0000be01 \
TU_DEBUG_STALE_REGS_FLAGS=cmdbuf,renderpass \
./app
To pinpoint the reg causing a failure reducing regs range could be
used for bisection. Some failures may be caused by multi-reg combination,
in such case set 'inverse' flag which would change the meaning of reg
range to "do not stomp these regs".
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21226>
On blob v512.490, using WRAP_GPU_ID to fake GPU versions, I see 0x41 used
everywhere, except for BLIT_OP_SCALE on a630. Define the magic number in
dev info so it can be reused in the two places that set the
non-BLIT_OP_SCALE value.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19794>
The blob driver does not support
VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_SEPARATE_RECONSTRUCTION_FILTER_BIT
before a6xx_gen3. It still sets CHROMA_LINEAR bit according to
chromaFilter, but the bit has no effect before a6xx_gen3 (confirmed on
a618 with blob version 512.490.0).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19609>
