* move/unify the cache onto zink_resource_object to streamline rebinds
* delete refcounts from surfaces and bufferviews
* only delete surfaces and bufferviews when owner object is destroyed
* cache swapchain surfaces onto the swapchain image
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35722>
Introduce nightly Cuttlefish jobs on Intel Tiger Lake and Alder Lake.
Like `android-angle-venus-anv-cml`, these jobs run dEQP with the Android
guest using Venus + ANGLE, and the host using the ANV Vulkan driver.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35737>
Move shared variables and configuration for the android-angle-venus-anv
job into a new template so that it can be reused by other jobs.
This follows the structure used everywhere else.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35737>
Update the kernel to enable CONFIG_LRU_GEN.
This is the only change from the previous kernel build.
Mutli-gen LRU improves how Linux handles high memory pressure, which
allows Cuttlefish to boot on devices with limited RAM.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35737>
Now that the workaround for stencil valuemask 0 is gone on more
recent cores, we can drop the failures that were caused by this
workaround.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35704>
Older cores have a hardware bug where the stencil test misbehaves when
the valuemask is 0 in the back stencil. The workaround is to effectively
switch to single sided stencil and hope for the best. This seems to be
okay for most actual use-cases and tests, as a 0 valuemask is quite rare.
However, as 0 is a valid value for the mask the workaround breaks some
edge cases. Newer cores don't seem to require the workaround and operate
correctly with all stencil valuemasks, so drop the workaround for them.
I don't know which feature bit tells us about the bugfix. I made an
educated guess by checking behavior on multiple GPUs: GC880r5106 and
GC2000r5108 need the workaround, GC3000r5450, GC7000r6204 and GC600r4653
work fine without it. By comparing the set BugFixes feature bits between
the cores and the fact that BugFixes15 already fixes some PE issues, I
think this one is the most likely candidate.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35704>
Drop the check for front stencil enable when selecting which stencil
ref value to put into the back stencil state. If the front stencil
isn't enabled then stencil operations as a whole aren't enabled and
we don't care which value ends up in the state.
While at it fix indentation.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35704>
There's a few things that will prevent enabling the more efficient
PE_COLOR_FORMAT_OVERWRITE mode, but pixel dicard due to alpha or
stencil testing isn't one of those conditions, as this behaves the
same way as pixel discard due to a failed depth test.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35704>
There is no question anymore: we need to swap front/back stencil
depending on the frontface winding order, as the hardware doesn't
have a front face configuration option. This is what is implemented
in the driver.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35704>
These temps are used to create the scratch_rsrc. Spilling them will
never benefit anything, because assign_spill_slots will insert code
that keeps them live. Since the spiller assumes all spilled variables
to be dead, this can cause more variables being live than intended and
spilling to fail.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35031>
movs supports the same conversions as cov which means that any cov of
its dst can be folded into the movs if all uses of its dst are the same
type of cov.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32624>
movs is just nir_intrinsic_read_invocation so this is a matter of
disabling the current lowering to nir_intrinsic_read_invocation_cond_ir3
and adding lowering to movs.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32624>
movs works like subgroupBroadcast/OpGroupNonUniformBroadcast. The fiber
id can either be an immediate or a value in a0.x. In the latter case,
the value has to be dynamically uniform or else the behavior is
undefined. The dst register has to be shared or else the behavior seems
to be equivalent to a normal mov (i.e., the fiber id is not taken into
account anymore).
movs can do a cov on the broadcasted value. It works exactly like a
normal cov except that using u8 as the src type does not seem to work at
all.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32624>
