sungmg/mutter-performance-source
1
0
Fork 0
Code Activity
mutter-performance-source/src/backends/native/meta-drm-buffer-import.h

56 lines
2.1 KiB
C
Raw Normal View History

renderer/native: Import primary buffer to 2nd GPU Where possible, try to export the buffer rendered by the primary GPU as a dmabuf and import it to the secondary GPU and turn it into a DRM FB for scanout. If this works, we get a zero-copy path to secondary GPU outputs. This is especially useful on virtual drivers like EVDI (used for DisplayLink devices) which are not picky at all about what kind of FBs they can handle. The zero-copy path is prioritised after the secondary GPU copy path, which should avoid regressions for existing working systems. Attempting zero-copy would have the risk of being less performant than doing the copy on the secondary GPU. This does not affect the DisplayLink use case, because there is no GPU in a DisplayLink device. The zero-copy path is prioritised before the primary GPU and CPU copy paths. It will be tried on the first frame of an output and the copy path is executed too. If zero-copy fails, the result from the copy path will take over on that frame. Furthermore, zero-copy will not be attemped again on that output. If zero-copy succeeds, the copy path is de-initialized. Zero-copy is assumed to be always preferable over the primary GPU and CPU copy paths. Whether this is universally true remains to be seen. This patch has one unhandled failure mode: if zero-copy path first succeeds and then fails later, there is no fallback and the output is left frozen or black. https://gitlab.gnome.org/GNOME/mutter/merge_requests/810
2019-05-24 14:07:14 +00:00
/*
* Copyright (C) 2018 Canonical Ltd.
* Copyright (C) 2019 Red Hat Inc.
* Copyright (C) 2019 DisplayLink (UK) Ltd.
*
* 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_DRM_BUFFER_IMPORT_H
#define META_DRM_BUFFER_IMPORT_H
#include <gbm.h>
#include "backends/native/meta-drm-buffer.h"
#include "backends/native/meta-drm-buffer-gbm.h"
#include "backends/native/meta-gpu-kms.h"
#define META_TYPE_DRM_BUFFER_IMPORT (meta_drm_buffer_import_get_type ())
G_DECLARE_FINAL_TYPE (MetaDrmBufferImport,
meta_drm_buffer_import,
META, DRM_BUFFER_IMPORT,
MetaDrmBuffer)
/*
* MetaDrmBufferImport is a buffer that refers to the storage of a
* MetaDrmBufferGbm buffer on another MetaGpuKms.
*
* When creating an imported buffer, the given GBM buffer is exported
* as a dma_buf and then imported to the given MetaGpuKms. A reference
* is kept to the GBM buffer so that it won't disappear while the
* imported buffer exists.
*
* The import has a high chance of failing under normal operating
* conditions and needs to be handled with fallbacks to something else.
*/
native: Consolidate DRM buffer management to MetaDrmBuffer types This commit consolidates DRM buffer management to the MetaDrmBuffer types, where the base type handles the common functionality (such as managing the framebuffer id using drmModeAdd*/RMFb()), and the sub types their corresponding type specific behavior. This means that drmModeAdd*/RmFB() handling is moved from meta-gpu-kms.c to meta-drm-buffer.c; dumb buffer allocation/management from meta-renderer-native.c. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-09-29 07:40:53 +00:00
MetaDrmBufferImport * meta_drm_buffer_import_new (MetaKmsDevice *device,
struct gbm_device *gbm_device,
MetaDrmBufferGbm *buffer_gbm,
GError **error);
renderer/native: Import primary buffer to 2nd GPU Where possible, try to export the buffer rendered by the primary GPU as a dmabuf and import it to the secondary GPU and turn it into a DRM FB for scanout. If this works, we get a zero-copy path to secondary GPU outputs. This is especially useful on virtual drivers like EVDI (used for DisplayLink devices) which are not picky at all about what kind of FBs they can handle. The zero-copy path is prioritised after the secondary GPU copy path, which should avoid regressions for existing working systems. Attempting zero-copy would have the risk of being less performant than doing the copy on the secondary GPU. This does not affect the DisplayLink use case, because there is no GPU in a DisplayLink device. The zero-copy path is prioritised before the primary GPU and CPU copy paths. It will be tried on the first frame of an output and the copy path is executed too. If zero-copy fails, the result from the copy path will take over on that frame. Furthermore, zero-copy will not be attemped again on that output. If zero-copy succeeds, the copy path is de-initialized. Zero-copy is assumed to be always preferable over the primary GPU and CPU copy paths. Whether this is universally true remains to be seen. This patch has one unhandled failure mode: if zero-copy path first succeeds and then fails later, there is no fallback and the output is left frozen or black. https://gitlab.gnome.org/GNOME/mutter/merge_requests/810
2019-05-24 14:07:14 +00:00
#endif /* META_DRM_BUFFER_IMPORT_H */
Copy permalink