All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: DRI Development <dri-devel@lists.freedesktop.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: [PATCH 01/19] drm/doc: Clarify the dumb object interfaces
Date: Thu, 23 Jan 2014 09:52:26 +0100	[thread overview]
Message-ID: <1390467164-951-2-git-send-email-daniel.vetter@ffwll.ch> (raw)
In-Reply-To: <1390467164-951-1-git-send-email-daniel.vetter@ffwll.ch>

- This is _not_ a generic interface to create gem objects, but just an
  interface to make early boot services (like boot splash) with a
  generic KMS userspace driver possible. Hence it's better to move
  the documentation for this from the GEM section to the KMS section,
  next to the creation of framebuffer objects.

- Make it really clear that the returned handle isn't necessarily a
  GEM object (it can also be e.g. a TTM handle when running on top of
  vmwgfx).

- Add a paragraph to make it clear that this is just for unaccelarated
  userspace - gpu drivers need to have their own buffer object
  creation ioctl which is hardware specific.

Cc: Laurent Pinchart laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 Documentation/DocBook/drm.tmpl | 125 ++++++++++++++++++++++-------------------
 1 file changed, 68 insertions(+), 57 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index ed1d6d289022..9c3fdd59c995 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -830,62 +830,6 @@ char *date;</synopsis>
         </para>
       </sect3>
       <sect3>
-        <title>Dumb GEM Objects</title>
-        <para>
-          The GEM API doesn't standardize GEM objects creation and leaves it to
-          driver-specific ioctls. While not an issue for full-fledged graphics
-          stacks that include device-specific userspace components (in libdrm for
-          instance), this limit makes DRM-based early boot graphics unnecessarily
-          complex.
-        </para>
-        <para>
-          Dumb GEM objects partly alleviate the problem by providing a standard
-          API to create dumb buffers suitable for scanout, which can then be used
-          to create KMS frame buffers.
-        </para>
-        <para>
-          To support dumb GEM objects drivers must implement the
-          <methodname>dumb_create</methodname>,
-          <methodname>dumb_destroy</methodname> and
-          <methodname>dumb_map_offset</methodname> operations.
-        </para>
-        <itemizedlist>
-          <listitem>
-            <synopsis>int (*dumb_create)(struct drm_file *file_priv, struct drm_device *dev,
-                     struct drm_mode_create_dumb *args);</synopsis>
-            <para>
-              The <methodname>dumb_create</methodname> operation creates a GEM
-              object suitable for scanout based on the width, height and depth
-              from the struct <structname>drm_mode_create_dumb</structname>
-              argument. It fills the argument's <structfield>handle</structfield>,
-              <structfield>pitch</structfield> and <structfield>size</structfield>
-              fields with a handle for the newly created GEM object and its line
-              pitch and size in bytes.
-            </para>
-          </listitem>
-          <listitem>
-            <synopsis>int (*dumb_destroy)(struct drm_file *file_priv, struct drm_device *dev,
-                      uint32_t handle);</synopsis>
-            <para>
-              The <methodname>dumb_destroy</methodname> operation destroys a dumb
-              GEM object created by <methodname>dumb_create</methodname>.
-            </para>
-          </listitem>
-          <listitem>
-            <synopsis>int (*dumb_map_offset)(struct drm_file *file_priv, struct drm_device *dev,
-                         uint32_t handle, uint64_t *offset);</synopsis>
-            <para>
-              The <methodname>dumb_map_offset</methodname> operation associates an
-              mmap fake offset with the GEM object given by the handle and returns
-              it. Drivers must use the
-              <function>drm_gem_create_mmap_offset</function> function to
-              associate the fake offset as described in
-              <xref linkend="drm-gem-objects-mapping"/>.
-            </para>
-          </listitem>
-        </itemizedlist>
-      </sect3>
-      <sect3>
         <title>Memory Coherency</title>
         <para>
           When mapped to the device or used in a command buffer, backing pages
