This enables GL applications to be written without any involvement of
Xlib.
EGL X11 platform is actually already xcb-only underneath, so this commit
just add the necessary interface changes so eglDisplay can be created
from a xcb_connection_t.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6474>
So far, we have only been supporting X11, so we assumed that we were running
inside X11 and would always try to get an authenticated fd from Xorg during
device initialization. While this works for desktop Raspbian, it is not
really correct and it is not what we want to do when we start considering
other WSIs.
Initially, one could think we can still do this by guarding the WSI code
under the proper instance extension check. This, however, doesn't work
reliably, as the Vulkan loader can call vkEnumerateDevices without enabling
surface extensions on the instance, which then can lead to us not
initializing any display_fd and failing with VK_ERROR_INITIALIZATION_FAILED,
which is not correct, so while we can try to acquire the display_fd here,
it might not always work, and we should definitely not fail initialization
of the physical device for that.
Instead, with this change we move acquisition of display_fd to swapchain
creation time where required extensions need to be enabled in the instance.
This was also suggested by Daniel Stone during review of a work-in-progress
implementation for the Wayland WSI.
There is a special case to consider though: applications like Zink that
don't use Vulkan's swapchains at all but still allocate images that they
intend to use for WSI. We need to handle these by checking that we have
indeed acquired a display_fd before doing any memory allocation for WSI,
and acquiring one at that time if that's not the case.
This change also removes the render_fd and display_fd fields from the
logical device (which we were copying from the physical device), because
now there is no guarantee that we have acquired a display_fd at the
time we create a logical device. Instead, we now put a reference to the
physical device on the logical device from which we can access these.
Finally, this also fixes a regression introduced with VK_KHR_display, where
if that extension is enabled but we are running inside a compositor, we would
acquire a display_fd that is not authenticated and try to use that instead
of acquiring an authenticated display_fd from the display server.
Fixes: b1188c9451 (v3dv: VK_KHR_display extension support)
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7546>
Commit eda3e4e055 moved the creation of
s->info.name to shader creation time, rather than after the compile.
A few lines after creating the shader, prog_to_nir clobbers s->info
entirely, losing the name.
This dropped the "ARB" indicator that iris uses to switch math to the
legacy non-IEEE mode used by ARB_vertex_program/fragment_program.
Revert that hunk and go back to doing things the way they were.
Fixes: eda3e4e055 ("nir/builder: Add a name format arg to nir_builder_init_simple_shader().")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3777
Acked-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7564>
In commit eda3e4e055, Eric added names
to various programs. In that patch, he also renamed our passthrough
TCS shader from "passthrough" to "passthrough TCS". The passthrough
TCS directly supplies the VUE headers rather than doing the whole
"patch parameters are in backwards order" reswizzling dance.
We failed to detect this and started trying to supply vec4s starting
at component 3, leading to a stack smash on an array of 7 sources,
not to mention the values were being put in the wrong place.
Easy fix: update the code for the new name.
Fixes: eda3e4e055 ("nir/builder: Add a name format arg to nir_builder_init_simple_shader().")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3777
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7564>
Seems some sort of linux change (bugfix?) resulted in the db410cs
selecting device mode for the db410cs due to the micro cable being
plugged in (fastboot runs them in device mode), so we weren't finding
the network and getting artifacts out.
Closes: #3728
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6971>
I'm surprised these were listed as flaky instead of xfails, since I would
have expected them to always fail given my experience on freedreno and
broadcom. But let's try turning them back on and see if it's actually
flaky since the test has been fixed.
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6971>
I want the new version to show the fix in the fd-largeconsts branch (and
make sure the pass keeps working, and make sure other drivers get around
to fixing the issue). While I'm here, cherry-pick in the VK test along
with the GLES one, and also the fix for clip_three on ARMs.
Since the VK and GL test lists were changing, I took the opportunity to
reset freedreno xfails lists to just the tests that are being run with the
CTS uprev, and increase its coverage to 1/10th of the CTS across two
boards (since we just freed up a bunch of runtime with the grouped gles
"other" job).
For panfrost, I didn't spend the time characterizing the t720 fragment_ops
flakes like I did for the deqp-runner change. Given that the random
behavior changes between CTS versions, it doesn't seem to be worth the
time to do so.
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6971>
The recent change to install kernel modules for AMD included a sed job to
disable kernel modules in the defconfig. This somehow broke booting on
a307, except the commit failed to bump the arm64_test tag so it wasn't
noticed until the next uprev. (I didn't notice when landing the next
change to that container to add the deqp runner, because I didn't get a
git conflict on rebasing my tag bump so I didn't bump the tag again to
pull in the kernel changes and catch the fail).
I've spent a while trying to debug what's happened (including what
*should* be a replication of the kernel build on my local db410c) and come
up empty. Just punt and disable the AMD kernel module changes on
baremetal to fix it. Bump every container using lava_build.sh to make
sure we don't screw anything up with the script changes.
Fixes: 60c5729d16 ("ci: Distribute ADMGPU driver to LAVA as a module")
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6971>
This cleans up a bunch of gross sprintfs and keeps the caller from needing
to remember to ralloc_strdup. I added a couple of '"%s", name ? name :
""' to radv where I didn't fully trace through whether a non-null name was
being passed in.
I also took the liberty of adding a basic name to a few shaders (pan_blit,
unit tests)
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7323>
These two consumers were the only ones out of the ~65 calls to
init_simple_shader, so there's a pretty clear consensus on how to allocate
simple shaders. I suspect that actually these would be just fine with
b.shader being the mem_ctx, but that would take a bit more rework.
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7323>
Rather than hard-code a list of all the format
modifiers supported by any gallium driver and the
number of aux planes they require in the dri state
tracker, add a screen proc that queries the number
of planes required for a given modifier+format
pair.
Since the only format modifiers that require
auxiliary planes currently are the iris driver's
I915_FORMAT_MOD_Y_TILED_CCS,
I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS, and
I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS, the absence
of the screen proc implies zero aux planes for all
of the screen's supported modifiers. Hence, when
a driver does not expose the proc, derive the
number of planes directly from the format.
Signed-off-by: James Jones <jajones@nvidia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3723>
Add a "do you support this modifier?" query to all
drivers which support format modifiers. This will
be used in a subsequent change to fully
encapsulate modifier validation and auxiliary plane
count calculation logic behind the driver
abstraction, which will in turn simplify the
addition of device-class-specific format modifiers
in the nouveau driver.
Signed-off-by: James Jones <jajones@nvidia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3723>
dEQP-VK.pipeline.blend.dual_source.format.r16g16b16a16_snorm.states.color_1msc_1ms1a_add_alpha_1mdc_1msa_sub-color_dc_1ms1c_rsub_alpha_z_1mdc_sub-color_ca_1ms1c_min_alpha_sas_ca_rsub-color_1ms1c_s1c_add_alpha_z_1mda_add,Fail
dEQP-VK.pipeline.blend.dual_source.format.r8g8_snorm.states.color_z_sc_add_alpha_1ms1c_sa_min-color_dc_1mca_add_alpha_z_1mca_max-color_1ms1c_sa_max_alpha_1mcc_sc_sub-color_s1c_1mda_add_alpha_s1c_1mda_add,Fail
dEQP-VK.pipeline.blend.dual_source.format.r8g8b8a8_snorm.states.color_1msc_1ms1a_add_alpha_1mdc_1msa_sub-color_dc_1ms1c_rsub_alpha_z_1mdc_sub-color_ca_1ms1c_min_alpha_sas_ca_rsub-color_1ms1c_s1c_add_alpha_z_1mda_add,Fail
dEQP-VK.pipeline.blend.dual_source.format.r8g8b8a8_snorm.states.color_z_sc_add_alpha_1ms1c_sa_min-color_dc_1mca_add_alpha_z_1mca_max-color_1ms1c_sa_max_alpha_1mcc_sc_sub-color_s1c_1mda_add_alpha_s1c_1mda_add,Fail
dEQP-VK.pipeline.blend.format.r16g16b16a16_snorm.states.color_ca_1mca_rsub_alpha_1mda_z_sub-color_sc_sc_add_alpha_1mca_sa_max-color_sa_1msa_min_alpha_1msc_sa_sub-color_dc_sc_add_alpha_1mdc_1mca_add,Fail
dEQP-VK.pipeline.blend.format.r8g8b8a8_snorm.states.color_ca_1mca_rsub_alpha_1mda_z_sub-color_sc_sc_add_alpha_1mca_sa_max-color_sa_1msa_min_alpha_1msc_sa_sub-color_dc_sc_add_alpha_1mdc_1mca_add,Fail
All fail due to the 1 - mdc or 1 - mca alpha channel in the last quadrant.
Cc: 20.3 <mesa-stable>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7499>
If we have cbufs but they are all empty, default
to returning the fb->samples.
Fixes:
dEQP-VK.pipeline.multisample.mixed_count.1_4_unused
on lavapipe
v2:
drop unneeded chunk (Roland)
Cc: 20.3 <mesa-stable>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7499>
Some drivers will drop warnings about seeing these structs in the
pNext chain and not handling them. This change makes it so we
only include the structs with Vulkan drivers that are known to
require them for proper behavior (v3dv only for now) to avoid the
warnings.
It should be noted that here we are only supressing the messages
from Zink. Since the Mesa Vulkan WSI code will include these structs,
when native Vulkan Mesa drivers are used without Zink they might
still dump these messages.
Requested by Mike Blumenkrantz.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7523>
We can use num_blocks (if it's been initialized by some pass indexing
blocks) to pre-size our table, which helps on validating shaders with many
blocks which would otherwise reallocate the set several times.
No statistically significant performance difference on softpipe
KHR-GL33.texture_swizzle.functional runtime (n=15). A previous, similar
variant of this patch cut .3% of instructions in softpipe shader-db ./run
shaders/closed/steam/borderlands-2/35* (an arbitrary set of shaders that
completed in reasonable amount of time) according to callgrind.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7244>
This implementation was broken and should have just been the same as the
hash_table_clear() one, which I copied over here. It was setting all
formerly-present entries to deleted, yet also setting deleted_entries to
0. This meant that all new searches or additions after clearing would
have to reprobe the whole table until a rehash happened, and that rehash
would be delayed because we violated the deleted_entries invariant.
No statistically significant performance difference on softpipe
KHR-GL33.texture_swizzle.functional runtime (n=18)
Fixes: 5c075b0855 ("util/set: add a set_clear function")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7244>
Use the entry_is_present() helper to clarify what's going on with
deletion, and then we can remove the special continue for NULL since we're
just writing NULL anyway (which the CPU cache will elide for us).
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7244>
