The current implementation in kmsro relies on buffer sharing using
WINSYS_HANDLE_TYPE_FD, which in x11 is only used by default when dri3
is enabled.
Since the current implementation will not work without it, we can
prevent user error by checking that it is not disabled at configuration
time.
Closes#4861
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11305>
In order to use the Vulkan 1.2 core viewport and layer shader outputs,
we need to use SPIR-V 1.5. But we've recently added some preliminary
support to compute the SPIR-V version we're using, with the intention of
adding a SPIR-V version override to work around bugs in tools like
RenderDoc. We haven't implemented the latter yet.
But just to be safe, let's limit this to SPIR-V 1.5. This isn't going to
matter right now, but it might avoid a problem if we decide to finish up
the SPIR-V version overriding.
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11259>
Vulkan has some additional restrictions for vkCmdBlitImage that we
weren't testing for. Quting the Vulkan 1.2 spec, section 20.5 "Image
Copies with Scaling", "Valid Usage" subsection:
- If either of srcImage or dstImage was created with a signed integer
VkFormat, the other must also have been created with a signed integer
VkFormat
- If either of srcImage or dstImage was created with an unsigned integer
VkFormat, the other must also have been created with an unsigned
integer VkFormat.
So let's make sure we reject these illegal blits.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11217>
LLVMpipe always used the bounding-box to rasterize-points, rather than
the actual rasterization-planes. This happened because the primitive was
expanded by one unit outside the bounding box. While this kinda work for
non-multisampled cases, it's not really quite *correct*.
Rasterization of non-legacy points in OpenGL is defined as the
intersection of a the pixel centers with a rectangle of size width and
height, centered around the point in viewport coordinates. This applies
both to multi-sampled and non-multisampled cases.
So let's fix the rasterizer to use the correct definition in both cases.
We leave the legacy case as-is, and just do the inverse adjustment
there so the end result should be the same.
This fixes the following dEQP test-cases:
- dEQP-GLES3.functional.rasterization.fbo.rbo_multisample_4.primitives.points
- dEQP-GLES3.functional.rasterization.fbo.rbo_multisample_max.primitives.points
...as well as this one for Lavapipe:
- dEQP-VK.rasterization.primitives_multisample_4_bit.no_stipple.points
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11183>
This does a little bit better than what we did in 2c0a078fdb
("llvmpipe: fix multisample lines."), where parts of the diamond-exit
rule stuff was bypassed. But we should actually bypass *all* of the
diamond-exit rule stuff here instead.
The reason is that multisampled lines have a completely differently
specified set of rasterization rules, as per the OpenGL 4.6 core spec,
section 14.5.4 ("Line Multisample Rasterization").
So let's give multisampled lines their own geometry-generation codepath
instead.
This fixes the following dEQP tests:
- dEQP-GLES3.functional.rasterization.fbo.rbo_multisample_4.primitives.lines
- dEQP-GLES3.functional.rasterization.fbo.rbo_multisample_max.primitives.lines
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11183>
There's no good reason why we peek into the rasterization state when
dealing with the point_quad_rasterization state, rather than set it
through lp_setup_set_point_state like other point-state.
Let's fix this up, and get rid of a needless NULL-check per primitive.
This makes the code a bit easier to read as well, and will help once
these conditions gets more complicated later on.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11183>
In 2737abb44e, the handling of pixel-offsets and edge rules were
untangled, but one case was missed.
This fixes the following dEQP test-cases on VirGL + LLVMpipe
- dEQP-GLES2.functional.draw.random.10
- dEQP-GLES2.functional.draw.random.42
- dEQP-GLES3.functional.draw.random.105
- dEQP-GLES3.functional.draw.random.114
- dEQP-GLES3.functional.draw.random.135
- dEQP-GLES3.functional.draw.random.144
- dEQP-GLES3.functional.draw.random.155
- dEQP-GLES3.functional.draw.random.174
- dEQP-GLES3.functional.draw.random.206
- dEQP-GLES3.functional.draw.random.31
- dEQP-GLES3.functional.draw.random.43
- dEQP-GLES3.functional.draw.random.84
- dEQP-GLES31.functional.draw_indirect.random.20
...as well as these on Zink + Lavapipe:
- spec@nv_primitive_restart@primitive-restart-disable_vbo
- spec@nv_primitive_restart@primitive-restart-vbo_combined_vertex_and_index
- spec@nv_primitive_restart@primitive-restart-vbo_index_only
- spec@nv_primitive_restart@primitive-restart-vbo_separate_vertex_and_index
- spec@nv_primitive_restart@primitive-restart-vbo_vertex_only
Fixes: 2737abb44e ("gallium: Replace gl_rasterization_rules with lower_left_origin and half_pixel_center.")
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11183>
This brings in some major new features in the runner:
- piglit tests now include subtest reporting
- "-t" support for quick include-filtering of tests.
- piglit tests that crash after their result report are considered crashes.
- throws a nice error if you try to annotate the same failure twice
(e.g. lvp's dEQP-VK.glsl.builtin.precision.pow.highp.vec2,Fail)
Since the runner catches piglit test bugs where the same subtest is run
twice, we also uprev piglit to pull in the fixes for those.
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11283>
We were inserting them in what was NIR's end block with the "end"
instruction, which meant that the moves they generated couldn't be
scheduled with the rest of the last block as part of post-RA scheduling.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9842>
RA currently can't handle a live value that's part of a vector and
introduces extra copies. This was espeically a problem for bary.f, where
the bary coords were being split and repeatedly re-collected. But this
could be a problem in other situations as well.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9842>
