[PATCH v2 2/6] modesetting: Use a gbm buffer for shadow if we are using glamor

[Keith Packard]

Jason Ekstrand <jason at jlekstrand.net> writes:

> Correction, we have two completely different concepts of "shadow fb" going
> on here.  One is the shadow from miext/shadow that seems to cover the
> entire screen pixmap.  The other shadow buffers, the ones used for
> rotation, should be per-crtc.  These two concepts of shadow buffers are, as
> far as I can tell, completely seperate.
>
> Given that I can't seem to figure out what miext/shadow does, I'm kind
> of at a loss.  My best guess is that it effectively causes X to be
> double-buffered by rendering in the primary pixmap and blitting to the
> shadow for actual scan-out.

Good deduction. Using a shadow frame buffer like this is generally a
good performance move when you're rendering with software and the scanout
buffer is a distance from the CPU.

The other thing the miext/shadow code does is reformat for 'weird'
scanout formats, so it doesn't use the normal CopyArea or Composite
paths to move data from the frame buffer to the scanout buffer.

> That said, I'm not really sure.  How should
> this interact with per-crtc rotation shadow buffers?  I have no idea.

Hrm. Ideally, we'd have one set of code to deal with getting pixels from
the frame buffer to the scanout buffer, but instead we have two sets of
code with different capabilities:

 1) RandR's rotation support. Handles arbitrary projective transforms,
    and deals with multiple CRTCs, each with a different transform and
    separate scanout buffer. Does not handle non-Zpixmap formats.

 2) miext/shadow. Handles 0/90/180/270-degree rotations and deals with
    non-Zpixmap formats. Does not handle arbitrary transforms or
    per-CRTC scanout buffers.

> Also, the xf86-video-intel driver doesn't use it at all, so my go-to
> example isn't helping.  A little help here?

Given that we don't handle non-Zpixmap formats in the modesetting
driver, I think what we want is to just use the RandR shadow support for
all shadowing. That will require changes to the core server to force
shadowing for a CRTC; I think that's 'trivial'; just changing
xf86CrtcRotate to always pick the shadow path for this CRTC. Then you
can simply delete all of the existing shadow code in the modesetting
driver and instead set the 'forceShadow' value in all of the CRTCs.

That's an ABI change, and will have to wait for 1.18, if it works at
all.

I'm not sure what to do for 1.17; suggestions are welcome...

diff --git a/hw/xfree86/modes/xf86Crtc.h b/hw/xfree86/modes/xf86Crtc.h
index 692bf40..f6ab4ba 100644
--- a/hw/xfree86/modes/xf86Crtc.h
+++ b/hw/xfree86/modes/xf86Crtc.h
@@ -366,6 +366,11 @@ struct _xf86Crtc {
     Bool shadowClear;
 
     /**
+     * Force the shadow
+     */
+    Bool forceShadow;
+
+    /**
      * Indicates that the driver is handling the transform, so the shadow
      * surface should be disabled.  The driver writes this field before calling
      * xf86CrtcRotate to indicate that it is handling the transform (including
diff --git a/hw/xfree86/modes/xf86Rotate.c b/hw/xfree86/modes/xf86Rotate.c
index 9c00a44..f6bf531 100644
--- a/hw/xfree86/modes/xf86Rotate.c
+++ b/hw/xfree86/modes/xf86Rotate.c
@@ -376,7 +376,9 @@ xf86CrtcRotate(xf86CrtcPtr crtc)
                             &crtc_to_fb,
                             &f_crtc_to_fb,
                             &f_fb_to_crtc) &&
-        xf86CrtcFitsScreen(crtc, &f_crtc_to_fb)) {
+        !crtc->forceShadow &&
+        xf86CrtcFitsScreen(crtc, &f_crtc_to_fb))
+    {
         /*
          * If the untranslated transformation is the identity,
          * disable the shadow buffer


-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20150111/a119a8b0/attachment.sig>