Age | Commit message (Collapse) | Author |
|
|
|
All built-in renderers now implement the new API.
|
|
It can be a bit confusing to debug when the user requests an
explicit renderer but it's disabled at build-time. Log an error
when that happens.
|
|
Pixman won't be chosen by default if the system has a valid render node
but gles2 and vulkan creation failed.
|
|
|
|
|
|
Only open a render node if we actually need one (ie, if we're about
to attempt GLES2 or Vulkan).
|
|
Let's not allow renderer implementations to mutate the passed in
options.
|
|
This is a bit more type-safe.
|
|
|
|
Based on five calls:
wlr_render_timer_create - creates a timer which can be reused across
frames on the same renderer
wlr_renderer_begin_buffer_pass - now takes a timer so that backends can
record when the rendering starts and finishes
wlr_render_timer_get_time - should be called as late as possible so that
queries can make their way back from the GPU
wlr_render_timer_destroy - self-explanatory
The timer is exposed as an opaque `struct wlr_render_timer` so that
backends can store whatever they want in there.
|
|
Add a render pass implementation which leverages the legacy
rendering API. This is helpful during the migration.
|
|
Goals:
- Extensibility: we need to be able to add new params to the calls
to render a texture/rect. For instance we'll need to add fences to
the render texture operation for explicit sync purposes.
- No implicit state: no more bind_buffer, begin, end.
- No matrices: these hurt Pixman and we don't need them.
- Clip regions for optimized damage repainting.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3188
|
|
Use early returns to remove the !renderer checks.
|
|
|
|
To be able to add support for newer versions without breaking
changes.
|
|
Make it clear this is a helper consuming a wlr_renderer. We'll
add a lower-level create() function which doesn't take it in the
next commit.
|
|
|
|
|
|
|
|
These are unused.
|
|
If we have a render node, it means there is a GPU which could be
used. We probably failed GL because of a kernel or Mesa issue.
Instead of automatically falling back to Pixman, error out.
This makes it more obvious to users when something goes wrong,
instead of silently exposing a slow unaccelerated desktop.
References: https://github.com/swaywm/sway/issues/7194
|
|
The Vulkan renderer is still experimental. If GL fails, we don't
want to automatically fall back to it by default.
Fixes: 8bd7170fd95a ("Use env helpers")
|
|
|
|
|
|
|
|
Ensures there is no field left to its previous undefined value after
calling an init function.
|
|
This allows compositors to initialize wl_shm without initializing
other globals like linux-dmabuf.
|
|
This env var allows to override the DRM node used by the GLES2 and
Vulkan renderers. It's especially useful to select a DRM node when
running with the headless backend.
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/2656
|
|
If the backend hasn't picked a DRM FD but supports DMA-BUF, pick
an arbitrary render node. This will allow removing the DRM device
selection logic from the headless backend.
|
|
This new renderer is implemented with the existing wlr_renderer API
(which is known to be sub-optimal for some operations). It's not
used by default, but users can opt-in by setting WLR_RENDERER=vulkan.
The renderer depends on VK_EXT_image_drm_format_modifier and
VK_EXT_physical_device_drm.
Co-authored-by: Simon Ser <contact@emersion.fr>
Co-authored-by: Jan Beich <jbeich@FreeBSD.org>
|
|
Now that we have our own wl_drm implementation, there's no reason
to provide custom renderer hooks to init a wl_display in the
interface. We can just initialize the wl_display generically,
depending on the renderer capabilities.
|
|
|
|
Everything needs to go through the unified wlr_buffer interface
now.
If necessary, there are two ways support for
EGL_WL_bind_wayland_display could be restored by compositors:
- Either by using GBM to convert back EGL Wayland buffers to
DMA-BUFs, then wrap the DMA-BUF into a wlr_buffer.
- Or by wrapping the EGL Wayland buffer into a special wlr_buffer
that doesn't implement any wlr_buffer_impl hook, and special-case
that buffer type in the renderer.
|
|
|
|
The types of buffers supported by the renderer might depend on the
renderer's instance. For instance, a renderer might only support
DMA-BUFs if the necessary EGL extensions are available.
Pass the wlr_renderer to get_buffer_caps so that the renderer can
perform such checks.
Fixes: 982498fab3c4 ("render: introduce renderer_get_render_buffer_caps")
|
|
Make it clear this function is a private wlroots API and will stay
that way.
|
|
This allows compositors to choose a wlr_buffer to render to. This
is a less awkward interface than having to call bind_buffer() before
and after begin() and end().
Closes: https://github.com/swaywm/wlroots/issues/2618
|
|
This probably already felt apart, but let's make it explicit that
this is not allowed.
|
|
This function is only required because the DRM backend still needs
to perform multi-GPU magic under-the-hood. Remove the wlr_ prefix
to make it clear it's not a candidate for being made public.
|
|
Makes it easier to figure out why a backend/renderer is picked.
|
|
|
|
Prior to this commit, WLR_RENDERER was only looked up when the
backend returned a DRM FD.
Make it so WLR_RENDERER is always looked up, so that running wlroots
on a system without a GPU and with WLR_RENDERER=gles2 fails as
expected instead of falling back to the Pixman renderer.
|
|
This env var forces the creation of a specific renderer. If no renderer
is specified, the function will try to create all of the renderers one
by one until one is created successfuly.
|
|
Allow selecting whether the GLES2 renderer gets enabled.
Co-authored-by: Simon Ser <contact@emersion.fr>
|
|
|
|
|
|
|
|
The get_drm_fd was made available in an internal header with a53ab146f. Move it
now to the public header so consumers opting in to the unstable interfaces can
make use of it.
|
|
For anything more complicated than quads, compositors can easily
ship their own shaders.
Closes: https://github.com/swaywm/wlroots/issues/2759
|