This lowers line-stippling to a combination of geometry and fragment
shaders:
- The geometry shader computes the length of each line-segment, and
outputs a varying that produces the stipple position.
- The fragment shader looks up the stipple position in the
stipple-pattern once per sample, and updates the sample mask
accordingly.
In case there's no geometry shader in place, we create a new
pass-through shader.
We should probably not declare the the push-constants in the pipeline
layout unless they're actually needed. But we already do this
unconditionally for the vertex shader and tesselation push-constants, so
let's do it unconditionally for these as well for now.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19117>
Right now, it's only the vertex-shader that needs special handling for
non-optimal keys. That makes it possible to use fallthrough to always
end up in the last-vertex-stage conditional.
But we're about to add special handling for the geometry stage as well,
so let's prepare by splitting the switch-statement in two; one that only
happens for non-optimal keys, and does all the needed processing there,
and one that deals with the rest.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19117>
Line-stipple lowering is going to need some geometry-shader specific
lowering, so lets give the GS its own shader-key struct.
The GS variant only needs a non-optimal variant, so let's assert that to
be sure.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19117>
There's two notable limitations here:
- This will viewport-map to viewport #0 only. This is because we need
the viewport-scale factors, which we'll be uploading using
push-constants. And we don't want to waste too many of those...
- It's missing a "global" stipple-counter. It doesn't seem like there's
a portable way of implementing this, so this is going to require a VK
extension that can be implemented in a hardware-specific way in the
long run. For now, let's just ignore the global stipple counter.
These two limitations don't seem viable to overcome for now, so but this
is better than nothing.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19117>
This is not ideal, but at least it should work. In the long run, we
might want to store a bit per mode we're missing, so we can do this
conditionally. But that's quite a bit more complicated, so let's go with
this for now.
The line-stippling logic needs non-optimal shader-keys. So let's drop
some perf on the floor here.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19117>
This probably wasn't noticed earlier because tests using sRGB storage
images didn't exist, and we didn't know whether this works, but this
fixes dEQP-VK.image.store.without_format.2d.*_srgb which also proves
that the bit works.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20060>
The coefficient register is 16-bit so our builder will make the iter 16-bit too
(maybe not the best design...), force fp32 to match the NIR intrinsic.
Fixes glsl-fs-fragcoord-zw-ortho
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20017>
We can implement glPolygonMode(GL_FRONT_AND_BACK, ...) natively. What we can't
implement natively are two-sided polygon modes. For that Apple has a nontrivial
lowering which I don't feel the need to implement unless someone actually hits a
workload other than Piglit that uses it.
Vulkan requires only one-sided polygon modes (so this is sufficient there), and
GLES doesn't have polygon modes at all. If an app hits the unimplemented case,
throw a warning like Zink does.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20017>
This option didn't exist half a decade ago when I first implemented base
workgroup support in ANV. It's cleaner to just have split system values
like all the other zero_base+base things do.
We currently only do this for COMPUTE and not KERNEL because it lets us
avoid changing intel_clc for now. We can add KERNEL later if needed.
We also don't do this lowering for task/mesh.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20068>
Enable AFBC for all RGBA UNORM formats possible in v5. This does not
cover the AFBC rules for newer gens, nor for YUV.
Noticed with an uncompressed R8 UNORM texture in SuperTuxKart.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19758>
AFBC of sRGB formats should just work. We just need to flip it on and enjoy
the improved performance.
In particular, this means that RGBA8 UNORM and RGBA8 sRGB UNORM are now
considered compatible formats for AFBC. That's a bug fix, because
GALLIUM_HUD use will act like a texture view between sRGB and linear
views. For FBOs, that will "just" result in a decompression, hurting
performance. For window system rendering with AFBC, that will cause an
assertion failure, as we cannot decompress SHARED resources.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19758>
Missed by mistake. This is not the same as 3D AFBC, it's just like a 2D
array. Noted in a supertuxkart pandecode.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19758>
We're about to enable AFBC on more formats in the core AFBC code. The plane
descriptor packing needs to be aware of these new formats.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19758>
Move them up to where the other conversion helpers. For nir_b2<T>(),
suffix them with N like all the others and make them use
nir_type_convert() as well.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20067>
