We shouldn't try to use geometry shaders on implementations that don't
support them. So let's verify the feature before using it.
Fixes: 8028991f36 ("zink: enable gs pipe caps")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7287>
other than the vaguely gross case of primitive restart with incompatible
draw modes and/or restart index, this is no trouble since the buffer formats
are compatible
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7191>
We don't support SSBOs yet, as we don't expose the
PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT-cap. But the gallium
state-tracker's limit-calculation gets confused by this half-way
support, and ends up thinking we can support atomics, which we
don't support yet either.
So let's not confuse the state-tracker here, and let's introduce this
again when SSBOs are actually supported.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7113>
using max(Uniform|Storage)BufferRange yields some insane values that aren't
consistent with reality
affects PIPE_CAP_MAX_SHADER_BUFFER_SIZE and PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6981>
this is just a find-and-replace from screen->... to screen->info.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6789>
All drivers that support mediump lowering should support 16BIT_TEMPS,
but some do not also want 16b consts to be lowered. Replace the pipe
cap in preperation to remove LowerPrecisionTemporaries.
Note: also updates reference checksums for the arm64_a630_traces job,
due to lowering more to 16b
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6189>
this value gets split between ssbos and abos, so clamping to 8 here causes
a number of tests to fail just because there's not enough buffers available
other gallium drivers return 32 here, so this seems pretty safe
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5913>
this requires some modifications to the ntv slot remapping, as we definitely
don't want to reserve another 25% of the available slots for the (deprecated)
texcoord varyings
now we remap VARYING_SLOT_TEX[n] to the last available slots, which lets us avoid
needing to do permanent reservation, and we check to make sure that we haven't
seen the corresponding texcoord varying any time we emit a non-texcoord varying in
that slot
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5551>
this is a simple extension that enables using uint8-sized index buffers,
which lets us avoid having those go through primconvert
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5712>
extensions need to have their feature structs passed in pNext to be enabled,
so switch to using the feature struct here in preparation for that
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5163>
this cap creates a different varying output which remains constant to be
emitted by xfb, allowing us to drop the special-casing code in ntv
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5163>
this adds:
* context hooks for gallium stream output methods
* handling for xfb-related queries
* barrier management for pausing and resuming xfb
loosely based on patches originally written by Dave Airlie <airlied@redhat.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5163>
technically both the extension and feature should be checked when enabling
extensions, and some features cannot be properly enabled without using
the more descriptive versions of these APIs
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5163>
This lets us enable PIPE_CAP_FRAGMENT_SHADER_TEXTURE_LOD, which in turns
gives us ARB_shader_texture_lod.
Still fails one piglit test on ANV, namely
spec@arb_shader_texture_lod@execution@arb_shader_texture_lod-texgradcube,
but with 33 new passing tests, I think this is worth it.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3140>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3140>
Vulkan only allows power-of-two sample counts. We already kinda checked
for this, but forgot to validate the result in the end. Let's check the
result and error properly.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
To make PIPE_FORMATs usable from non-gallium parts of Mesa, I want to
move their helpers out of gallium. Since u_format used
util_copy_rect(), I moved that in there, too.
I've put it in a separate directory in util/ because it's a big chunk
of related code, and it's not clear to me whether we might want it as
a separate library from libmesa_util at some point.
Closes: #1905
Acked-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
When using packed vulkan-formats on little-endian systems, we need to
swap the components for the gallium formats. And since Zink isn't
big-endian safe yet, little-endian is the only endianess we care about
right now.
This fixes a bunch of piglit tests, amongs others:
- spec@arb_depth_texture@depth-level-clamp
- spec@arb_depth_texture@depthstencil-render-miplevels * d=z24
- spec@arb_depth_texture@fbo-depth-gl_depth_component24-blit
- spec@arb_depth_texture@fbo-depth-gl_depth_component24-copypixels
- spec@arb_depth_texture@fbo-depth-gl_depth_component24-drawpixels
- spec@arb_depth_texture@fbo-depth-gl_depth_component24-readpixels
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Fixes: 8d46e35d16 ("zink: introduce opengl over vulkan")
We don't support nir_texop_txd, which is required by this cap. So let's
disable it for now.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Fixes: 8d46e35d16 ("zink: introduce opengl over vulkan")
We do not support them yet, so let's not pretend.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Fixes: 8d46e35d16 ("zink: introduce opengl over vulkan")
While we're at it, make sure we error out if it's not supported when
required.
This brings us a bit closer to being able to test on SwiftShader, which
doesn't currently support KHR_external_memory_fd.
The Vulkan spec says that an implementation has to support one of
VK_FORMAT_X8_D24_UNORM_PACK32 and VK_FORMAT_D32_SFLOAT, as well of
one of VK_FORMAT_D24_UNORM_S8_UINT and VK_FORMAT_D32_SFLOAT_S8_UINT.
So let's keep track which one is supported of earch pair, and emulate
one on top of the other one.
This won't give the exact result for comparisons, or when mapping and
unmapping the resources. But it's better than flat out failing to create
the resource, and we can fix the map/unmap issue later if needed.
Tested-by: Duncan Hopkins <duncan@thefoundry.co.uk>
We're now adding interface-types during code-emitting, so we need to
defer emitting the entry-point. No biggie, spirv_builder is prepares for
this.
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
We don't implement the get_timestamp context-method, so this is just
going to crash if anyone tries to use it. Let's implement it later.
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
This isn't as inaccurate as the comment says, the Vulkan documentation
even seems to suggest this is the same. Let's drop the comment.
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
Here's zink, a so far pretty simple vulkan-gallium driver that is able
to translate some applications from OpenGL to Vulkan.
The compiler is quite limited for now, this will be improved on later.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
Erik Faye-Lund
Mike Blumenkrantz
Hoe Hao Cheng
Eric Anholt
Rob Clark
Marek Olšák
Dave Airlie
Duncan Hopkins