If we're doing separate front/back stencil ops, then in the absence of a
hardware bit for setting front_ccw (which you can already see from how we
manage cull face) we need to flip front/back stencil register settings.
Closes: #4974, #4975
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11706>
This allows more potential compiler optimizations if the value is a
constant or from a scalar load.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11579>
I believe these Gallium caps imply these Vulkan features. If they don't,
then we got things wrong on the Zink side as well ;)
While we're at it, query shaderStorageImageWriteWithoutFormat based on
the PIPE_SHADER_CAP_MAX_SHADER_IMAGES cap. This matches what the gallium
OpenGL frontend does.
This brings Zink on Lavapipe up to OpenGL 4.5.
For some reason, a bunch of PBO tests starts failing on CI for Zink, but
that doesn't seem like a Lavapipe problem...
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10467>
LLVMpipe has a rather limited implementation of shader-images, so let's
limit what we report to the formats required by the spec, as all of
those seems to work fine.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10467>
Assuming all formats are supported here isn't a good plan; we
don't actually support all formats.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10467>
A run of dEQP-VK.*geom* has 6328 test passes and 16 failures. 14 of
these failures are related to a CTS bug affecting atomic operations
for which I submitted a CL to Khronos. Another fail looks like it might
be a case of the error threshold in CTS being slightly low. There is
only one test fail in that list that looks like it might be an actual
driver bug, but it is a variable pointers test, so it might be unrelated
to geometry shaders in the end.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11783>
This was required to handle the case of secondary command buffers that
did not have framebuffer information available from the primary, since
we used to have an implementation that required this information to
be available for the fallback path of vkCmdClearAttachments. Now that
we can handle our our attachment clears in the current subpass by
emitting draw calls, we no longer need the framebuffer information to
be available and we can remove this.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11783>
Now that we have geometry shaders, we can leverage this to implement
clears of layered framebuffers by adding a geometry shader in our
clear pipelines that redirects the clear rect to the appropriate
layer in the framebuffer, instead of falling back to emitting separate
clear jobs for each layer, which is a lot slower.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11783>
Clip distance arrays will come as compact array variables, so we need
to handle them as such, like we did for vertex inputs.
Fixes:
dEQP-VK.clipping.user_defined.clip_distance.vert_geom.{1,2,3,4}
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11783>
There is a bit of a corner case here for secondary buffers that
don't inherit framebuffer information, since those won't have
access to the number of layers in the framebuffer by the time
we get here. Since we only emit this to sanitize the value of
gl_Layer produced from geometry shaders, I think it is probably
fine to lie about it and just use the maximum number of layers
we support. The only issue with that is that broken shaders that
emit out of bounds layer indices (which the spect states may lead
to unfined shading results) may cause undefined results.
In the future we could do better and patch the uniform streams
later when the secondary is executed inside a primary, since we
will have the required framebuffer information at that point,
but for now this seems like a reasonable compromise.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11783>
I removed this because I thought the state tracker could handle it,
and it really should handle it, but it has some minecraft side effects
I'm unsure about. This fixes the problem for now, we can revisit it later.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11822>
Emma Anholt
Samuel Pitoiset
Erik Faye-Lund
Daniel Stone
Jason Ekstrand
Marcin Ślusarz
Daniel Schürmann
Thomas H.P. Andersen
Lionel Landwerlin
Icecream95
Iago Toral Quiroga
Dave Airlie
Alyssa Rosenzweig
Mike Blumenkrantz