@@ -970,7 +914,9 @@ int max_width, max_height;</synopsis>
         handle (or a list of memory handles for multi-planar formats) through
         the <parameter>drm_mode_fb_cmd2</parameter> argument. This document
         assumes that the driver uses GEM, those handles thus reference GEM
-        objects.
+        objects. But drivers are free to use their own backing storage object
+	handles, e.g. vmwgfx directly exposes special TTM handles to userspace
+	and so expects TTM handles in the create ioctl and not GEM objects.
       </para>
       <para>
         Drivers must first validate the requested frame buffer parameters passed
@@ -1052,6 +998,71 @@ int max_width, max_height;</synopsis>
 	<function>drm_framebuffer_unregister_private</function>.
     </sect2>
     <sect2>
+      <title>Dumb GEM Objects</title>
+      <para>
+	The KMS API doesn't standardize backing storage object creation and
+	leaves it to driver-specific ioctls. Furthermore actually creating a
+	buffer object even for GEM-based drivers is done through a
+	driver-specific ioctl - GEM only has a common userspace interface for
+	sharing and destroying objects. While not an issue for full-fledged
+	graphics stacks that include device-specific userspace components (in
+	libdrm for instance), this limit makes DRM-based early boot graphics
+	unnecessarily complex.
+      </para>
+      <para>
+        Dumb objects partly alleviate the problem by providing a standard
+        API to create dumb buffers suitable for scanout, which can then be used
+        to create KMS frame buffers.
+      </para>
+      <para>
+        To support dumb objects drivers must implement the
+        <methodname>dumb_create</methodname>,
+        <methodname>dumb_destroy</methodname> and
+        <methodname>dumb_map_offset</methodname> operations.
+      </para>
+      <itemizedlist>
+        <listitem>
+          <synopsis>int (*dumb_create)(struct drm_file *file_priv, struct drm_device *dev,
+                   struct drm_mode_create_dumb *args);</synopsis>
+          <para>
+            The <methodname>dumb_create</methodname> operation creates a driver
+	    object (GEM or TTM handle) object suitable for scanout based on the
+	    width, height and depth from the struct
+	    <structname>drm_mode_create_dumb</structname> argument. It fills the
+	    argument's <structfield>handle</structfield>,
+	    <structfield>pitch</structfield> and <structfield>size</structfield>
+	    fields with a handle for the newly created object and its line
+            pitch and size in bytes.
+          </para>
+        </listitem>
+        <listitem>
+          <synopsis>int (*dumb_destroy)(struct drm_file *file_priv, struct drm_device *dev,
+                    uint32_t handle);</synopsis>
+          <para>
+            The <methodname>dumb_destroy</methodname> operation destroys a dumb
+            object created by <methodname>dumb_create</methodname>.
+          </para>
+        </listitem>
+        <listitem>
+          <synopsis>int (*dumb_map_offset)(struct drm_file *file_priv, struct drm_device *dev,
+                       uint32_t handle, uint64_t *offset);</synopsis>
+          <para>
+            The <methodname>dumb_map_offset</methodname> operation associates an
+            mmap fake offset with the object given by the handle and returns
+            it. Drivers must use the
+            <function>drm_gem_create_mmap_offset</function> function to
+            associate the fake offset as described in
+            <xref linkend="drm-gem-objects-mapping"/>.
+          </para>
+        </listitem>
+      </itemizedlist>
+      <para>
+        Note that dumb objects may not be used for gpu accelaration, as has been
+	attempted on some ARM embedded platforms. Such drivers really must have
+	a hardware-specific ioctl to allocate suitable objects.
+      </para>
+    </sect2>
+    <sect2>
       <title>Output Polling</title>
       <synopsis>void (*output_poll_changed)(struct drm_device *dev);</synopsis>
       <para>
