For gl_FragDepth, passes dEQP-GLES3.functional.shaders.fragdepth.* and piglit
fragdepth_gles2.
For stencil export, passes piglit glsl-fs-shader-stencil-export.
For gl_FragDepth together with stencil export, passes
dEQP-GLES3.functional.fbo.blit.*
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20365>
Now we support all the vertex formats! This means we don't hit u_vbuf for format
translation, which helps performance in lots of applications. By doing the
lowering in NIR, the vertex fetch code itself can be optimized by NIR (e.g.
nir_opt_algebraic) which can improve generated code quality.
In my first implementation of this, I had a big switch statement mapping format
enums to interchange formats and post-processing code. This ends up being really
unwieldly, the combinatorics of bit packing + conversion + swizzles is
enormous and for performance we want to support everything (no u_vbuf
fallbacks). To keep the combinatorics in check, we rely on parsing the
util_format_description to separate out the issues of bit packing, conversion,
and swizzling, allowing us to handle bizarro formats like B10G10R10A2_SNORM with
no special casing.
In an effort to support everything in one shot, this handles all the formats
needed for the extensions EXT_vertex_array_bgra, ARB_vertex_type_2_10_10_10_rev,
and ARB_vertex_type_10f_11f_11f_rev.
Passes dEQP-GLES3.functional.vertex_arrays.*
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19996>
We support a good chunk of GL 3.x now ... let's get us on the board so that
Mesamatrix can get onto solving the challenging problem of deciding what colour
to use for Asahi ;-)
Table filled out to the best of my abilities, there may be inaccuracies or
omissions.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19944>
This extension is basically a no-op exposing some new enums.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19726>
This extension is basically a no-op exposing some new enums.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19726>
This extension is basically a no-op exposing some new enums.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Reviewed-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19726>
This CAP only concerns mapping of buffers, not textures. For buffers,
etnaviv does not seem to use any staging resources. In neither case does
etnaviv use explicit syncs or flushes, so persistent/coherent mapping
should come as the implicit default and the cap should be almost free.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19392>
It's a software rasterizer, all buffers are necessarily persistent and
coherent. There are no staging buffers in transfer_map and no sync/flush
operations, so this is trivial.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19392>
After a great deal of spec lawyering in #dri-devel, I am convinced this
is probably okay for the same reasons as v3d and freedreno. The batch
reordering and flush deferral optimizations are seemingly still ok. The
requirement that writes are visible "immediately" in the spec actually
means "in the subsequent [OpenGL] command" for the CPU -> GPU direction,
which avoids pitfalls where PERSISTENT|COHERENT could be used as a
"doorbell". With that understanding, the extension doesn't actually
require anything special for tilers other than coherency at GPU submit
boundaries, which is true for any driver that does not use a sync ioctl.
After this commit, the remaining drivers that don't set the CAP are
d3d12, softpipe, etnaviv, and i915g. I am unsure about d3d12, but the
latter 3 could probbaly enable it trivially for the same reason.
v2: Don't use copy_resource path for persistent mappings (Emma). Emma
explained on GitLab:
I don't think you should have the copy_resource path taken for
PIPE_RESOURCE_FLAG_MAP_PERSISTENT BOs. Imagine the user has a
general-purpose BO they're streaming stuff into and doing draws that
they keep persistently mapped until wrapping. They call some GL
function on the same buffer that does a fallback write map on the BO
(u_default_buffer_subdata, util_resource_copy_region, whatever) -- the
buffer is in use, copy triggers, allocates a new BO. Whoops, the user's
pointer for streaming writes is now freed.
Closes: #7570
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19351>
Some tricky dynamic states still need to be implemented for full ds3
support with Zink, I will implement them later.
Pass dEQP-VK.pipeline.*extended_dynamic_state* on NAVI21.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18882>
Another manual re-sync with reality.
There are a few extension, notably GL_ARB_texture_compression_bptc,
which are exposed but mesamatrix doesn't show as supported. I can't
really figure out why.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19100>
This is now done for all drivers that supports half-float and sRGB
textures. Update features.txt to reflect this.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18574>
This extension adds new NONE attachment load / store operations,
which are identical to the DONT_CARE variants with the difference
that DONT_CARE doesn't ensure that the original contents of the
memory within the render area are preserved and these new versions
do (with some caveats).
Our implementation was not destroying data with DONT_CARE anyway
so we already support the new semantics. Our implementation is
such that we don't need to do anything specific with the new
operations and the current behavior will do what is expected.
We pass all the tests under:
dEQP-VK.renderpass*.load_store_op_none.*
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18570>
This is a trivial implementation where we just insert a UBO descriptor
pointing to the actual data and then treat it as a normal UBO everywhere
else. In theory an indirect CP_LOAD_STATE would be more efficient than
ldc.k to preload inline uniform blocks to constants. However we will
always need the UBO descriptor anyway, even if we lower the limits
enough to always be able to preload them, because with variable pointers
we may have a pointer that could be to either an inline uniform block or
regular uniform block. So, using an indirect CP_LOAD_STATE should be an
optimization on top of this.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17960>
