Source-Changes-HG archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
[xsrc/trunk]: xsrc/external/mit/libdrm/dist merge libdrm 2.4.105.
details: https://anonhg.NetBSD.org/xsrc/rev/1b64c14168a5
branches: trunk
changeset: 10698:1b64c14168a5
user: mrg <mrg%NetBSD.org@localhost>
date: Tue Apr 27 03:02:37 2021 +0000
description:
merge libdrm 2.4.105.
diffstat:
external/mit/libdrm/dist/intel/intel_bufmgr_gem.c | 96 ++++-
external/mit/libdrm/dist/man/drm-kms.xml | 342 ---------------
external/mit/libdrm/dist/man/drm-memory.xml | 430 -------------------
external/mit/libdrm/dist/man/drm.xml | 137 ------
external/mit/libdrm/dist/man/drmAvailable.xml | 75 ---
external/mit/libdrm/dist/man/drmHandleEvent.xml | 102 ----
external/mit/libdrm/dist/man/drmModeGetResources.xml | 139 ------
external/mit/libdrm/dist/tests/modetest/modetest.c | 2 +-
external/mit/libdrm/dist/xf86drm.c | 41 +-
external/mit/libdrm/dist/xf86drm.h | 18 +
external/mit/libdrm/dist/xf86drmMode.c | 19 +-
external/mit/libdrm/dist/xf86drmMode.h | 147 +-----
12 files changed, 184 insertions(+), 1364 deletions(-)
diffs (truncated from 1783 to 300 lines):
diff -r 4e73141a4d5c -r 1b64c14168a5 external/mit/libdrm/dist/intel/intel_bufmgr_gem.c
--- a/external/mit/libdrm/dist/intel/intel_bufmgr_gem.c Tue Apr 27 03:01:48 2021 +0000
+++ b/external/mit/libdrm/dist/intel/intel_bufmgr_gem.c Tue Apr 27 03:02:37 2021 +0000
@@ -1732,6 +1732,82 @@
return drm_intel_gem_bo_unmap(bo);
}
+static bool is_cache_coherent(drm_intel_bo *bo)
+{
+ drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr;
+ drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
+ struct drm_i915_gem_caching arg = {};
+
+ arg.handle = bo_gem->gem_handle;
+ if (drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_GET_CACHING, &arg))
+ assert(false);
+ return arg.caching != I915_CACHING_NONE;
+}
+
+static void set_domain(drm_intel_bo *bo, uint32_t read, uint32_t write)
+{
+ drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr;
+ drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
+ struct drm_i915_gem_set_domain arg = {};
+
+ arg.handle = bo_gem->gem_handle;
+ arg.read_domains = read;
+ arg.write_domain = write;
+ if (drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_SET_DOMAIN, &arg))
+ assert(false);
+}
+
+static int mmap_write(drm_intel_bo *bo, unsigned long offset,
+ unsigned long length, const void *buf)
+{
+ void *map = NULL;
+
+ if (!length)
+ return 0;
+
+ if (is_cache_coherent(bo)) {
+ map = drm_intel_gem_bo_map__cpu(bo);
+ if (map)
+ set_domain(bo, I915_GEM_DOMAIN_CPU, I915_GEM_DOMAIN_CPU);
+ }
+ if (!map) {
+ map = drm_intel_gem_bo_map__wc(bo);
+ if (map)
+ set_domain(bo, I915_GEM_DOMAIN_WC, I915_GEM_DOMAIN_WC);
+ }
+
+ assert(map);
+ memcpy((char *)map + offset, buf, length);
+ drm_intel_gem_bo_unmap(bo);
+ return 0;
+}
+
+static int mmap_read(drm_intel_bo *bo, unsigned long offset,
+ unsigned long length, void *buf)
+{
+ drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr;
+ void *map = NULL;
+
+ if (!length)
+ return 0;
+
+ if (bufmgr_gem->has_llc || is_cache_coherent(bo)) {
+ map = drm_intel_gem_bo_map__cpu(bo);
+ if (map)
+ set_domain(bo, I915_GEM_DOMAIN_CPU, 0);
+ }
+ if (!map) {
+ map = drm_intel_gem_bo_map__wc(bo);
+ if (map)
+ set_domain(bo, I915_GEM_DOMAIN_WC, 0);
+ }
+
+ assert(map);
+ memcpy(buf, (char *)map + offset, length);
+ drm_intel_gem_bo_unmap(bo);
+ return 0;
+}
+
static int
drm_intel_gem_bo_subdata(drm_intel_bo *bo, unsigned long offset,
unsigned long size, const void *data)
@@ -1752,14 +1828,20 @@
ret = drmIoctl(bufmgr_gem->fd,
DRM_IOCTL_I915_GEM_PWRITE,
&pwrite);
- if (ret != 0) {
+ if (ret)
ret = -errno;
+
+ if (ret != 0 && ret != -EOPNOTSUPP) {
DBG("%s:%d: Error writing data to buffer %d: (%d %d) %s .\n",
__FILE__, __LINE__, bo_gem->gem_handle, (int)offset,
(int)size, strerror(errno));
+ return ret;
}
- return ret;
+ if (ret == -EOPNOTSUPP)
+ mmap_write(bo, offset, size, data);
+
+ return 0;
}
static int
@@ -1807,14 +1889,20 @@
ret = drmIoctl(bufmgr_gem->fd,
DRM_IOCTL_I915_GEM_PREAD,
&pread);
- if (ret != 0) {
+ if (ret)
ret = -errno;
+
+ if (ret != 0 && ret != -EOPNOTSUPP) {
DBG("%s:%d: Error reading data from buffer %d: (%d %d) %s .\n",
__FILE__, __LINE__, bo_gem->gem_handle, (int)offset,
(int)size, strerror(errno));
+ return ret;
}
- return ret;
+ if (ret == -EOPNOTSUPP)
+ mmap_read(bo, offset, size, data);
+
+ return 0;
}
/** Waits for all GPU rendering with the object to have completed. */
diff -r 4e73141a4d5c -r 1b64c14168a5 external/mit/libdrm/dist/man/drm-kms.xml
--- a/external/mit/libdrm/dist/man/drm-kms.xml Tue Apr 27 03:01:48 2021 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,342 +0,0 @@
-<?xml version='1.0'?> <!--*-nxml-*-->
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
- "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";>
-
-<!--
- Written 2012 by David Herrmann <dh.herrmann%googlemail.com@localhost>
- Dedicated to the Public Domain
--->
-
-<refentry id="drm-kms">
- <refentryinfo>
- <title>Direct Rendering Manager</title>
- <productname>libdrm</productname>
- <date>September 2012</date>
- <authorgroup>
- <author>
- <contrib>Developer</contrib>
- <firstname>David</firstname>
- <surname>Herrmann</surname>
- <email>dh.herrmann%googlemail.com@localhost</email>
- </author>
- </authorgroup>
- </refentryinfo>
-
- <refmeta>
- <refentrytitle>drm-kms</refentrytitle>
- <manvolnum>7</manvolnum>
- </refmeta>
-
- <refnamediv>
- <refname>drm-kms</refname>
- <refpurpose>Kernel Mode-Setting</refpurpose>
- </refnamediv>
-
- <refsynopsisdiv>
- <funcsynopsis>
- <funcsynopsisinfo>#include <xf86drm.h></funcsynopsisinfo>
- <funcsynopsisinfo>#include <xf86drmMode.h></funcsynopsisinfo>
- </funcsynopsis>
- </refsynopsisdiv>
-
- <refsect1>
- <title>Description</title>
- <para>Each DRM device provides access to manage which monitors and displays
- are currently used and what frames to be displayed. This task is
- called <emphasis>Kernel Mode-Setting</emphasis> (KMS). Historically,
- this was done in user-space and called
- <emphasis>User-space Mode-Setting</emphasis> (UMS). Almost all
- open-source drivers now provide the KMS kernel API to do this in the
- kernel, however, many non-open-source binary drivers from different
- vendors still do not support this. You can use
- <citerefentry><refentrytitle>drmModeSettingSupported</refentrytitle><manvolnum>3</manvolnum></citerefentry>
- to check whether your driver supports this. To understand how KMS
- works, we need to introduce 5 objects: <emphasis>CRTCs</emphasis>,
- <emphasis>Planes</emphasis>, <emphasis>Encoders</emphasis>,
- <emphasis>Connectors</emphasis> and
- <emphasis>Framebuffers</emphasis>.
-
- <variablelist>
- <varlistentry>
- <term>CRTCs</term>
- <listitem>
- <para>A <emphasis>CRTC</emphasis> short for
- <emphasis>CRT Controller</emphasis> is an abstraction
- representing a part of the chip that contains a pointer to a
- scanout buffer. Therefore, the number of CRTCs available
- determines how many independent scanout buffers can be active
- at any given time. The CRTC structure contains several fields
- to support this: a pointer to some video memory (abstracted as
- a frame-buffer object), a list of driven connectors, a display
- mode and an (x, y) offset into the video memory to support
- panning or configurations where one piece of video memory
- spans multiple CRTCs. A CRTC is the central point where
- configuration of displays happens. You select which objects to
- use, which modes and which parameters and then configure each
- CRTC via
- <citerefentry><refentrytitle>drmModeCrtcSet</refentrytitle><manvolnum>3</manvolnum></citerefentry>
- to drive the display devices.</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>Planes</term>
- <listitem>
- <para>A <emphasis>plane</emphasis> respresents an image source that
- can be blended with or overlayed on top of a CRTC during the
- scanout process. Planes are associated with a frame-buffer to
- crop a portion of the image memory (source) and optionally
- scale it to a destination size. The result is then blended
- with or overlayed on top of a CRTC. Planes are not provided by
- all hardware and the number of available planes is limited. If
- planes are not available or if not enough planes are
- available, the user should fall back to normal software
- blending (via GPU or CPU).</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>Encoders</term>
- <listitem>
- <para>An <emphasis>encoder</emphasis> takes pixel data from a CRTC
- and converts it to a format suitable for any attached
- connectors. On some devices, it may be possible to have a CRTC
- send data to more than one encoder. In that case, both
- encoders would receive data from the same scanout buffer,
- resulting in a <emphasis>cloned</emphasis> display
- configuration across the connectors attached to each
- encoder.</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>Connectors</term>
- <listitem>
- <para>A <emphasis>connector</emphasis> is the final destination of
- pixel-data on a device, and usually connects directly to an
- external display device like a monitor or laptop panel. A
- connector can only be attached to one encoder at a time. The
- connector is also the structure where information about the
- attached display is kept, so it contains fields for display
- data, <emphasis>EDID</emphasis> data,
- <emphasis>DPMS</emphasis> and
- <emphasis>connection status</emphasis>, and information about
- modes supported on the attached displays.</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>Framebuffers</term>
- <listitem>
- <para><emphasis>Framebuffers</emphasis> are abstract memory objects
- that provide a source of pixel data to scanout to a CRTC.
- Applications explicitly request the creation of framebuffers
- and can control their behavior. Framebuffers rely on the
- underneath memory manager for low-level memory operations.
- When creating a framebuffer, applications pass a memory handle
- through the API which is used as backing storage. The
- framebuffer itself is only an abstract object with no data. It
- just refers to memory buffers that must be created with the
- <citerefentry><refentrytitle>drm-memory</refentrytitle><manvolnum>7</manvolnum></citerefentry>
- API.</para>
- </listitem>
- </varlistentry>
- </variablelist>
- </para>
-
- <refsect2>
- <title>Mode-Setting</title>
- <para>Before mode-setting can be performed, an application needs to call
- <citerefentry><refentrytitle>drmSetMaster</refentrytitle><manvolnum>3</manvolnum></citerefentry>
- to become <emphasis>DRM-Master</emphasis>. It then has exclusive
- access to the KMS API. A call to
- <citerefentry><refentrytitle>drmModeGetResources</refentrytitle><manvolnum>3</manvolnum></citerefentry>
- returns a list of <emphasis>CRTCs</emphasis>,
- <emphasis>Connectors</emphasis>, <emphasis>Encoders</emphasis> and
- <emphasis>Planes</emphasis>.</para>
-
- <para>Normal procedure now includes: First, you select which connectors
- you want to use. Users are mostly interested in which monitor or
- display-panel is active so you need to make sure to arrange them in
- the correct logical order and select the correct ones to use. For
- each connector, you need to find a CRTC to drive this connector. If
- you want to clone output to two or more connectors, you may use a
- single CRTC for all cloned connectors (if the hardware supports
- this). To find a suitable CRTC, you need to iterate over the list of
- encoders that are available for each connector. Each encoder
- contains a list of CRTCs that it can work with and you simply select
- one of these CRTCs. If you later program the CRTC to control a
Home |
Main Index |
Thread Index |
Old Index