-- 
1.8.5.2

  reply	other threads:[~2014-01-23  8:53 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-23  8:52 [PATCH 00/19] DRM developer's guide polish, part 1 Daniel Vetter
2014-01-23  8:52 ` Daniel Vetter [this message]
2014-01-23  9:14   ` [PATCH 01/19] drm/doc: Clarify the dumb object interfaces David Herrmann
2014-01-23 11:30     ` Laurent Pinchart
2014-01-23 12:48     ` [PATCH] " Daniel Vetter
2014-01-23 13:30       ` Laurent Pinchart
2014-01-23 13:50         ` Daniel Vetter
2014-01-24 11:13           ` Laurent Pinchart
2014-01-24 16:53             ` Daniel Vetter
2014-01-24 16:58             ` Daniel Vetter
2014-01-24 19:56               ` Dieter Nützel
2014-01-26 22:59               ` Laurent Pinchart
2014-01-23 11:21   ` [PATCH 01/19] " Laurent Pinchart
2014-01-23 12:47     ` Daniel Vetter
2014-01-23 12:56       ` Laurent Pinchart
2014-01-23 13:46         ` Daniel Vetter
2014-01-24 11:08           ` Laurent Pinchart
2014-01-24 16:49             ` Daniel Vetter
2014-01-23  8:52 ` [PATCH 02/19] drm/doc: Fix up kerneldoc in drm_edid.c Daniel Vetter
2014-01-23  8:52 ` [PATCH 03/19] drm/doc: Clean up and integrate kerneldoc for drm_gem.c Daniel Vetter
2014-01-23  9:21   ` David Herrmann
2014-01-23  9:39     ` Daniel Vetter
2014-01-23  8:52 ` [PATCH 04/19] drm/doc: Remove <term> from rendernode docs Daniel Vetter
2014-01-23  8:52 ` [PATCH 05/19] drm/doc: Reorganize driver documentation Daniel Vetter
2014-01-23  8:52 ` [PATCH 06/19] drm/doc: Move the vma offset manager to the right spot Daniel Vetter
2014-01-23  8:52 ` [PATCH 07/19] drm/doc: Remove the "command submissin and fencing" section Daniel Vetter
2014-01-23  8:52 ` [PATCH 08/19] drm/doc: No more drm perf counters Daniel Vetter
2014-01-23  8:52 ` [PATCH 09/19] drm/doc: Document drm_helper_resume_force_mode Daniel Vetter
2014-01-23  8:52 ` [PATCH 10/19] drm/doc: Hide legacy horrors better Daniel Vetter
2014-01-23  8:52 ` [PATCH 11/19] drm/docs: Include hdmi infoframe helper reference Daniel Vetter
2014-01-23  8:52 ` [PATCH 12/19] drm/doc: Clarify PRIME documentation Daniel Vetter
2014-01-23  8:52 ` [PATCH 13/19] drm/doc: Add PRIME function references Daniel Vetter
2014-01-23  9:28   ` David Herrmann
2014-01-23  9:37     ` Daniel Vetter
2014-01-23  9:45       ` David Herrmann
2014-01-23  9:58         ` Daniel Vetter
2014-01-23  8:52 ` [PATCH 14/19] drm/doc: Update copyright Daniel Vetter
2014-01-23  8:52 ` [PATCH 15/19] drm/mm: Remove MM_UNUSED_TARGET Daniel Vetter
2014-01-23  8:52 ` [PATCH 16/19] drm/doc: Overview documentation for drm_mm.c Daniel Vetter
2014-01-23  8:52 ` [PATCH 17/19] drm/doc: Add fucntion reference " Daniel Vetter
2014-01-23  8:52 ` [PATCH 18/19] drm/kms: rip out drm_mode_connector_detach_encoder Daniel Vetter
2014-01-23  8:52 ` [PATCH 19/19] drm/kms: don't export drm_mode_group_init_legacy_group Daniel Vetter
2014-01-23  9:42   ` David Herrmann
2014-01-23 10:00     ` Daniel Vetter
2014-01-23 10:05       ` Russell King - ARM Linux
2014-01-23 12:51         ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1390467164-951-2-git-send-email-daniel.vetter@ffwll.ch \
    --to=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=laurent.pinchart@ideasonboard.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.