Would allow earlier faults instead of having corrupted cmdstream.
This was already done to Freedreno long ago in:
04aff7e4 "freedreno: make cmdstream bo's read-only to GPU"
Since private memory should be GPU writable it is now allocated
separately, instead of suballocation from now read-only cmdstream.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10807>
We don't want to have to deal with vector phis in freedreno, because
vectors are always split/unsplit around vectorized instructions anyways,
and the stated reason for not scalarising them (it hurting coalescing)
won't apply to us because we won't be using nir_from_ssa. Add this
option so that we don't have to do the equivalent thing while
translating from NIR.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10809>
Not every MR, but several per day since I landed the apitrace switch which
increased trace replay resolution to 1080p. Hopefully some day we can
tune the hangcheck to be less aggressive.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10793>
The spec requires at least 2, but says "No specific guarantees are made
about higher priority queues receiving more processing time or better
quality of service than lower priority queues." So, we can just leave the
priorities as a stub.
Fixes dEQP-VK.info.device_properties
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10470>
Blending in SP_BLEND_CNTL is not a binary flag but the same
mask as in RB_BLEND_CNTL. It is a per-mrt enable bit for blending.
Example SP_BLEND_CNTL produced by blob on a630 and different MRT
blendings:
SP_BLEND_CNTL: { UNK8 | 0x6 }
SP_BLEND_CNTL: { ENABLED | UNK8 | 0xe }
(Decoded before this commit)
Fixes mis-rendering with D3D11 game "Spelunky 2".
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10682>
We were forgetting to increment in the loop, but also it looks from blob
dumps on Pixel 2 like all the pointers it emitted were shifted up by 3
compared to our xml, and that's the same shift that a6xx uses for its
pointers. None of the tests seem to use more than one
border-color-requiring texture, so it's hard to tell.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9904>
We don't support major 1.2 required extensions like timeline semaphores.
Fixes many complaints in the dEQP-VK.info.vulkan1p2.* group.
We were originally bumped to 1.2 in 75755e0eba ("turnip: Pretend to
support Vulkan 1.2") but hopefully that build issue has been fixed in the
entrypoint reworks since then.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10471>
No handling of Acquire/Release because at the moment scheduler
works as if any barrier is Acq+Rel.
Instead of removing scoped_barrier with scope/mode that for TCS
corresponds to a control_barrier or a memory_barrier_tcs_patch in
ir3_nir_lower_tess_ctrl - remove them in emit_intrinsic_barrier.
And do the same for memory_barrier_tcs_patch and control_barrier.
While in any case hw fence/barrier shouldn't be emitted for them,
they still affect ordering of stores, and in feature ir3 backend
may want to have that information.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9054>
nir_intrinsic_memory_barrier has the same semantic as memoryBarrier()
in GLSL, which is:
GLSL 4.60, 4.10. "Memory Qualifiers":
"The built-in function memoryBarrier() can be used if needed to
guarantee the completion and relative ordering of memory accesses
performed by a single shader invocation."
GLSL 4.60, 8.17. "Shader Memory Control Functions":
"The built-in functions memoryBarrier() and groupMemoryBarrier() wait
for the completion of accesses to all of the above variable types."
Fixes tests:
dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.device.payload_local.image.guard_nonlocal.workgroup.comp
dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.device.payload_nonlocal.workgroup.guard_local.image.comp
Fixes: 819a613a ("freedreno/ir3: moar better scheduler")
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9054>
We were implictly including it in exposing VK 1.2, but we weren't making
use of the supplied struct. Actually enabling it gives us a chance to do
slightly better at Z/S UBWC, and means we won't lose the separate usage
test coverage when switching back to exposing VK 1.1.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10594>
Instead of using a separate outputs array, make the "end" instruction
(or chmask) take the outputs as sources. This works better for the new
RA, because it better models the fact that outputs are consumed all at
the same time. With the old model, each output collect would be assumed
dead after it was processed and subsequent collects could use it when
inserting shuffle code, which wouldn't work, and the new RA also deletes
collect instructions after lowering them to moves so the information
would be gone after RA.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10591>
We need a stable order in order to create phi instructions. In the
future we can make this more sophisticated in order to make manipulating
the CFG easier, but for now that only happens after RA, so we won't have
to worry about it.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10591>
Originally I wrote this to support multiple ir3 blocks per NIR block,
but this turned out to be more useful for creating a stable ordering to
the predecessors. We compute the predecessors ourselves, rather than
relying on NIR, so that the array of predecessors we create in the next
commit has a stable order we can rely on when creating phi nodes.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10591>
There's an optimization here to sink direct (i.e. not relative) reads of
an array past unrelated direct writes. However, since each write
actually reads, modifies, and then writes again to the array, this means
that we need to read the latest updated array. The old RA used the array
id instead of the SSA information, so it didn't care, but the new RA
uses ->instr instead and ignores the array id because arrays are now SSA
so it needs to be correct.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10591>
This wasn't using the same calculation that add_reg_dep() was using to
get the index into state->regs, so it was using the wrong register. Fix
this by folding it into add_reg_dep().
This shouldn't fix anything, because it's just used for scheduler
priorities, but it should reduce nop's and syncs.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10591>
a0.x is written as a half-reg, but just interpreting it as "hr61.x" will
result in it overlapping with r30.z in merged mode, which is not what
the hardware does at all. This introduced a spurious dependency on
a write to r30.z which resulted in an assert tripping. Just pretend it's
a full reg instead.
This fixes
spec@arb_tessellation_shader@execution@variable-indexing@vs-output-array-vec3-index-wr-before-tcs
with the new RA.
Fixes: 0f78c32 ("freedreno/ir3: post-RA sched pass")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10591>
Danylo Piliaiev