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

93 lines
3.5 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"
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;
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
typedef void (*MetaKmsFlipCallback) (void *user_data);
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
gboolean meta_gpu_kms_apply_crtc_mode (MetaGpuKms *gpu_kms,
MetaCrtc *crtc,
int x,
int y,
uint32_t fb_id);
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);
renderer/native: Retry page flip after one vsync if EBUSY We might fail to page flip a new buffer, often after resuming, due to the FIFO being full. Prior to this commit, we handled this by switching over to plain mode setting instead of page flipping. This is bad because we won't be synchronized to the refresh rate anymore, but just the clock. Instead, deal with this by trying again until the FIFO is no longer full. Do this on a v-sync based interval, until it works. This also changes the error handling code for drivers not supporting page flipping to rely on them returning -EINVAL. The handling is moved from pretending a page flip working to explicit mode setting in meta-renderer-native.c. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/460
2019-02-12 18:10:59 +00:00
gboolean meta_gpu_kms_flip_crtc (MetaGpuKms *gpu_kms,
MetaCrtc *crtc,
uint32_t fb_id,
GClosure *flip_closure,
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
gpu-kms: poll() on KMS fd on EAGAIN When drmHandleEvent() returns an error and errno is set to EAGAIN, instead of ending up in a busy loop, poll() the fd until there is anything to read. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-24 02:50:49 +00:00
gboolean meta_gpu_kms_wait_for_flip (MetaGpuKms *gpu_kms,
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
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);
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
int64_t meta_gpu_kms_get_current_time_ns (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
void meta_gpu_kms_set_power_save_mode (MetaGpuKms *gpu_kms,
uint64_t state);
MetaCrtcMode * meta_gpu_kms_get_mode_from_drm_mode (MetaGpuKms *gpu_kms,
const drmModeModeInfo *drm_mode);
gboolean meta_drm_mode_equal (const drmModeModeInfo *one,
const drmModeModeInfo *two);
float meta_calculate_drm_mode_refresh_rate (const drmModeModeInfo *mode);
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