This lets us implement all the complex logic of copying a GOB in a
central place and all we really need for each GOB type is an iterator
function. There's a bit of duplication here with the copy functions but
it's still better than what we had before.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35660>
This depends on GOB types but we really only support Turing for now.
Add the match statement anyway so we panic if we see an unsupported GOB
type instead of pretending it's TuringColor2D and copying anyway.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35660>
The gob kind and sector layout should map directly to a unique GOBType.
We can now also advertise zero modifiers for GOB types that don't
support modifiers. Currently this is redundant with the earlier return
for depth/stencil images but it should help protect us in the future
when adding new GOB types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35660>
We know Turing+ is different because it's different in the NVIDIA
modifiers and because we've implemented host image copies and the
current implementation doesn't work on Volta and earlier. We also know
that Z/S is different from color and that there's some sort of 3D GOB
concept we haven't reverse engineered yet. Let's make everything a as
explicit as we can.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35660>
Take into account the alpha blend state of all render targets when deciding
whether it is okay to enable dithering. Do not dither render targets with
less than 5 bits of precision per channel as this leads to visible artifacts.
GC7000 fails to blend RGBA4444 correctly when dithering is disabled but
PE_LOGIC_OP_DITHER_MODE is set to anything other than 0, so set this state
depending on whether dithering is actually enabled.
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/35673>
The spirv-to-c-array.py script assembles a SPIR-V module,
then disassembles it, capturing that text, then re-assembles
that text, providing it on stdin. But this last invocation of
spirv-as must use '-' to specify that the text input appears
on stdin.
Currently it always errors out, complaining that there must
be exactly one input file.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35691>
Currently anv exposes this on lots of devices, with the intent to be better
than apps can give, but I think this is wrong for a couple of reasons.
Apps want to know if hw exposes the fast path, Vulkan is meant to be explicit,
and telling llama.cpp if the fast path exists lets it make smarter decisions.
It seems unless someone heavily optimises the slow path, that CPU is usually
faster than GPU with llama-bench unless the hw path exists.
v2: added INTEL_LOWER_DPAS support
Acked-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35564>
It is annoying to change all function signatures when a driver needs
more information. There are also some callbacks that have a lot of
parameters and there have already been bugs related to that.
This patch tries to clean the interface by adding a struct that contains
all information that might be relevant for the driver and passing that
to most callbacks.
radv changes are:
Reviewed-by: Natalie Vock <natalie.vock@gmx.de>
anv changes are:
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
turnip changes are:
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
vulkan runtime changes are:
Reviewed-by: Natalie Vock <natalie.vock@gmx.de>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35385>
The spec says (emphasis mine):
If the color attachment is fixed-point, the components of the source and
destination values **AND BLEND FACTORS** are each clamped to [0,1] or [-1,1]
respectively for an unsigned normalized or signed normalized color attachment
prior to evaluating the blend operations. If the color attachment is
floating-point, no clamping occurs.
However, neither the CTS nor any hardware implement this semantic.
For unsigned normalized formats, the definitions are roughly equivalent (except
perhaps around constant colours). 0 <= x <= 1 implies that 0 <= 1 - x <= 1.
Therefore if the source/destination colours are clamped to [0, 1], then their
complements are also in [0, 1], so clamping any blend factor (except constant
colour) has no effect if the source/dest were already clamped.
For signed normalized formats, however, this difference matters. -1 <= x <= 1
implies that 0 <= 1 - x <= 2... so to implement the spec text faithfully, we
would need to clamp again the complemented colour blend factors to return back
to signed normalized range. Software blending implementations can of course do
that... but doing so causes CTS fails, as the CTS reference renderer does not do
this.
This commit adjusts nir_lower_blend to match what actual hardware does, what CTS
requires, and what the spec should have said.
See https://gitlab.khronos.org/vulkan/vulkan/-/issues/4293 for the spec
resolution.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35519>
Spec recommended values should give us a good balance between progress
in render and compute engines, also with less possibility of values
it will reduce the number of times that we need to emit
STATE_COMPUTE_MODE reducing the number of stalls in the compute engine.
Cc: stable
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35563>
If attachments are used in separate subpasses, then we can store them in
the same GMEM area. That gives us more space per attachment and thus
larger tile sizes. For gfxbench vk-5-normal's main renderpass it goes
from 128x128 to 160x128, improving perf by 2.125% +/- 0.194356% (n=4)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17943>
This can reduce the subpass live range of attachments, for future gmem
attachment space sharing.
We have to disable IB2 skipping when the subpass isn't the last, but being
able to reuse the gmem space by storing early ends up paying off (in the
next commit).
Fixes: #5181
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17943>
Ryan Mckeever