We now have support for baseline MSAA, except for support for eMRT. But hey,
this gets us 99% of the way there, so it's worth flipping on at least in
agx/next.
We can also advertise dual-source blending again. It was reverted since Chromium
freaks out with dual-source blending on a GL 2.1 driver, but since we're
advertising GL 3.1 now, it's ok.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23480>
Handle the other pipeline stats counters in order to implement
GL_ARB_pipeline_statistics_query. Note that this does away with
collecting *all* the counters if DEBUG_COUNTERS is enabled, other-
wise it was getting over-complicated.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23301>
I hadn't been keeping this up-to-date as development was rapid but
now that we're starting to stabilize and new work is largely going
to be new extensions, it makes sense to start tracking this better.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23038>
This code was originally based on the Panfrost implementation, but has been
improved in a number of ways.
1. Transform feedback programs are dispatched generically with Gallium calls,
rather than emitting something hardware-specific. This is cleaner and
portable to future GPUs.
2. Transform feedback with indexed draws is now fixed, by lowering to an index
buffer pull.
3. Transform feedback with buffer overflows is now fixed, by correctly
bounds checking in transform feedback programs.
4. Transform feedback with strips/fans/loops are fixed, by correctly
tessellating to the underlying primitives as required by OpenGL.
5. Transform feedback with QUADS is fixed, by tessellating to triangles as
required by OpenGL.
That said, the code is still not in its final form.
1. It still does not support indirect draws. This will require a substantial
overhaul to do tracking on the GPU instead of the CPU. Currently we force
unroll indirect draws (slow but kosher in GL, treif in Vulkan). This isn't
hard to solve but I'm not going to duplicate the code until the algorithms
are otherwise complete because it's a lot easier to hack on the CPU versions
than the GPU versions.
2. It still does not support primitive restart. This has especially nasty
interactions with transform feedback. Again we force unroll to non-primitive
restart forms, again slow but kosher in GL but treif in Vulkan. This is a lot
harder to deal with. I sketched out something really nasty in my notebook
(hinging on efficient GPU prefix sums) but I'm not in a hurry to type this
out.
3. There will be interactions with geometry and tessellation shaders and I don't
think I can get the core code here future-proofed without actually bringing
up the new shader stages.
As such, this is a hard fork of the panfrost code for now, I'm not trying to
share the code (although it *would* clear out almost all of panfrost's transform
feedback related piglit failures).
Passes dEQP-GLES3.functional.transform_feedback.* and most of the relevant
piglits.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22891>
Implement buffer textures in full generality. There are a few issues here:
* OpenGL requires buffer textures support a minimum size of 65536 elements,
however 1D textures in AGX are (at most) 8192 elements.
* OpenGL 4.0 (and OpenGL ES) require buffer textures to support the "RGB32"
texture formats. These are 3 packed channels of 32-bits each. In general,
non-power-of-two texel sizes are problematic. AGX does not support any such
formats and we rely on the GL frontend to lower to a padded format (RGBX) if
necessary. Such a lowering cannot work for buffer textures, however, so we
need to find a way to implement RGB32 buffer textures.
We solve these issues in the follow way:
* Use 2D texture descriptors for buffer textures, with a large fixed
power-of-two size along one axis. Then large texel indices may be accessed at
a small vec2 texel coordinate, and since the fixed dimension is a
power-of-two, that vector may be recovered by simply shifting and masking.
This effectively avoids size restriction. We do need to clamp texel indices to
the buffer size to avoid faulting on OOB reads, since we may read past the end
of the buffer (if the app binds a non-page-aligned offset into the buffer).
* Use a general purpose memory load for RGB32 buffer textures. Lower the texture
load instruction to a memory load from the buffer and some address arithmetic.
There's no format conversion needed for RGB32, other than maybe filling in a
format-appropriate alpha, so this is straightforward. Again, we need to clamp
the texel index for robustness with OOB reads.
Each of these solutions brings its own problem.
* Using 2D textures instead of 1D requires physically rounding up the buffer
size when packing the descriptor, so we can no longer implement textureSize()
by reading off the texture descriptor like normal.
* We don't know at compile-time whether a given texture load will read from an
RGB32 buffer texture or not, so we need to emit code for both. In Vulkan, we
can't key the shader to this property, either, since it's descriptor set state
and not pipeline state.
And each of these problems in turn brings its own solution:
* The texture descriptor is linear, so the "compression buffer address" field is
ignored by the hardware. We stash the real buffer size there so that
textureSize becomes a load from the texture descriptor like usual, without
requiring a sideband (which would complicate bindless textures).
* If we determine a texture descriptor contains RGB32 data, then it will never
be interpreted by the hardware and hence does not need to be a valid texture
descriptor. So, we extend the hardware's format enum to contain a
software-defined RGB32 format enum. Then, when lowering texture buffer loads,
we either read it as a typed RGB32 memory load or as a texture load depending
on the value of the format field in the texture descriptor.
All of this is accomplished with a big NIR pass generating a pile of strange
looking code. But it should be good enough in practice for this silly feature.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21672>
The previous lowering was insufficient in two areas:
* No support for indirection. This is required for dynamically indexing into
UBOs, SSBOS, etc in OpenGL ES 3.2
* Only a single table supported. Multiple tables are required to implement
indirect dispatch/draws efficiently, in order to bind the indirect buffer as
uniforms.
The first problem is addressed here by reworking the lowering of
system values to happen in NIR, decoupled from the uniform register assignment
details, such that we can handle 1:n lowerings in a straightforward way.
Namely, indirect sysvals are lowered to indirect memory loads relative to the
base address of the sysval table, where the table address is itself pushed as a
(direct) sysval.
The second problem is addressed in this patch by generalizing to multiple
uniform tables.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21703>
Strictly, this extension was already advertised, but it didn't seem nice to mark
it DONE when there was no sync support in the driver whatsoever. Mark it done
now that we do have proper explicit sync (well, in conjunction with the "add
Linux UAPI" patches that are blocked on getting the kernel driver upstream, but
that's needed for *any* of these extensions to be there!)
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21676>
Original patches wrote by Ella Stanforth.
Alejandro Piñeiro main changes (skipping the small fixes/typos):
* Reduced the list of supported formats to
VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and
VK_FORMAT_G8_B8R8_2PLANE_420_UNORM, that are the two only
mandatory by the spec.
* Fix format features exposed with YCbCr:
* Disallow some features not supported with YCbCr (like blitting)
* Disallow storage image support. Not clear if really useful. Even
if there are CTS tests, there is an ongoing discussion about the
possibility to remove them.
* Expose VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT, that is
mandatory for the formats supported.
* Not expose VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Some
CTS tests are failing right now, and it is not mandatory. Likely
to be revisit later.
* We are keeping VK_FORMAT_FEATURE_2_DISJOINT_BIT and
VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Even if they
are optional, it is working with the two formats that we are
exposing. Likely that will need to be refined if we start to
expose more formats.
* create_image_view: don't use hardcoded 0x70, but instead doing an
explicit bit or of VK_IMAGE_ASPECT_PLANE_0/1/2_BIT
* image_format_plane_features: keep how supported aspects and
separate stencil check is done. Even if the change introduced was
correct (not sure about that though), that change is unrelated to
this work
* write_image_descriptor: add additional checks for descriptor type,
to compute properly the offset.
* Cosmetic changes (don't use // for comments, capital letters, etc)
* Main changes coming from the review:
* Not use image aliases. All the info is already on the image
planes, and some points of the code were confusing as it was
using always a hardcoded plane 0.
* Squashed the two original main patches. YCbCr conversion was
leaking on the multi-planar support, as some support needed
info coming from the ycbcr structs.
* Not expose the extension on Android, and explicitly assert that
we expect plane_count to be 1 always.
* For a full list of review changes see MR#19950
Signed-off-by: Ella Stanforth <estanforth@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19950>
