sungmg/mutter-performance-source
1
0
Fork 0
Code Activity
mutter-performance-source/src/backends/native/meta-gpu-kms.h

79 lines
3 KiB
C
Raw Normal View History

backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
/*
* Copyright (C) 2017 Red Hat
gpu/kms: Add identifier We need a device unique id in order to uniquely identify an output, which will use a (device, connector) pair.
2018-10-11 14:12:53 +00:00
* Copyright (C) 2018 DisplayLink (UK) Ltd.
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of the
* License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
* 02111-1307, USA.
*/
#ifndef META_GPU_KMS_H
#define META_GPU_KMS_H
#include <glib-object.h>
#include <xf86drm.h>
#include <xf86drmMode.h>
#include "backends/meta-gpu.h"
backend: Move GPU ownership from the monitor manager to the backend Lets work towards making MetaMonitorManager about managing monitors, and not about managing GPUs. This changes other units to keep a pointer to the backend instead of a monitor manager, in case their ownership changed, or their main usage of the monitor manager was to look up GPUs. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-11 14:35:42 +00:00
#include "backends/native/meta-backend-native.h"
backend/native: Add and use transactional KMS API This commit introduces, and makes use of, a transactional API used for setting up KMS state, later to be applied, potentially atomically. From an API point of view, so is always the case, but in the current implementation, it still uses legacy drmMode* API to apply the state non-atomically. The API consists of various buliding blocks: * MetaKmsUpdate - a set of configuration changes, the higher level handle for handing over configuration to the impl backend. It's used to set mode, assign framebuffers to planes, queue page flips and set connector properties. * MetaKmsPlaneAssignment - the assignment of a framebuffer to a plane. Currently used to map a framebuffer to the primary plane of a CRTC. In the legacy KMS implementation, the plane assignment is used to derive the framebuffer used for mode setting and page flipping. This also means various high level changes: State, excluding configuring the cursor plane and creating/destroying DRM framebuffer handles, are applied in the end of a clutter frame, in one go. From an API point of view, this is done atomically, but as mentioned, only the non-atomic implementation exists so far. From MetaRendererNative's point of view, a page flip now initially always succeeds; the handling of EBUSY errors are done asynchronously in the MetaKmsImpl backend (still by retrying at refresh rate, but postponing flip callbacks instead of manipulating the frame clock). Handling of falling back to mode setting instead of page flipping is notified after the fact by a more precise page flip feedback API. EGLStream based page flipping relies on the impl backend not being atomic, as the page flipping is done in the EGLStream backend (e.g. nvidia driver). It uses a 'custom' page flip queueing method, keeping the EGLStream logic inside meta-renderer-native.c. Page flip handling is moved to meta-kms-impl-device.c from meta-gpu-kms.c. It goes via an extra idle callback before reaching meta-renderer-native.c to make sure callbacks are invoked outside of the impl context. While dummy power save page flipping is kept in meta-renderer-native.c, the EBUSY handling is moved to meta-kms-impl-simple.c. Instead of freezing the frame clock, actual page flip callbacks are postponed until all EBUSY retries have either succeeded or failed due to some other error than EBUSY. This effectively inhibits new frames to be drawn, meaning we won't stall waiting on the file descriptor for pending page flips. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-04-04 20:36:41 +00:00
#include "backends/native/meta-kms-types.h"
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
#define META_TYPE_GPU_KMS (meta_gpu_kms_get_type ())
G_DECLARE_FINAL_TYPE (MetaGpuKms, meta_gpu_kms, META, GPU_KMS, MetaGpu)
renderer/native: Also wrap flip closures for EGLStreams When using the EGLStream backend, the MetaRendererNative passed a GClosure to KMS when using EGLStreams, but KMS flip callback event handler in meta-gpu-kms.c expected a closure wrapped in a closure container, meaning it'd instead crash when using EGLStreams. Make the flip handler get what it expects also when using EGLStreams by wrapping the flip closure in the container before handing it over to EGL. https://bugzilla.gnome.org/show_bug.cgi?id=790316
2017-11-14 08:08:52 +00:00
typedef struct _MetaGpuKmsFlipClosureContainer MetaGpuKmsFlipClosureContainer;
backend: Move GPU ownership from the monitor manager to the backend Lets work towards making MetaMonitorManager about managing monitors, and not about managing GPUs. This changes other units to keep a pointer to the backend instead of a monitor manager, in case their ownership changed, or their main usage of the monitor manager was to look up GPUs. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-11 14:35:42 +00:00
MetaGpuKms * meta_gpu_kms_new (MetaBackendNative *backend_native,
backends/native: Add basic KMS abstraction building blocks The intention with KMS abstraction is to hide away accessing the drm functions behind an API that allows us to have different kind of KMS implementations, including legacy non-atomic and atomic. The intention is also that the code interacting with the drm device should be able to be run in a different thread than the main thread. This means that we need to make sure that all drm*() API usage must only occur from within tasks that eventually can be run in the dedicated thread. The idea here is that MetaKms provides a outward facing API other places of mutter can use (e.g. MetaGpuKms and friends), while MetaKmsImpl is an internal implementation that only gets interacted with via "tasks" posted via the MetaKms object. These tasks will in the future potentially be run on the dedicated KMS thread. Initially, we don't create any new threads. Likewise, MetaKmsDevice is a outward facing representation of a KMS device, while MetaKmsImplDevice is the corresponding implementation, which only runs from within the MetaKmsImpl tasks. This commit only moves opening and closing the device to this new API, while leaking the fd outside of the impl enclosure, effectively making the isolation for drm*() calls pointless. This, however, is necessary to allow gradual porting of drm interaction, and eventually the file descriptor in MetaGpuKms will be removed. For now, it's harmless, since everything still run in the main thread. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-29 09:24:44 +00:00
MetaKmsDevice *kms_device,
backend: Move GPU ownership from the monitor manager to the backend Lets work towards making MetaMonitorManager about managing monitors, and not about managing GPUs. This changes other units to keep a pointer to the backend instead of a monitor manager, in case their ownership changed, or their main usage of the monitor manager was to look up GPUs. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-11 14:35:42 +00:00
GError **error);
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
monitor-manager-kms: Check if GPUs can have outputs We need a way for mutter to exit if no available GPUs are going to work. For example if gdm starts gnome-shell and we're using a DRM driver that doesn't work with KMS then we should exit so that GDM can try with Xorg, rather than operating in headless mode. Related: https://gitlab.gnome.org/GNOME/mutter/issues/223
2018-08-13 10:22:22 +00:00
gboolean meta_gpu_kms_can_have_outputs (MetaGpuKms *gpu_kms);
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
gboolean meta_gpu_kms_is_crtc_active (MetaGpuKms *gpu_kms,
MetaCrtc *crtc);
backends/native: Add flags to MetaGpuKms Add a flags field to MetaGpuKms. In following commits, the flags defined here will be set and used for choosing the primary GPU. Co-authored by: Emilio Pozuelo Monfort <emilio.pozuelo@collabora.co.uk> https://gitlab.gnome.org/GNOME/mutter/merge_requests/271
2018-12-04 14:52:59 +00:00
gboolean meta_gpu_kms_is_boot_vga (MetaGpuKms *gpu_kms);
gboolean meta_gpu_kms_is_platform_device (MetaGpuKms *gpu_kms);
backends: force enable modifiers on tagged devices Some devices can't scanout to linear buffers directly as the hw is not capable of eg rendering into a linear depth buffer. Add code to force kms-modifiers on udev taged devices. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1408 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1443
2020-09-14 18:36:17 +00:00
gboolean meta_gpu_kms_requires_modifiers (MetaGpuKms *gpu_kms);
backends/native: Add flags to MetaGpuKms Add a flags field to MetaGpuKms. In following commits, the flags defined here will be set and used for choosing the primary GPU. Co-authored by: Emilio Pozuelo Monfort <emilio.pozuelo@collabora.co.uk> https://gitlab.gnome.org/GNOME/mutter/merge_requests/271
2018-12-04 14:52:59 +00:00
crtc/kms: Use MetaKmsPlane to check supported rotations and formats Instead of manually retrieving supported transforms and formats from the primary plane of the CRTC, use the MetaKmsPlane abstraction to find the primary plane of the CRTC and check compatibility using the MetaKmsPlane API. This removes the last user of direct KMS API usage except for applying configuration. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-03-09 17:23:28 +00:00
MetaKmsDevice * meta_gpu_kms_get_kms_device (MetaGpuKms *gpu_kms);
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
int meta_gpu_kms_get_fd (MetaGpuKms *gpu_kms);
gpu/kms: Add identifier We need a device unique id in order to uniquely identify an output, which will use a (device, connector) pair.
2018-10-11 14:12:53 +00:00
uint32_t meta_gpu_kms_get_id (MetaGpuKms *gpu_kms);
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
const char * meta_gpu_kms_get_file_path (MetaGpuKms *gpu_kms);
cogl: Make presentation time always MONOTONIC This concerns only the cases when the presentation timestamp is received directly from the device (from KMS or from GLX). In the majority of cases this timestamp is already MONOTONIC. When it isn't, after this commit, the current value of the MONOTONIC clock is sampled instead. The alternative is to store the clock id alongside the timestamp, with possible values of MONOTONIC, REALTIME (from KMS) and GETTIMEOFDAY (from GLX; this might be the same as REALTIME, I'm not sure), and then "convert" the timestamp to MONOTONIC when needed. An example of such a conversion was done in compositor.c (removed in this commit). It would also be needed for the presentation-time Wayland protocol. However, it seems that the vast majority of up-to-date systems are using MONOTONIC anyway, making this effort not justified. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
2021-01-30 20:14:55 +00:00
gboolean meta_gpu_kms_is_clock_monotonic (MetaGpuKms *gpu_kms);
backend/native: Add and use transactional KMS API This commit introduces, and makes use of, a transactional API used for setting up KMS state, later to be applied, potentially atomically. From an API point of view, so is always the case, but in the current implementation, it still uses legacy drmMode* API to apply the state non-atomically. The API consists of various buliding blocks: * MetaKmsUpdate - a set of configuration changes, the higher level handle for handing over configuration to the impl backend. It's used to set mode, assign framebuffers to planes, queue page flips and set connector properties. * MetaKmsPlaneAssignment - the assignment of a framebuffer to a plane. Currently used to map a framebuffer to the primary plane of a CRTC. In the legacy KMS implementation, the plane assignment is used to derive the framebuffer used for mode setting and page flipping. This also means various high level changes: State, excluding configuring the cursor plane and creating/destroying DRM framebuffer handles, are applied in the end of a clutter frame, in one go. From an API point of view, this is done atomically, but as mentioned, only the non-atomic implementation exists so far. From MetaRendererNative's point of view, a page flip now initially always succeeds; the handling of EBUSY errors are done asynchronously in the MetaKmsImpl backend (still by retrying at refresh rate, but postponing flip callbacks instead of manipulating the frame clock). Handling of falling back to mode setting instead of page flipping is notified after the fact by a more precise page flip feedback API. EGLStream based page flipping relies on the impl backend not being atomic, as the page flipping is done in the EGLStream backend (e.g. nvidia driver). It uses a 'custom' page flip queueing method, keeping the EGLStream logic inside meta-renderer-native.c. Page flip handling is moved to meta-kms-impl-device.c from meta-gpu-kms.c. It goes via an extra idle callback before reaching meta-renderer-native.c to make sure callbacks are invoked outside of the impl context. While dummy power save page flipping is kept in meta-renderer-native.c, the EBUSY handling is moved to meta-kms-impl-simple.c. Instead of freezing the frame clock, actual page flip callbacks are postponed until all EBUSY retries have either succeeded or failed due to some other error than EBUSY. This effectively inhibits new frames to be drawn, meaning we won't stall waiting on the file descriptor for pending page flips. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-04-04 20:36:41 +00:00
void meta_gpu_kms_set_power_save_mode (MetaGpuKms *gpu_kms,
uint64_t state,
MetaKmsUpdate *kms_update);
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
crtc-mode-kms: Wrap MetaKmsMode instead of drmModeModeInfo We'll need to use the MetaKmsMode later on for state keeping. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-02 13:47:32 +00:00
MetaCrtcMode * meta_gpu_kms_get_mode_from_kms_mode (MetaGpuKms *gpu_kms,
MetaKmsMode *kms_mode);
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
gboolean meta_drm_mode_equal (const drmModeModeInfo *one,
const drmModeModeInfo *two);
renderer/native: Also wrap flip closures for EGLStreams When using the EGLStream backend, the MetaRendererNative passed a GClosure to KMS when using EGLStreams, but KMS flip callback event handler in meta-gpu-kms.c expected a closure wrapped in a closure container, meaning it'd instead crash when using EGLStreams. Make the flip handler get what it expects also when using EGLStreams by wrapping the flip closure in the container before handing it over to EGL. https://bugzilla.gnome.org/show_bug.cgi?id=790316
2017-11-14 08:08:52 +00:00
MetaGpuKmsFlipClosureContainer * meta_gpu_kms_wrap_flip_closure (MetaGpuKms *gpu_kms,
renderer-native: Add hardware presentation timing Add support for getting hardware presentation times from KMS (Wayland sessions). Also implement cogl_get_clock_time which is required to compare and judge the age of presentation timestamps. For single monitor systems this is straightforward. For multi-monitor systems though we have to choose a display to sync to. The compositor already partially solves this for us in the case of only one display updating because it will only use the subset of monitors that are changing. In the case of multiple monitors consuming the same frame concurrently however, we choose the fastest one (in use at the time). Note however that we also need !73 to land in order to fully realize multiple monitors running at full speed.
2018-06-27 09:19:27 +00:00
MetaCrtc *crtc,
renderer/native: Also wrap flip closures for EGLStreams When using the EGLStream backend, the MetaRendererNative passed a GClosure to KMS when using EGLStreams, but KMS flip callback event handler in meta-gpu-kms.c expected a closure wrapped in a closure container, meaning it'd instead crash when using EGLStreams. Make the flip handler get what it expects also when using EGLStreams by wrapping the flip closure in the container before handing it over to EGL. https://bugzilla.gnome.org/show_bug.cgi?id=790316
2017-11-14 08:08:52 +00:00
GClosure *flip_closure);
void meta_gpu_kms_flip_closure_container_free (MetaGpuKmsFlipClosureContainer *closure_container);
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
#endif /* META_GPU_KMS_H */
Copy permalink