Re: [PATCH 5/6] glx: Flatten -DXFree86Server
On Tue, 15 Mar 2011 06:05:39 +1000, Dave Airlie airl...@gmail.com wrote: On Tue, Mar 15, 2011 at 5:31 AM, Adam Jackson a...@redhat.com wrote: Always defined by the makefile, so, just get rid of it. Signed-off-by: Adam Jackson a...@redhat.com --- glx/Makefile.am | 1 - glx/glapi.c | 43 --- 2 files changed, 0 insertions(+), 44 deletions(-) [...] diff --git a/glx/glapi.c b/glx/glapi.c index dcebc56..4bb07e2 100644 --- a/glx/glapi.c +++ b/glx/glapi.c @@ -231,9 +231,6 @@ _glapi_get_dispatch(void) # endif #endif -#if !defined(DISPATCH_FUNCTION_SIZE) !defined(XFree86Server) !defined(XGLServer) -# define NEED_FUNCTION_POINTER -#endif /* The code in this file is auto-generated with Python */ ^^^ Do we reaally want to clean this up or the generator scripts? This particular file sure looks like it shouldn't be auto-generated. It's just a big pile of ifdefs and not much really to it. pgpdOEnS8iEkr.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [ATCH 0/5] GLX context tag reimplementation
On Mon, 21 Mar 2011 16:02:12 -0400, Adam Jackson a...@redhat.com wrote: GLX, apparently as some sort of elaborate prank, has both context IDs and context tags. These are _almost_ identical; the functional difference is that you're allowed to continue to mention the tag of a deleted context as long as it's still your current context. The sample implementation of tags has a difficult time with context lifetime, because we have to keep track of things in two places and be sure we're not freeing things before we mean to be and blah blah unmanaged runtimes sure do suck. But fortunately there's a simpler implementation that I believe to be within the letter of the law, which is what the first patch in this series is. The rest is merely cleanup. This series is: Reviewed-by:Eric Anholt e...@anholt.net pgptwmvSAlXLp.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] glx: Fix fbconfigs with no corresponding visual
On Mon, 11 Apr 2011 11:29:48 -0400, Adam Jackson a...@redhat.com wrote:
There are, in general, more fbconfig depths than visual depths.
fbconfigs need not support Window rendering, however any that do must
have an associated visual ID (which we got right), and any that do not
must not claim GLX_WINDOW_BIT in GLX_DRAWABLE_TYPE (which we got wrong).
Fixes piglit/glx-fbconfig-sanity, assuming you have a sufficiently
recent piglit, as that test formerly wrongly required pixmap-capable
fbconfigs to have a visual.
Signed-off-by: Adam Jackson a...@redhat.com
---
glx/glxscreens.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/glx/glxscreens.c b/glx/glxscreens.c
index 496cf9e..1969aa3 100644
--- a/glx/glxscreens.c
+++ b/glx/glxscreens.c
@@ -395,8 +395,13 @@ void __glXScreenInit(__GLXscreen *pGlxScreen, ScreenPtr
pScreen)
if (depth == pScreen-visuals[i].nplanes)
break;
}
- if (i == pScreen-numVisuals)
+ /* If it can't, fix up the fbconfig to not advertise window support
+ * XXX should really do this when creating the fbconfig
+ */
+ if (i == pScreen-numVisuals) {
+ config-drawableType = ~(GLX_WINDOW_BIT);
continue;
+ }
/* Create a new X visual for our FBconfig. */
visual = AddScreenVisuals(pScreen, 1, depth);
I think that this place (matching fbconfigs with visuals if possible) is
the also right place to also mask off drawabletype for this requirement.
I'd drop XXX comment.
pgp25NbXkjwNz.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Pack swap complete bits into an XEvent
On Thu, 28 Apr 2011 13:27:19 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
The defintion of the swap complete event was wrong; XEvents are only 32
bytes long, and with padding the swap event was longer. So use some
creative packing to get all the bits we want transmitted. Requires a
proto version bump.
---
configure.ac |2 +-
glxproto.h | 13 +
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index d88e6df..a3047e4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
AC_PREREQ([2.60])
-AC_INIT([GLProto], [1.4.12],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([GLProto], [1.4.13],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
diff --git a/glxproto.h b/glxproto.h
index 0ff44e3..4a583c1 100644
--- a/glxproto.h
+++ b/glxproto.h
@@ -1370,18 +1370,23 @@ typedef struct {
CARD32 unused2 B32;
} xGLXPbufferClobberEvent;
+/* Note, this struct is too large for an Xevent, I fail -- jbarnes
+ * So sbc_lo won't ever be sent. We can use a generic event though without
+ * size restrictions, thus xGLXBufferSwapComplete2.
+ */
This comment doesn't seem to match the change.
typedef struct {
BYTE type;
-BYTE pad;
+BYTE sbc_lo0;
CARD16 sequenceNumber B16;
-CARD16 event_type B16;
-CARD32 drawable;
+CARD8 event_type;
+CARD8 sbc_lo8;
+CARD16 sbc_lo16 B16;
+CARD32 drawable B32;
CARD32 ust_hi B32;
CARD32 ust_lo B32;
CARD32 msc_hi B32;
CARD32 msc_lo B32;
CARD32 sbc_hi B32;
-CARD32 sbc_lo B32;
} xGLXBufferSwapComplete;
pgpvVEqhx05gf.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] DRI2/GLX: fix swap event handling
On Thu, 28 Apr 2011 13:27:22 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: Use the new swap event structure packing and send it to the client if possible. This means tracking client version information when clients connect. If they don't support the new packing, they'll get the old bits and fill junk into their sbc values when they receive the event. If they do support the new packing, send off the right data. --- a/glx/glxdri2.c +++ b/glx/glxdri2.c @@ -192,8 +192,17 @@ __glXdriSwapEvent(ClientPtr client, void *data, int type, CARD64 ust, wire.ust_lo = ust 0x; wire.msc_hi = msc 32; wire.msc_lo = msc 0x; -wire.sbc_hi = sbc 32; -wire.sbc_lo = sbc 0x; +wire.sbc_hi = 0; was that supposed to be wire.sbc_lo and not whacking wire.sbc_hi? At first I was confused by this whole thing -- why not rearrange the structure a bit if we're messing things up? Then I realized that this let the server emit the mostly-the-same event structure and only steal the other half of event_type for clients that understand the new 8-bit event_type protocol. Seems like a reasonable approach. pgpdUcjZocA7c.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Mesa-dev] glproto changes
On Wed, 4 May 2011 18:21:20 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: On Thu, 5 May 2011 11:17:02 +1000 Dave Airlie airl...@gmail.com wrote: So I wasn't watching and glproto broke its interface, and I think its bad. Why? You can no longer bisect things across this point without now moving glproto. glxproto.h:xGLXBufferSwapComplete was a released header file definition, you cannot go back and change history. This should have been handled with xGLXBufferSwapComplete2 struct that newer mesa and X server could would use instead of the older code. Old code would build against the old broken defintion but since its broken it wouldn't matter, and new code would build against the new fixed definition. This doesn't address the I need the latest glproto to build mesa and my distro doesn't have which concerns me less than the I can't bisect anymore and I fully agree with Jesse that the last time we tried using #ifdef for this sort of thing it led to a number of untested combos resulting in impossible to debug issues. Yes, in hindsight I was too shellshocked by our previous experience with dri2 invalidate, ifdefs, and untested paths to even consider allowing new code to build with old proto. But breaking bisect is bad, no doubt. But in this case adding a separate struct is probably the right thing to do, and I'd be happy to do it if people are willing to put up with the churn (glproto 1.4.14, dri2proto 2.5 plus changes to Mesa and X to use the new struct). Yes, please do a new struct. I'm happy to see the churn to make it happen if it means developers are likely to do better at testing stable branches. pgpJQDb5VCzXL.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: More DRI2 invalidate stuff
On Fri, 6 May 2011 18:18:14 +0300, ville.syrj...@nokia.com wrote: The proposed DRI@ invalidate patch [1] causes a lot more invalidate events to be sent out. That will cause processes to wake up needlessly. Eg. if an unredirected fullscreen app is flipping, each flip will also send an invalidate event to the compositor, since the composite overlay and client window share the same pixmap. Now, assuming that the compositor hasn't done a GetBuffers yet, there's no need to send an invalidate event to it. I took the easy approach and stuck the boolean flag into the DRI2DrawableRec. The optimal solution would have been to put it into DRI2DrawableRefRec and keep track of the invalidate state per reference, but that would require the client's drawable ID and client ID so that the correct ref could be found in GetBuffers. Too much hassle for my taste, and I think this simple approach should provide equal benefit in most cases. Have you measured this to reduce invalidates? I don't see how something that is producing flip requests that produce invalidates will do so without having called getbuffers in between. pgpd9GhWrYcQx.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH rendercheck] Report the success_mask to stdout
On Sat, 7 May 2011 18:20:17 -0700, Jeremy Huddleston jerem...@apple.com wrote:
This was previously computed but never passed on to the caller.
Found-by: clang static analyzer
Signed-off-by: Jeremy Huddleston jerem...@apple.com
Doing something useful with those success flags would be nice, but I
don't think a hex dump of it is that.
---
tests.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tests.c b/tests.c
index f722bc6..1b47eee 100644
--- a/tests.c
+++ b/tests.c
@@ -752,7 +752,7 @@ do {
\
free(test_mask);
free(test_dst);
- printf(%d tests passed of %d total\n, tests_passed, tests_total);
+ printf(%d tests passed of %d total (successful groups: 0x%x)\n,
tests_passed, tests_total, success_mask);
return tests_passed == tests_total;
}
--
pgpkqFUSib95s.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH rendercheck] Report which test groups passed successfully
On Mon, 9 May 2011 18:31:34 -0700, Jeremy Huddleston jerem...@apple.com wrote:
This was previously computed but never passed on to the caller.
Found-by: clang static analyzer
Signed-off-by: Jeremy Huddleston jerem...@apple.com
Bonus cleanup of the rest of the code. Nice.
Looks like I don't get to complain about 4-space indents, because I've
got them all over the code. Sigh.
---
configure.ac |2 +-
main.c| 83
+++--
rendercheck.h |5 +++-
tests.c |2 +
4 files changed, 58 insertions(+), 34 deletions(-)
diff --git a/configure.ac b/configure.ac
index 4fa5a63..09b07bd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -22,7 +22,7 @@ XORG_DEFAULT_OPTIONS
AC_CHECK_HEADERS([err.h])
# Checks for pkg-config packages
-PKG_CHECK_MODULES(RC, [xrender x11])
+PKG_CHECK_MODULES(RC, [xrender x11 xproto = 7.0.17])
What's this about? Seems like a separate commit kind of thing.
+void print_tests(FILE *file, int tests) {
+int i, j;
+
+for(i=0, j=0; available_tests[i].name; i++) {
+if(!(available_tests[i].flag tests))
+continue;
+if(j % 5 == 0) {
+if(j != 0)
+putc('\n', stderr);
+putc('\t', stderr);
+} else {
+fprintf(stderr, , );
+}
+fprintf(stderr, %s, available_tests[i].name);
+j++;
+}
+if(j)
+fprintf(file, \n);
+}
Spaces between if( and for(
pgpm0RUtLruln.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] dri2proto: add new DRI2BufferSwapComplete struct to match spec
On Thu, 5 May 2011 12:42:43 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: Just add a new struct to remain compatible with existing code. Reviewed-by: Eric Anholt e...@anholt.net pgpPWYDLhJdKT.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] glproto: add a new GLXBufferSwapComplete struct that matches the spec
On Thu, 5 May 2011 12:39:57 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Just add a new struct to remain compatible with existing code.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
diff --git a/configure.ac b/configure.ac
index a3047e4..a6c301c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
AC_PREREQ([2.60])
-AC_INIT([GLProto], [1.4.13],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([GLProto], [1.4.14],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
diff --git a/glxproto.h b/glxproto.h
index dfa0647..3f9e837 100644
--- a/glxproto.h
+++ b/glxproto.h
@@ -1375,6 +1375,20 @@ typedef struct {
BYTE pad;
CARD16 sequenceNumber B16;
CARD16 event_type B16;
While this is the compat structure, I'd still like to see the padding
explicit so I don't worry about it when reading the code ever again.
+CARD32 drawable;
+CARD32 ust_hi B32;
+CARD32 ust_lo B32;
+CARD32 msc_hi B32;
+CARD32 msc_lo B32;
+CARD32 sbc_hi B32;
+CARD32 sbc_lo B32;
+} xGLXBufferSwapComplete;
pgpGoE7Hp2AZA.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] glproto: add a new GLXBufferSwapComplete struct that matches the spec
On Tue, 10 May 2011 12:32:24 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Tue, 10 May 2011 11:59:56 -0700
Eric Anholt e...@anholt.net wrote:
On Thu, 5 May 2011 12:39:57 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Just add a new struct to remain compatible with existing code.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
diff --git a/configure.ac b/configure.ac
index a3047e4..a6c301c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
AC_PREREQ([2.60])
-AC_INIT([GLProto], [1.4.13],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([GLProto], [1.4.14],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
diff --git a/glxproto.h b/glxproto.h
index dfa0647..3f9e837 100644
--- a/glxproto.h
+++ b/glxproto.h
@@ -1375,6 +1375,20 @@ typedef struct {
BYTE pad;
CARD16 sequenceNumber B16;
CARD16 event_type B16;
While this is the compat structure, I'd still like to see the padding
explicit so I don't worry about it when reading the code ever again.
Ok, wanna push your existing patch for that or should I push it with
this stuff?
Meh, just push it with your stuff.
pgpMtDZ9wbewi.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] dri2: Pass AsyncSwap [vblank_mode=0] requests to the drivers
On Wed, 8 Jun 2011 12:03:04 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: On Wed, 8 Jun 2011 19:06:11 +0100 Chris Wilson ch...@chris-wilson.co.uk wrote: Currently, the midlayer dri2 code intercepts vblank_mode=0 SwapBuffers and converts it to a CopyRegion request. This prevents the backend from doing anything meaningful in this case and typically ends up being vsync'ed since the drivers cannot distinguish it from a regular CopyRegion request. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Jesse Barnes jbar...@virtuousgeek.org Cc: Kristian Høgsberg k...@bitplanet.net --- Sigh... I broke the patch with a last minute name change. Please pretend you never saw the previous patch. In hindsight, it would have been better if DRI2 never had a CopyRegion hook and just let the driver decide what to do given all the params (i.e. a very generic Swap hook). But we don't have that and this looks like a nice addition. It would be good to add a blurb to the header file about the hook though, since it could be easily confused with a hook that's supposed to schedule something and return immediately or something, rather than a swap now, tearing be damned hook. \o/ making vblank handling more predictable. So, I'm wondering if we want to just drop the no-tearing support in CopyRegion (aka MESA_copy_sub_buffer) that we snuck in back when we didn't really have other no-tearing support. It sounds like the clutter compositors are using another swap control to sync to vblank before dispatching their subbuffer blits. Do we know about compiz? (The latency between vblank signal from OML_sync_control to client wakeup to server wakeup to render engine wakeup might make us miss the vblank. If we do, it means dropping from 60fps to 30fps, though, which is perhaps even nastier than a tear?) pgpABylNu23wI.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 2/2] Set DamageSetReportAfterOp to true for the damage extension
From: Kristian Høgsberg k...@bitplanet.net Change the damage extension reporter to queue up events after we chain to the wrapped functions. Damage events are typically sent out after the rendering happens anyway, since we submit batch buffers from the flush callback chain and then flush client io buffers. Compositing managers relie on this order, and there is no way we could reliably provide damage events to clients before the rendering happens anyway. By queueing up the damage events before the rendering happens, there's a risk that the client io buffer may overflow and send the damage events to the client before the driver has even seen the rendering request. Reporting damage events after the rendering fixes this corner case and better corresponds with how we expect this to work. Signed-off-by: Kristian Høgsberg k...@bitplanet.net Reviewed-by: Keith Packard kei...@keithp.com (cherry picked from commit 8d7b7a0d71e0b89321b3341b781bc8845386def6) [anholt: re-applied to revert the revert, now that the cause of the revert is fixed] --- damageext/damageext.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/damageext/damageext.c b/damageext/damageext.c index 4aa0ff3..754383d 100644 --- a/damageext/damageext.c +++ b/damageext/damageext.c @@ -217,6 +217,7 @@ ProcDamageCreate (ClientPtr client) if (!AddResource (stuff-damage, DamageExtType, (pointer) pDamageExt)) return BadAlloc; +DamageSetReportAfterOp (pDamageExt-pDamage, TRUE); DamageRegister (pDamageExt-pDrawable, pDamageExt-pDamage); if (pDrawable-type == DRAWABLE_WINDOW) -- 1.7.2.3 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 1/2] Replace usage of DamageRegionAppend with DamageDamageRegion to fix reportAfter.
In all these cases, any rendering implied by this damage has already
occurred, and we want to get the damage out to the client. Some of
the DamageRegionAppend calls were explicitly telling damage to flush
the reportAfter damage out, but not all.
Bug #30260. Fixes the compiz wallpaper plugin with client damage
changed to reportAfter.
Signed-off-by: Eric Anholt e...@anholt.net
---
composite/compalloc.c |2 +-
composite/compwindow.c|4 ++--
damageext/damageext.c |4 ++--
exa/exa.c |3 +--
glx/glxdri.c |4 +---
hw/xfree86/modes/xf86Rotate.c |2 +-
6 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/composite/compalloc.c b/composite/compalloc.c
index 47d5c0a..c86eb9b 100644
--- a/composite/compalloc.c
+++ b/composite/compalloc.c
@@ -238,7 +238,7 @@ compFreeClientWindow (WindowPtr pWin, XID id)
DamageRegister (pWin-drawable, cw-damage);
cw-damageRegistered = TRUE;
pWin-redirectDraw = RedirectDrawAutomatic;
- DamageRegionAppend(pWin-drawable, pWin-borderSize);
+ DamageDamageRegion(pWin-drawable, pWin-borderSize);
}
if (wasMapped !pWin-mapped)
{
diff --git a/composite/compwindow.c b/composite/compwindow.c
index 8849dc3..d17ff77 100644
--- a/composite/compwindow.c
+++ b/composite/compwindow.c
@@ -519,7 +519,7 @@ compCopyWindow (WindowPtr pWin, DDXPointRec ptOldOrg,
RegionPtr prgnSrc)
RegionTranslate(prgnSrc,
pWin-drawable.x - ptOldOrg.x,
pWin-drawable.y - ptOldOrg.y);
- DamageRegionAppend(pWin-drawable, prgnSrc);
+ DamageDamageRegion(pWin-drawable, prgnSrc);
}
cs-CopyWindow = pScreen-CopyWindow;
pScreen-CopyWindow = compCopyWindow;
@@ -598,7 +598,7 @@ compSetRedirectBorderClip (WindowPtr pWin, RegionPtr
pRegion)
/*
* Report that as damaged so it will be redrawn
*/
-DamageRegionAppend(pWin-drawable, damage);
+DamageDamageRegion(pWin-drawable, damage);
RegionUninit(damage);
/*
* Save the new border clip region
diff --git a/damageext/damageext.c b/damageext/damageext.c
index f5265dd..4aa0ff3 100644
--- a/damageext/damageext.c
+++ b/damageext/damageext.c
@@ -222,7 +222,7 @@ ProcDamageCreate (ClientPtr client)
if (pDrawable-type == DRAWABLE_WINDOW)
{
pRegion = ((WindowPtr) pDrawable)-borderClip;
- DamageRegionAppend(pDrawable, pRegion);
+ DamageDamageRegion(pDrawable, pRegion);
}
return Success;
@@ -292,7 +292,7 @@ ProcDamageAdd (ClientPtr client)
* screen coordinates like damage expects.
*/
RegionTranslate(pRegion, pDrawable-x, pDrawable-y);
-DamageRegionAppend(pDrawable, pRegion);
+DamageDamageRegion(pDrawable, pRegion);
RegionTranslate(pRegion, -pDrawable-x, -pDrawable-y);
return Success;
diff --git a/exa/exa.c b/exa/exa.c
index fc15c24..8adf847 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -159,8 +159,7 @@ exaPixmapDirty (PixmapPtr pPix, int x1, int y1, int x2, int
y2)
return;
RegionInit(region, box, 1);
-DamageRegionAppend(pPix-drawable, region);
-DamageRegionProcessPending(pPix-drawable);
+DamageDamageRegion(pPix-drawable, region);
RegionUninit(region);
}
diff --git a/glx/glxdri.c b/glx/glxdri.c
index 41482c9..6458ef9 100644
--- a/glx/glxdri.c
+++ b/glx/glxdri.c
@@ -834,9 +834,7 @@ static void __glXReportDamage(__DRIdrawable *driDraw,
RegionInit(region, (BoxPtr) rects, num_rects);
RegionTranslate(region, pDraw-x, pDraw-y);
-DamageRegionAppend(pDraw, region);
-/* This is wrong, this needs a seperate function. */
-DamageRegionProcessPending(pDraw);
+DamageDamageRegion(pDraw, region);
RegionUninit(region);
__glXleaveServer(GL_FALSE);
diff --git a/hw/xfree86/modes/xf86Rotate.c b/hw/xfree86/modes/xf86Rotate.c
index fdc38c5..57c3499 100644
--- a/hw/xfree86/modes/xf86Rotate.c
+++ b/hw/xfree86/modes/xf86Rotate.c
@@ -168,7 +168,7 @@ xf86CrtcDamageShadow (xf86CrtcPtr crtc)
if (damage_box.x2 pScreen-width) damage_box.x2 = pScreen-width;
if (damage_box.y2 pScreen-height) damage_box.y2 = pScreen-height;
RegionInit(damage_region, damage_box, 1);
-DamageRegionAppend ((*pScreen-GetScreenPixmap)(pScreen)-drawable,
+DamageDamageRegion ((*pScreen-GetScreenPixmap)(pScreen)-drawable,
damage_region);
RegionUninit(damage_region);
crtc-shadowClear = TRUE;
--
1.7.2.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 1/2] Replace usage of DamageRegionAppend with DamageDamageRegion to fix reportAfter.
On Fri, 29 Oct 2010 10:46:00 +0200, Michel Dänzer mic...@daenzer.net wrote: On Don, 2010-10-28 at 20:46 -0700, Eric Anholt wrote: In all these cases, any rendering implied by this damage has already occurred, and we want to get the damage out to the client. Some of the DamageRegionAppend calls were explicitly telling damage to flush the reportAfter damage out, but not all. I haven't been able to confirm it on some quick tests, but I suspect this will break EXA in some cases, as it assumes that between a DamageRegionAppend/DamageRegionProcessPending call pair the corresponding region will be modified by a rendering operation and will thus be valid in the current copy of the pixmap contents and invalid in the other copy. Maybe what's needed here is some other mechanism for specifying a region that is not related to actual rendering but only to be reported to clients via the DAMAGE extension for informational purposes. FWIW, the test that prompted me to split up damage processing into two steps was starting compiz in an xterm on an otherwise 'naked' X server. The xterm window borders (the parts between the decoration and the actual terminal contents) would previously be corrupted. I suspect this change will reintroduce that problem with the EXA 'classic' scheme at least. Breakdown of the actual changed locations here: compalloc.c: notification to trigger recomposite on transition to automatic compositing. compwindow.c: 1) client notification of damage after optimized-out noop internal rendering (introduced with original import of composite, I'm not clear on why it's needed) 2) client notification of damage to trigger a redraw. damageext.c: 1) client notification of full damage in new damage struct on a window to trigger a redraw 2) adding damage to a drawable *for direct rendering that has already occurred* exa.c: Noop, replacing two function calls with the right one. glxdri: Noop, replacing two function calls with the right one. xf86Rotate.c: full damage on new shadow to trigger full shadow redraw later. Without this change, you'll still get the pending damage reported at some later date when other damage occurs to the pixmap that triggers a processing of pending damage, completely disconnected from when the rendering occurred, if any was involved. This just brings the reporting in to when it's supposed to happen, because either the rendering has already happened or it's a communication mechanism between the server internals and compositing (either automatic or manual) to trigger a redraw so that EXA has some actual rendering (which will, itself, produce damage for actual rendering). I can't see how this would make EXA any more broken. pgpCFVX8sdJKW.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Define/use pad_to_pow_two() instead of open coding it
On Wed, 24 Mar 2010 14:59:04 -0400, Matt Turner matts...@gmail.com wrote:
On Wed, Mar 24, 2010 at 2:56 PM, Mark Kettenis mark.kette...@xs4all.nl
wrote:
From: Matt Turner matts...@gmail.com
Date: Wed, 24 Mar 2010 13:57:15 -0400
diff --git a/hw/dmx/dmxpict.c b/hw/dmx/dmxpict.c
index 072e3a6..51616bb 100644
--- a/hw/dmx/dmxpict.c
+++ b/hw/dmx/dmxpict.c
@@ -674,7 +674,7 @@ static int dmxProcRenderSetPictureFilter(ClientPtr
client)
if (pPictPriv-pict) {
filter = (char *)(stuff + 1);
- params = (XFixed *)(filter + ((stuff-nbytes + 3) ~3));
+ params = (XFixed *)(filter + pad_to_pow_two(stuff-nbytes, 4));
Sorry, but to me this isn't an improvement. I probably spend to much
time on kernel hacking, but the origional is immediately obvious to
me, whereas the new line makes me think you're trying to align to a
16-byte boundary.
Hmm, yes, I see what you're saying. I changed the name to try to make
it explicitly obvious that 'alignment' must be a power of two, but I
see it is actually a little confusing.
What would you suggest for the name of the function?
ALIGN, like the kernel.
pgp9Qh0jYm4Xt.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] configure: introduce --{enable, disable}-syscall-clock
On Mon, 29 Mar 2010 14:59:35 -0400, Adam Jackson a...@redhat.com wrote: On Mon, 2010-03-29 at 11:02 -0700, Alan Coopersmith wrote: Tiago Vignatti wrote: Some systems might not want to link against rt and pthread libraries simply to implement monotonic clock, inside GetTimeInMillis(). For those, use a direct syscall instead. This patch keeps the new syscall version disabled by default - therefore not changing the original behaviour of the xserver build. The main concern was regarding some eventual performance degradation when not going through optimized code in C library, or because syscall is varargs based. That's actually my secondary concern - my primary concern is that on most non-Linux systems, the system libraries are the public, stable, supported, documented interface, and syscall() is a private implementation detail to those, which applications are strongly discouraged from calling directly. Yeah, it's not really something I want Linux to default to using either. I mean, we're going to want input threads, so slicing off librt just because it pulls in libpthread is a bit temporary. And Mesa's GLX support pulls in pthreads already, so the class of device where this applies is pretty thin. At the moment, clock_gettime() is the only reason I can't get Mesa off of libpthread. Before a bunch of ugly hacking in libdrm, the overhead From pthreads presence was around 10% CPU time on CPU-bound apps on i965. These days it's down to a few percent. It seems to me like the real problem is that clock_gettime() isn't in glibc without the pthreads cost. Perhaps someone could look into that instead of hacking around it in its consumers? pgpUT4KDV0U0S.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] configure: introduce --{enable, disable}-syscall-clock
On Mon, 05 Apr 2010 10:20:04 -0400, Adam Jackson a...@redhat.com wrote: On Fri, 2010-04-02 at 11:13 -1000, Eric Anholt wrote: On Mon, 29 Mar 2010 14:59:35 -0400, Adam Jackson a...@redhat.com wrote: Yeah, it's not really something I want Linux to default to using either. I mean, we're going to want input threads, so slicing off librt just because it pulls in libpthread is a bit temporary. And Mesa's GLX support pulls in pthreads already, so the class of device where this applies is pretty thin. At the moment, clock_gettime() is the only reason I can't get Mesa off of libpthread. Before a bunch of ugly hacking in libdrm, the overhead From pthreads presence was around 10% CPU time on CPU-bound apps on i965. These days it's down to a few percent. I'm not sure you're blaming the right piece of the world there. If you're referring to: commit 0d7ad7e43ca212b1e9f16cd18f36493cab455e61 Author: Eric Anholt e...@anholt.net Date: Tue Oct 20 14:19:38 2009 -0700 intel: Only call clock_gettime once per unreference_final. then I'm pretty sure the overhead there was calling clock_gettime at all. The implementation doesn't have any interaction with thread support. Compare runtimes from: http://people.freedesktop.org/~ajax/syscall/ Pretty sure you'll find them to be just about identical. It seems to me like the real problem is that clock_gettime() isn't in glibc without the pthreads cost. Perhaps someone could look into that instead of hacking around it in its consumers? The clock_gettime() implementation is in librt because that's where all the POSIX realtime stuff lives. Moving it into glibc wouldn't be especially difficult, though you'd need to get the symbol versioning right. No, I was talking about this problem: anh...@pollan:anholt/src/glsl2% ldd /usr/lib/librt.so linux-gate.so.1 = (0xe000) libc.so.6 = /lib/i686/cmov/libc.so.6 (0xb7761000) libpthread.so.0 = /lib/i686/cmov/libpthread.so.0 (0xb7748000) /lib/ld-linux.so.2 (0xb78cd000) By linking to librt to get clock_gettime, we pull in real pthreads, and all the mutex lock/unlocks everywhere else in our code go from free to ow ow ow stop it already. So we've relaxed a bunch of the locking in libdrm_intel and left it up to the user where the user was doing locking anyway for its requirements, and we've cut down the number of calls made to the parts that still do locking. pgpsqlpMi4avd.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Merged proto package
On Tue, 06 Apr 2010 15:41:41 -0700, Keith Packard kei...@keithp.com wrote: I've written some scripts that construct a merged proto package from the existing proto packages. They're not fancy, but do preserve the entire history of each sub package as they get merged in. Here's the merged package: git clone git://people.freedesktop.org/home/keithp/proto.git He meant git clone git://people.freedesktop.org/~keithp/proto.git and it can now be cloned via anongit. pgpnSJf6VIcKR.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 4/4] miext/damage: Only wrap into the GC ops chain if there's a listener
On Tue, 13 Dec 2011 17:31:53 -0500, Adam Jackson a...@redhat.com wrote: Before: 4000 trep @ 0.0009 msec (1148346.9/sec): PutImage 10x10 square 6000 trep @ 0.0005 msec (2091666.1/sec): ShmPutImage 10x10 square After: 4000 trep @ 0.0008 msec (1191807.5/sec): PutImage 10x10 square 6000 trep @ 0.0005 msec (2180983.0/sec): ShmPutImage 10x10 square Signed-off-by: Adam Jackson a...@redhat.com Reviewed-by: Eric Anholt e...@anholt.net pgpOtez327FCq.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 01/11] glx: Fix mishandling of shared contexts
On Fri, 23 Dec 2011 15:18:19 -0800, Ian Romanick i...@freedesktop.org wrote: From: Ian Romanick ian.d.roman...@intel.com Signed-off-by: Ian Romanick ian.d.roman...@intel.com --- glx/glxcmds.c | 22 +++--- 1 files changed, 11 insertions(+), 11 deletions(-) diff --git a/glx/glxcmds.c b/glx/glxcmds.c index d5b764f..c5de60d 100644 + /* Page 26 (page 32 of the PDF) of the GLX 1.4 spec says: + * + * The server context state for all sharing contexts must exist + * in a single address space or a BadMatch error is generated. + * + * If the share context is indirect, force the new context to also be + * indirect. If the shard context is direct but the new context shared. Other than that, I'm assuming that checking for address space matches between two direct contexts is handled by the client side (I think I recall code to that effect, and seems like the only possible place), which would make this: Reviewed-by: Eric Anholt e...@anholt.net pgp5HGNcSrGHG.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH intel-gpu-tools 00/10] Upgrade module configuration - Part 2
On Mon, 02 Jan 2012 18:23:15 -0500, Gaetan Nadon mems...@videotron.ca wrote: This series applies some xorg project policies and code reuse from util-macros. In some cases it reverts upgrades that were too new for the overall xorg. There were no bug fixes, things went smoothly. Both series for updates to automake infrastructure for this project are Acked-by: Eric Anholt e...@anholt.net I think I cribbed from xf86-video-intel when I originally did this stuff, and I didn't mean for it to be gratuitously different from our other projects, as I recall. pgp15r1mBdcSV.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH:intel-gpu-tools 0/6] Port to Solaris
On Fri, 6 Jan 2012 14:37:15 -0800, Alan Coopersmith alan.coopersm...@oracle.com wrote: This allows the tools to build on Solaris 11, using either gcc 4.5.2 or Solaris Studio 12.3. The tools that require the Linux debugfs don't run, but others, such as intel_gpu_top and intel_reg_dumper do work. I've tried not to break any other platforms, but haven't tested on any to confirm that. Alan Coopersmith (6): Provide Solaris implementation of intel_get_total_ram_mb Solaris defines struct winsize in termios.h Use sched_yield if pthread_yield is not available List out array values instead of using gcc range extension include fcntl.h in lib/intel_mmio.c for open() prototype on Solaris Fix pthread compiler flags to work on Solaris and with Studio compiler Acked-by: Eric Anholt e...@anholt.net pgp5XP5DaXLS9.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH synaptics 06/10] Drop circular pad support
On Wed, 9 May 2012 15:34:34 +1000, Peter Hutterer peter.hutte...@who-t.net wrote: Do such devices still exist? Yeah, I use a 6 year old one as my i915 test system. But then, it doesn't have any particular synaptics configuration done to it, so I guess the driver never knew it. Nor do I understand what downside I experienced from not having it set up. pgpkJvf6RawdG.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 01/02] dri2proto: Add DRI2GetParam request
On Thu, 10 May 2012 00:04:36 -0700, Chad Versace chad.vers...@linux.intel.com
wrote:
/*
* Events
@@ -330,4 +331,32 @@ typedef struct {
} xDRI2InvalidateBuffers;
#define sz_xDRI2InvalidateBuffers 32
+typedef struct {
+CARD8 reqType;
+CARD8 dri2ReqType;
+CARD16 length B16;
+CARD32 drawable B32;
+CARD32 namespace_ B32;
+CARD32 param_hi B32;
+CARD32 param_lo B32;
+} xDRI2GetParamReq;
+#define sz_xDRI2GetParamReq 20
64 bits of param enums? I'm going to go ahead and guess that we've
moved to a new protocol or driver implementation before we run out of 32 bits.
+┌───
+DRI2GetParam
+ drawable: DRAWABLE
+ namespace: DRI2PARAM_NAMESPACE
+ param: CARD64
+ ▶
+ is_param_recognized: BOOL
+ unused: 3 bytes
+ value: CARD64
+└───
+ Errors: Drawable, Value
+
+Get the value of a parameter. The parameter's value is looked up in
+ the 'namespace' on the screen associated with the 'drawable'.
+
+Possible values of 'param_is_recognized' are true (1) and
+ false(0). If false, then 'value' is undefined.
s/param_is_recognized/is_param_recognized/
pgpcRkLPwgq6O.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v3 02/02] dri2: Add DRI2GetParam request
On Wed, 16 May 2012 12:44:41 -0700, Chad Versace chad.vers...@linux.intel.com
wr diff --git a/hw/xfree86/dri2/dri2ext.c b/hw/xfree86/dri2/dri2ext.c
index 2579a5c..5487806 100644
--- a/hw/xfree86/dri2/dri2ext.c
+++ b/hw/xfree86/dri2/dri2ext.c
@@ -535,6 +535,38 @@ ProcDRI2WaitSBC(ClientPtr client)
}
static int
+ProcDRI2GetParam(ClientPtr client)
+{
+REQUEST(xDRI2GetParamReq);
+xDRI2GetParamReply rep;
+DrawablePtr pDrawable;
+CARD64 param;
Unused variable?
+CARD64 value;
+int status;
+
+REQUEST_SIZE_MATCH(xDRI2GetParamReq);
+rep.type = X_Reply;
+rep.length = 0;
+rep.sequenceNumber = client-sequence;
+
+if (!validDrawable(client, stuff-drawable, DixReadAccess,
+ pDrawable, status))
+return status;
+
+status = DRI2GetParam(client, pDrawable, stuff-param,
+ rep.is_param_recognized, value);
+rep.value_hi = value 32;
+rep.value_lo = value 0x;
+
+if (status != Success)
+return status;
+
+WriteToClient(client, sizeof(xDRI2GetParamReply), rep);
+
+return status;
+}
Other than that, this series is:
Reviewed-by: Eric Anholt e...@anholt.net
pgpSOHodxuXcU.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Mesa-dev] [PATCH] RFC: refactor out dri2 proto code into libdri2
On Thu, 22 Sep 2011 15:36:07 -0500, Rob Clark rob.cl...@linaro.org wrote: Since I was working on some extensions to DRI2 protocol for handling video, it occurred to me that it might be easier to extend the protocol if there weren't N different copies of dri2.c floating around in various different src trees.. also, for video, with one or two other small extensions (ie. standard way to mmap() GEM buffers), I think it should eventually be possible for DRI2 to be directly used by end applications (ie. for sw video decoders, etc). So refactoring this out into a shared library pretty much seemed like the right- thing-to-do. This patch updates mesa to remove two nearly identical copies of DRI2 protocol code. The error, wire-event, and event-wire stuff is split out into some callbacks, as this was really the only differences between the two copies of dri2.c (and also, other than name changes, the main difference between what is in mesa and vaapi). Also, from looking at the git history, it appears that these callbacks are the main place where there have been any changes to this code in the last couple years. Temporary home for libdri2 tree is here: git://people.freedesktop.org/~robclark/libdri2 Eventually I can make patches for libva and libvdpau.. but I started with mesa because that was something I actually had a way to test. Splitting out the code is definitely better than the copy and paste disaster we had before. I'd rather see us move to using XCB instead even more. But for that, I had issues with wiring up the event handling bits (which wants to intercept events inside the GL and not expose them to the client). pgp5Um71fUub9.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Pull v2] Glamor - fixed build failure, fixed coding style problem.
On Thu, 20 Oct 2011 09:54:29 +0200, Jamey Sharp ja...@minilop.net wrote: Non-text part: multipart/mixed Non-text part: multipart/signed This is also like Xgl, as I recall, in that Xgl was a large development effort happening inside a company (Novell, in that case) and then being dropped on the X.Org community. I'd say that had a lot to do with it eventually failing. A bunch of this work has Eric Anholt's and Kristian Høgsberg's names on it, and I'd have expected them to remember that debacle. I didn't get very far in the work before deciding that getting DRI2 working was going to be hard and that further work wasn't useful until I had some sort of plan for it. My intention back when I was working on it was to do incremental merging once DRI2 was figured out -- there's an obvious merge point where correct all-software-fallbacks are possible, then another when the first couple of blit paths are in, then Render accel. But now, in order to get DRI2 working with GL-based 2D, we're thinking of flipping the whole thing on its head and using our current driver, binding its BOs into GL, and doing incremental migration of our current rendering to GL rendering that way. We've burned ourselves switching to new AAs both times we've done it, so any plan that involves incremental changes has a lot recommending it. pgpBDQ0rU9xbt.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] int10: Remove the vm86 and stub backends
On Thu, 29 Jul 2010 13:53:39 -0400, Adam Jackson a...@nwnk.net wrote: On Wed, 2010-07-28 at 11:35 -0400, Alex Deucher wrote: On Wed, Jul 28, 2010 at 11:29 AM, Alan Coopersmith alan.coopersm...@oracle.com wrote: Isn't vm86 even further limited to just those machines running the Linux kernel, not BSD or Solaris or anything else? (Okay, maybe that doesn't take a huge chunk out of the number of machines that can run it, but it is replacing one more platform-specific difference with common code.) I could have sworn one of the BSDs had implemented a vm86 syscall, but I can't find any reference to it now. It certainly doesn't seem to exist under Solaris. FreeBSD had one. Trying to use it was a huge disaster, emulation was totally the way to go. pgpDHn8eryOFf.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH mesa] Include search for non pkg-config libtalloc.
On Wed, 8 Sep 2010 17:01:25 -0400, Trevor Woerner twoer...@gmail.com wrote: From: Trevor Woerner twoer...@gmail.com Change search for libtalloc so a build which includes it in a non pkg-config'ized form will succeed. Signed-off-by: Trevor Woerner twoer...@gmail.com --- My system includes libtalloc and libtalloc-devel in a way that is not pkg-config'ized. I'm hoping this or something like this will be accepted so my build can succeed. You should be able to make your build succeed with the TALLOC_LIBS and TALLOC_CFLAGS environment variables already. See ./configure --help. But if you want a fallback for distro shortcomings, please make it a fallback from pkg-config checking, rather than something that overrides pkg-config checking, as this patch would break PKG_CONFIG_PATH ./configure, for example. pgpbdPUpP53Fp.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [patches] Fix broken Render implementation in several video drivers (radeonhd, mga, i128)
On Tue, 2009-02-17 at 18:19 -0500, Thomas Jaeger wrote: I'm trying to break the vicious cycle where cairo can't forward composite operations with extend mode EXTEND_PAD to XRender because some drivers don't implement it correctly and the drivers don't get fixed because the bugs are not exposed by cairo. The (trivial) fixes consist of just announcing that the driver doesn't support the affected repeat modes, so that the server's software fallback will be used. This is good enough in practice and certainly much better than the current client-side fallback that cairo is using: If an application currently wants to upscale an image using a bilinear filter this is what happens: It needs to enable EXTEND_PAD so that the image borders are rendered correctly, so cairo will (1) fetch the destination region from the server (nevermind that it's going to be overwritten completely), (2) fetch the whole source image (even if only a tiny part of it will be redrawn, as is the case when scrolling), (3) scale the image in software and then (4) send it back to the server. All of this will go over the wire, no shared memory is used. It should come as no surprise that this is unacceptably slow, which for example forces firefox to ditch bilinear filtering completely. The following three drivers are still affected (bug reports: [1,2,3]): -radeonhd, -mga and -i128. Since -radeonhd shares most its exa code with -ati, it can just use the same fix that is already in -ati [4], and probably also take advantage of hardware acceleration that is present in -ati now [5]. I'm attaching the patches for the other two drivers to this email. Pushed, with one small tweak for mga. Thanks! -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: Default local auth policy
On Fri, 2009-03-13 at 13:46 -0400, Adam Jackson wrote: Currently, if you start X without -ac and without -auth, the default connection policy is to allow connections from localhost. In particular, this means on every IPv[46] address, and any local transports including unix sockets. I'd like to see a mode where the default policy is effectively +si:localuser:`id -un`, which would allow connections only from the uid that started the server. This is effectively the policy everyone's trying to implement with xauth cookies, but cookies have to get stored on disk somewhere which sucks for NFS and r/o images, etc. For the gdm case, the display manager would add the real user to the access list once they've been authed, and then remove itself and start the session as the user. Normally I'd just change the default here, but I think this might be a significant enough difference in behaviour that you should have to ask for it. So. New -localuser option? Change the default? Bad idea, give up, take up farming? It sounds sensible, the only thing I'm concerned about is whether with this new default I could sudo X app and still get success. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: Default local auth policy
On Tue, 2009-03-17 at 14:06 -0400, Adam Jackson wrote: On Mon, 2009-03-16 at 12:52 -0700, Eric Anholt wrote: On Fri, 2009-03-13 at 13:46 -0400, Adam Jackson wrote: Currently, if you start X without -ac and without -auth, the default connection policy is to allow connections from localhost. In particular, this means on every IPv[46] address, and any local transports including unix sockets. I'd like to see a mode where the default policy is effectively +si:localuser:`id -un`, which would allow connections only from the uid that started the server. This is effectively the policy everyone's trying to implement with xauth cookies, but cookies have to get stored on disk somewhere which sucks for NFS and r/o images, etc. For the gdm case, the display manager would add the real user to the access list once they've been authed, and then remove itself and start the session as the user. Normally I'd just change the default here, but I think this might be a significant enough difference in behaviour that you should have to ask for it. So. New -localuser option? Change the default? Bad idea, give up, take up farming? It sounds sensible, the only thing I'm concerned about is whether with this new default I could sudo X app and still get success. It's not particularly well specified, at least for getsockopt(SO_PEERCRED). The Linux implementation appears to give you the effective UID, not real, so suid apps would fail. I'm not sure what the other OS's implement offhand. And sudo would fail as well? That's extremely uncool. Unless the plan is to add +si:localuser:0 as well. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: Temporary resolution changes?
On Wed, 2009-05-20 at 10:59 +0100, Luke Benstead wrote: Hi all, I recently had a discussion with a Wine developer and I mentioned that I had on several occasions been left at a low resolution when a fullscreen application crashes. He said that Wine could perhaps code in a fix which guaranteed the resolution was reset but he wasn't sure where this problem lied, or more specifically which project should fix it, as native games also suffer the same problem. Incidentally, the previous day I had been in a PC store and started up SuperTux on a netbook in the shop, I came back a few minutes later to find the desktop at a low resolution, the game had obviously crashed (desperate not to give a bad impression of Linux to passers by I reset the netbook ;) ) so I know it's quite a common issue. After more discussion with the Wine dev I learned/realized that Windows generally doesn't suffer a similar problem, because setting the CDS_FULLSCREEN flag in the DEVMODE structure (passed to ChangeDisplaySettings) indicates a temporary resolution change. If the program crashes, or is ALT+TABbed away from, Windows (usually) resets the resolution back to native. After some discussion on some forums I found this bug report: https://bugs.freedesktop.org/show_bug.cgi?id=14255 I really just interested to find out from you guys where you think the problem lies? Is it something that the X.org devs can fix? Or is it something that should be fixed higher up? Is a temp flag perhaps something that can be passed to xrandr when a resolution is set? I'd love to see an extension to RandR to handle this. It's been a serious problem of X's modesetting APIs forever. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xserver: remove all of RAC and access code
On Tue, 2009-07-28 at 09:17 +1000, Dave Airlie wrote:
On Thu, 2009-07-23 at 12:32 +1000, Dave Airlie wrote:
this is a major API + ABI break, we'll be adding back vga arb support after
this hopefully.
So after a bit of messing around I think removing everything makes it
hard to build drivers for 1.6 and 1.7, so I'm going to add some api
compat for now.
Mainly I'm thinking of keeping the third member the pci
@@ -285,27 +273,29 @@ extern _X_EXPORT pointer xf86FindXvOptions(int
scrnIndex, int adapt_index, char
extern _X_EXPORT void xf86GetOS(const char **name, int *major, int *minor,
int *teeny);
extern _X_EXPORT ScrnInfoPtr xf86ConfigPciEntity(ScrnInfoPtr pScrn, int
scrnFlag,
int entityIndex,PciChipsets *p_chip,
- resList res, EntityProc init,
+ EntityProc init,
EntityProc enter, EntityProc leave,
pointer private);
extern _X_EXPORT ScrnInfoPtr xf86ConfigFbEntity(ScrnInfoPtr pScrn, int
scrnFlag,
int entityIndex, EntityProc init,
EntityProc enter, EntityProc leave,
pointer private);
+
/* Obsolete! don't use */
extern _X_EXPORT Bool xf86ConfigActivePciEntity(ScrnInfoPtr pScrn,
int entityIndex,PciChipsets *p_chip,
- resList res, EntityProc init,
+ EntityProc init,
EntityProc enter, EntityProc leave,
pointer private);
Add a spare member instead of resList, so the function signatures don't
change.
diff --git a/hw/xfree86/common/xf86Resources.h
b/hw/xfree86/common/xf86Resources.h
deleted file mode 100644
index 012fa69..000
--- a/hw/xfree86/common/xf86Resources.h
+++ /dev/null
@@ -1,137 +0,0 @@
-
-/* Old style names */
-#define RES_EXCLUSIVE_VGA resVgaExclusive
-#define RES_SHARED_VGA resVgaShared
-#define RES_EXCLUSIVE_8514 res8514Exclusive
-#define RES_SHARED_8514 res8514Shared
add some dummy defines for these.
-
typedef struct _PciChipsets {
/**
* Key used to match this device with its name in an array of
@@ -720,10 +581,6 @@ typedef struct _PciChipsets {
*/
int PCIid;
-/**
- * Resources associated with this type of device.
- */
-resRange *resList;
} PciChipsets;
add a dummy for resRange here so we don't have to rewrite the pci ids
structs in lots of drivers.
good idea or bad idea?
Love it!
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] pciaccess: remove xorg macros dependency
On Fri, 2009-07-17 at 02:05 +1000, Daniel Stone wrote: On Thu, Jul 16, 2009 at 08:27:12AM -0700, Eric Anholt wrote: On Thu, 2009-07-16 at 14:18 +0300, Tiago Vignatti wrote: -m4_ifndef([XORG_MACROS_VERSION], [AC_FATAL([must install xorg-macros 1.2 or later before running autoconf/autogen])]) -XORG_MACROS_VERSION(1.2) AM_CONFIG_HEADER(config.h) # Check for progs AC_PROG_CC AC_PROG_LIBTOOL -XORG_CWARNFLAGS pciids_path=/usr/share/hwdata AC_ARG_WITH(pciids-path, AC_HELP_STRING([--with-pciids-path=PCIIDS_PATH], @@ -108,9 +104,6 @@ AC_CHECK_MEMBER([struct pci_io.pi_sel.pc_domain], AC_SUBST(PCIACCESS_CFLAGS) AC_SUBST(PCIACCESS_LIBS) -XORG_RELEASE_VERSION -XORG_CHANGELOG - AC_OUTPUT([Makefile src/Makefile pciaccess.pc]) NAK. Reducing the functionality of the package for no reason. Agreed, but shouldn't XORG_RELEASE_VERSION be removed in general? Yeah, XORG_RELEASE_VERSION is terrible, and I think XORG_CHANGELOG is pretty bogus, too. Removing the warning cflags is what I don't like. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC PATCH] Only open the console if the video driver needs hardware access.
On Thu, 2009-10-01 at 20:58 +0200, Mark Kettenis wrote: Date: Thu, 1 Oct 2009 11:50:42 -0700 From: Jamey Sharp ja...@minilop.net xf86OpenConsole fails as non-root, at least on Linux. Since the xf86-video-dummy driver works fine without root privileges or console access, just don't open the console. --- I wanted to see how to replace Xvfb and Xfake with an appropriate video driver for the xfree86 DDX, and needing root privileges was obnoxious. Aside from that problem, the existing dummy driver seems well on the way to doing the job. But I'm guessing this is the wrong way to solve this problem. I suspect so. I think for example the wsfb driver on OpenBSD doesn't need hardware access in the xorgHWAccess sense, but still needs console access. This seems related to jbarnes's non-root X stuff http://lists.x.org/archives/xorg-devel/2009-July/001293.html Perhaps we need a flag for this ddx needs console access as well as this ddx needs io ports and such -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCHv2] Remove static MAXSCREENS limit from Xext/shm.c.
;
xShmGetImageReplyxgi;
ShmDescPtr shmdesc;
@@ -767,9 +794,11 @@ CreatePmap:
result = (client-noClientException);
FOR_NSCREENS(j) {
+ ShmScrPrivateRec *priv;
pScreen = screenInfo.screens[j];
- pMap = (*shmFuncs[j]-CreatePixmap)(pScreen,
+ priv = ShmGetScreenPriv(pScreen);
Stylistically, I like private fetching to be part of the declaration.
Less chance for early dereferencing. Also, as many layers have screen
privates, pixmap privates, gc privates, etc., it can be nice to name the
variables for the privates screen_priv, pixmap_priv, etc.
+ pMap = (*priv-shmFuncs-CreatePixmap)(pScreen,
stuff-width, stuff-height, stuff-depth,
shmdesc-addr + stuff-offset);
@@ -1052,6 +1081,7 @@ ProcShmCreatePixmap(ClientPtr client)
DepthPtr pDepth;
int i, rc;
ShmDescPtr shmdesc;
+ShmScrPrivateRec *priv;
REQUEST(xShmCreatePixmapReq);
unsigned int width, height, depth;
unsigned long size;
@@ -1100,7 +1130,8 @@ CreatePmap:
return BadAlloc;
VERIFY_SHMSIZE(shmdesc, stuff-offset, size, client);
-pMap = (*shmFuncs[pDraw-pScreen-myNum]-CreatePixmap)(
+priv = ShmGetScreenPriv(pDraw-pScreen);
+pMap = (*priv-shmFuncs-CreatePixmap)(
pDraw-pScreen, stuff-width,
stuff-height, stuff-depth,
shmdesc-addr + stuff-offset);
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 1/3] Remove shave now that automake-1.11 has AM_SILENT_RULES
On Mon, 2009-10-05 at 17:27 -0700, Alan Coopersmith wrote: Revert Add shave so that we can see the steaming piles of warnings generated. This reverts commit 181cc08c8908a119fc403f970dea8cc98d3e0b9b. shave was left in the xserver 1.7 release/branch to allow developers distros time to transition to automake-1.11. xserver 1.8 series will require automake-1.11 for silencing build noise. Signed-off-by: Alan Coopersmith alan.coopersm...@sun.com series is Reviewed-by: Eric Anholt e...@anholt.net -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Cast small-int values through intptr_t when they're passed as pointers.
On Mon, 2009-10-05 at 15:35 -0400, Adam Jackson wrote: On Sun, 2009-10-04 at 12:08 +1100, Daniel Stone wrote: On Fri, Oct 02, 2009 at 01:42:50PM -0700, Jamey Sharp wrote: On 64-bit systems, int and pointers don't have the same size, so GCC gives warnings about casts between int and pointer types. However, in the cases covered by this patch, it's always a value that fits in int being stored temporarily as a pointer and then converted back later, which is safe. Casting through the pointer-sized integer type intptr_t convinces the compiler that this is OK. Signed-off-by: Jamey Sharp ja...@minilop.net Alan, Matthieu -- is this portable enough? intptr_t is part of stdint.h in C99, but seems to also be in unistd.h in UNIX98, which is nearly universal by this point unlike C99. I would love love love to see us move entirely to stdint types instead of the mess we've got now. Yes. Yes yes yes. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Xcb] Thinking towards 7.6 katamari, including xcb
On Wed, 2009-10-28 at 08:38 -0700, Keith Packard wrote: Excerpts from Alex Deucher's message of Wed Oct 28 08:00:59 -0700 2009: So I think the main issue here is making building the xserver less daunting. The key external dependencies here are protocol headers and libdrm; does anyone have other stuff used in their driver that sees a lot of churn? For protocol headers, it seems like with the recent re-work, we should be at the point where newer headers should remain compatible with old versions of the server, which at least allows you to always use the newest headers without fear. Should we consider combining all of the protocol headers into a single module as well? Please yes. I've wanted this since the original modularization plan. I mostly live in the server + input driver + video driver update world, except that the server keeps needing a new point rev of 2-3 different protos. I've got 3.6MB in /usr/include/X11, but a lot of that is library headers. Developers can easily spare that, and I think every one of us would gladly make the trade of disk space for time pulling and building multiple packages to get the build done. I bet distros will be pretty happy with this plan as well. I'm *not* saying that we should merge libs or apps. Just protos. Libdrm is more of an issue as it often changes in sync with Mesa and driver updates. I don't have a great plan here, aside from the suggestion that we fix the X server to make building a subset of the drivers easy so that users wouldn't be affected by libdrm changes for chips they don't use. Libdrm has a pretty strict no-regressions policy. Old interfaces continue to exist, and headers keep working. A far better record than X.Org's proto and library headers. We also don't let our driver depend on unreleased libdrm. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] DRI2 synchronization and swap bits
On Fri, 2009-10-30 at 10:59 -0700, Jesse Barnes wrote: I've put up some trees (after learning my lesson about working in the main tree) with the latest DRI2 sync/swap bits: git://git.freedesktop.org/home/jbarnes/xserver master branch git://git.freedesktop.org/home/jbarnes/mesa master branch They includes support for some new DRI2 requests (proto for which is in the dri2-swapbuffers branch of dri2proto), including: DRI2SwapBuffers DRI2GetMSC DRI2WaitMSC and DRI2WaitSBC These allow us to support GLX extensions like SGI_video_sync, OML_swap_control and SGI_swap_interval. There have been a few comments about the protocol so far: 1) DRI2SwapBuffers a) Concern about doing another round trip to fetch new buffers following the swap. I think this is a valid concern, we could potentially respond from the swap with the new buffers, but this would make some memory saving optimizations more difficult (e.g. freeing buffers if no drawing comes in for a short time after the swap). You're doing one round-trip anyway, and if users are concerned about the second one, go use XCB already. (We need to go fix Mesa to do that). -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: New development model check-in.
On Thu, 2009-11-19 at 01:41 +1100, Daniel Stone wrote:
On Wed, Nov 18, 2009 at 02:48:45PM +0100, Luc Verhaegen wrote:
On Thu, Nov 19, 2009 at 12:30:53AM +1100, Daniel Stone wrote:
I don't think that's necessarily true in areas that aren't EXA;
certainly, no-one else has complained, and the patch flow from both
regular and one-off contributors seems to be very similar to what it was
before the change.
I can't speak for Keith, but I would've assumed that as a major
subsystem responsible for some inordinately large percentage of commits
these days, that EXA would have (at least) one tree where one could pull
from to obtain the latest reviewed and mergeable EXA commits. It makes
everyone's lives a lot easier -- including yours, because you don't have
to patchbomb the list and follow up doggedly on the patchbombs. One
mail ('please pull the EXA tree') would suffice.
So if this mode of working is now imposed, does that mean that our ~ on
annarchy, which will supposedly hold such trees, will be backed up now?
Right now, it's not, but someone proposed backing up at least the git
trees, which I think makes a great deal of sense.
I'd be pretty concerned if a git tree for a major component like EXA
vanished with no-one at all having any kind of copy of it though;
wouldn't you?
In the last data loss, my ~anholt/mesa disappeared. I figured I'd
re-upload it at some point, but there are a bunch of branches to put up,
so I put it off. Some people wanted some of it, but meh. Yesterday, in
the midst of some travel-related sleep-dep I nearly hosed my Mesa git
tree, and realized that my backup of my Mesa tree (annarchy) wasn't
backed up at the moment, and I could have lost everything.
Yeah, my laptop should be backed up. But could we please backup
annarchy for imperfect people?
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] exa: Fix a warning when enabling DEBUG_TRACE_FALL
Thierry Reding thierry.red...@gmail.com writes: From: Thierry Reding tred...@nvidia.com The format string wants a picture and a character, but the argument list contains only a character, causing GCC to complain. Add the missing argument. Signed-off-by: Thierry Reding tred...@nvidia.com Reviewed-by: Eric Anholt e...@anholt.net pgptLseT_DeD7.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 2/6] xephyr: Pass incoming XCB events to the Xlib event filter.
This is the same thing that Qt ended up doing to get DRI2's event
mangling to happen despite using an XCB event loop.
Signed-off-by: Eric Anholt e...@anholt.net
Reviewed-by: Keith Packard kei...@keithp.com
---
hw/kdrive/ephyr/ephyr.c| 3 +++
hw/kdrive/ephyr/ephyr_glamor_glx.c | 39 ++
hw/kdrive/ephyr/ephyr_glamor_glx.h | 15 +--
3 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/hw/kdrive/ephyr/ephyr.c b/hw/kdrive/ephyr/ephyr.c
index 75a6fcb..def50d8 100644
--- a/hw/kdrive/ephyr/ephyr.c
+++ b/hw/kdrive/ephyr/ephyr.c
@@ -1223,6 +1223,9 @@ ephyrPoll(void)
break;
}
+if (ephyr_glamor)
+ephyr_glamor_process_event(xev);
+
free(xev);
}
}
diff --git a/hw/kdrive/ephyr/ephyr_glamor_glx.c
b/hw/kdrive/ephyr/ephyr_glamor_glx.c
index a937c1a..d56907f 100644
--- a/hw/kdrive/ephyr/ephyr_glamor_glx.c
+++ b/hw/kdrive/ephyr/ephyr_glamor_glx.c
@@ -29,12 +29,17 @@
#include stdlib.h
#include X11/Xlib.h
+#include X11/Xlibint.h
+#undef Xcalloc
+#undef Xrealloc
+#undef Xfree
#include X11/Xlib-xcb.h
#include xcb/xcb_aux.h
#include pixman.h
#include epoxy/glx.h
#include ephyr_glamor_glx.h
#include os.h
+#include X11/Xproto.h
/** @{
*
@@ -218,6 +223,40 @@ ephyr_glamor_damage_redisplay(struct ephyr_glamor *glamor,
glXSwapBuffers(dpy, glamor-glx_win);
}
+/**
+ * Xlib-based handling of xcb events for glamor.
+ *
+ * We need to let the Xlib event filtering run on the event so that
+ * Mesa's dri2_glx.c userspace event mangling gets run, and we
+ * correctly get our invalidate events propagated into the driver.
+ */
+void
+ephyr_glamor_process_event(xcb_generic_event_t *xev)
+{
+
+uint32_t response_type = xev-response_type 0x7f;
+/* Note the types on wire_to_event: there's an Xlib XEvent (with
+ * the broken types) that it returns, and a protocol xEvent that
+ * it inspects.
+ */
+Bool (*wire_to_event)(Display *dpy, XEvent *ret, xEvent *event);
+
+XLockDisplay(dpy);
+/* Set the event handler to NULL to get access to the current one. */
+wire_to_event = XESetWireToEvent(dpy, response_type, NULL);
+if (wire_to_event) {
+XEvent processed_event;
+
+/* OK they had an event handler. Plug it back in, and call
+ * through to it.
+ */
+XESetWireToEvent(dpy, response_type, wire_to_event);
+xev-sequence = LastKnownRequestProcessed(dpy);
+wire_to_event(dpy, processed_event, (xEvent *)xev);
+}
+XUnlockDisplay(dpy);
+}
+
struct ephyr_glamor *
ephyr_glamor_glx_screen_init(xcb_window_t win)
{
diff --git a/hw/kdrive/ephyr/ephyr_glamor_glx.h
b/hw/kdrive/ephyr/ephyr_glamor_glx.h
index 950beff..8995e1e 100644
--- a/hw/kdrive/ephyr/ephyr_glamor_glx.h
+++ b/hw/kdrive/ephyr/ephyr_glamor_glx.h
@@ -53,10 +53,21 @@ ephyr_glamor_glx_screen_fini(struct ephyr_glamor *glamor);
void
ephyr_glamor_damage_redisplay(struct ephyr_glamor *glamor,
struct pixman_region16 *damage);
-#else
+
+void
+ephyr_glamor_process_event(xcb_generic_event_t *xev);
+
+#else /* !GLAMOR */
+
static inline void
ephyr_glamor_damage_redisplay(struct ephyr_glamor *glamor,
struct pixman_region16 *damage)
{
}
-#endif
+
+static inline void
+ephyr_glamor_process_event(xcb_generic_event_t *xev)
+{
+}
+
+#endif /* !GLAMOR */
--
1.9.rc1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
glamor: Enabling xephyr and Xorg.
Here's a short series to make the server glamor stuff actually testable. I'm now running glamor for my normal desktop, and the xephyr bits work too. I pulled out changes that would have required more from the intel 2d driver: now it's just a matter of not linking to the external module's libglamor.so, and not trying to do its own DRI3 support. I also pulled out the swap events code: While my timing tracecs on swap events are looking reasonable, there's really weird stuff going on with x11perf performance both before and after that change, and I'm holding off until I can understand it. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 3/6] xorg: Build a glamor_egl module.
This is not exposing the API we want long term, but it should get
existing DDX drivers up and running while we massage the API into
shape.
v2: Use LIBADD instead of LDFLAGS to fix deps on libglamor.la, and use
version 0.5.1 (the point it was forked from the external repo).
Signed-off-by: Eric Anholt e...@anholt.net
---
configure.ac | 11 +++
glamor/glamor_eglmodule.c | 3 ++-
hw/xfree86/Makefile.am| 7 ++-
hw/xfree86/glamor_egl/Makefile.am | 39 +++
include/dix-config.h.in | 3 +++
5 files changed, 61 insertions(+), 2 deletions(-)
create mode 100644 hw/xfree86/glamor_egl/Makefile.am
diff --git a/configure.ac b/configure.ac
index 5934950..74819bf 100644
--- a/configure.ac
+++ b/configure.ac
@@ -806,6 +806,8 @@ LIBAPPLEWM=applewm = 1.4
LIBDMX=dmx = 1.0.99.1
LIBDRI=dri = 7.8.0
LIBDRM=libdrm = 2.3.0
+LIBEGL=egl
+LIBGBM=gbm = 9
LIBGL=gl = 7.1.0
LIBXEXT=xext = 1.0.99.4
LIBXFONT=xfont = 1.4.2
@@ -2070,7 +2072,15 @@ AM_CONDITIONAL([GLAMOR], [test x$GLAMOR = xyes])
if test x$GLAMOR = xyes; then
AC_DEFINE(GLAMOR, 1, [Build glamor])
PKG_CHECK_MODULES([GLAMOR], [epoxy])
+
+ PKG_CHECK_MODULES(GBM, $LIBGBM, [GBM=yes], [GBM=no])
+ if test x$GBM = xyes; then
+ AC_DEFINE(GLAMOR_HAS_GBM, 1,
+ [Build glamor with GBM-based EGL support])
+ fi
+
fi
+AM_CONDITIONAL([GLAMOR_EGL], [test x$GBM = xyes])
dnl XWin DDX
@@ -2479,6 +2489,7 @@ hw/xfree86/exa/Makefile
hw/xfree86/exa/man/Makefile
hw/xfree86/fbdevhw/Makefile
hw/xfree86/fbdevhw/man/Makefile
+hw/xfree86/glamor_egl/Makefile
hw/xfree86/i2c/Makefile
hw/xfree86/int10/Makefile
hw/xfree86/loader/Makefile
diff --git a/glamor/glamor_eglmodule.c b/glamor/glamor_eglmodule.c
index 5ddd602..fb5b855 100644
--- a/glamor/glamor_eglmodule.c
+++ b/glamor/glamor_eglmodule.c
@@ -30,6 +30,7 @@
#include dix-config.h
#include xorg-server.h
+#include xf86.h
#define GLAMOR_FOR_XORG
#include xf86Module.h
#include glamor.h
@@ -40,7 +41,7 @@ static XF86ModuleVersionInfo VersRec = {
MODINFOSTRING1,
MODINFOSTRING2,
XORG_VERSION_CURRENT,
-PACKAGE_VERSION_MAJOR, PACKAGE_VERSION_MINOR, PACKAGE_VERSION_PATCHLEVEL,
+0, 5, 1, /* version */
ABI_CLASS_ANSIC,/* Only need the ansic layer */
ABI_ANSIC_VERSION,
MOD_CLASS_NONE,
diff --git a/hw/xfree86/Makefile.am b/hw/xfree86/Makefile.am
index 9672904..73e1b4c 100644
--- a/hw/xfree86/Makefile.am
+++ b/hw/xfree86/Makefile.am
@@ -14,6 +14,10 @@ DRI3_BUILDDIR = $(top_builddir)/dri3
DRI3_LIB = $(DRI3_BUILDDIR)/libdri3.la
endif
+if GLAMOR_EGL
+GLAMOR_EGL_SUBDIR = glamor_egl
+endif
+
if XF86UTILS
XF86UTILS_SUBDIR = utils
endif
@@ -33,7 +37,8 @@ endif
SUBDIRS = common ddc x86emu $(INT10_SUBDIR) os-support parser \
ramdac $(VGAHW_SUBDIR) loader modes $(DRI_SUBDIR) \
$(DRI2_SUBDIR) . $(VBE_SUBDIR) i2c dixmods \
- fbdevhw shadowfb exa $(XF86UTILS_SUBDIR) doc man
+ fbdevhw shadowfb exa $(XF86UTILS_SUBDIR) doc man \
+ $(GLAMOR_EGL_SUBDIR)
DIST_SUBDIRS = common ddc i2c x86emu int10 fbdevhw os-support \
parser ramdac shadowfb vbe vgahw \
diff --git a/hw/xfree86/glamor_egl/Makefile.am
b/hw/xfree86/glamor_egl/Makefile.am
new file mode 100644
index 000..827e033
--- /dev/null
+++ b/hw/xfree86/glamor_egl/Makefile.am
@@ -0,0 +1,39 @@
+# Copyright © 2013 Intel Corporation
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the Software),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+# IN THE SOFTWARE.
+
+module_LTLIBRARIES = libglamoregl.la
+
+libglamoregl_la_SOURCES = \
+ $(top_srcdir)/glamor/glamor_egl.c \
+ $(top_srcdir)/glamor/glamor_eglmodule.c \
+ $()
+
+libglamoregl_la_LDFLAGS = \
+ -avoid-version \
+ $(GBM_LIBS) \
+ $()
+
+libglamoregl_la_LIBADD = \
+ $(top_builddir)/glamor/libglamor.la \
+ $()
+
+AM_CPPFLAGS = $(XORG_INCS)
+AM_CFLAGS = $(DIX_CFLAGS
[PATCH 1/6] xephyr: Build support for rendering with glamor using a -glamor option.
v2: Avoid making the Ximage for the screen that we'll never use, and
drive the screen pixmap creation for glamor ourselves.
Signed-off-by: Eric Anholt e...@anholt.net
Reviewed-by: Keith Packard kei...@keithp.com (v1)
---
configure.ac | 3 +
glamor/glamor.c| 11 ++
glamor/glamor.h| 2 +
hw/kdrive/ephyr/Makefile.am| 20 ++-
hw/kdrive/ephyr/ephyr.c| 42 --
hw/kdrive/ephyr/ephyr.h| 14 ++
hw/kdrive/ephyr/ephyr_glamor_glx.c | 292 +
hw/kdrive/ephyr/ephyr_glamor_glx.h | 62
hw/kdrive/ephyr/ephyrinit.c| 14 ++
hw/kdrive/ephyr/hostx.c| 126 +++-
10 files changed, 570 insertions(+), 16 deletions(-)
create mode 100644 hw/kdrive/ephyr/ephyr_glamor_glx.c
create mode 100644 hw/kdrive/ephyr/ephyr_glamor_glx.h
diff --git a/configure.ac b/configure.ac
index 0fb2fc3..5934950 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2319,6 +2319,9 @@ if test $KDRIVE = yes; then
if test x$DRI = xyes test x$GLX = xyes; then
XEPHYR_REQUIRED_LIBS=$XEPHYR_REQUIRED_LIBS libdrm xcb-glx xcb-xf86dri
1.6
fi
+if test x$GLAMOR = xyes; then
+XEPHYR_REQUIRED_LIBS=$XEPHYR_REQUIRED_LIBS x11-xcb
+fi
if test x$XEPHYR = xauto; then
PKG_CHECK_MODULES(XEPHYR, $XEPHYR_REQUIRED_LIBS, [XEPHYR=yes],
[XEPHYR=no])
diff --git a/glamor/glamor.c b/glamor/glamor.c
index 7d8228c..85fd560 100644
--- a/glamor/glamor.c
+++ b/glamor/glamor.c
@@ -123,6 +123,17 @@ glamor_set_screen_pixmap(PixmapPtr screen_pixmap,
PixmapPtr *back_pixmap)
glamor_priv-back_pixmap = back_pixmap;
}
+uint32_t
+glamor_get_pixmap_texture(PixmapPtr pixmap)
+{
+glamor_pixmap_private *pixmap_priv = glamor_get_pixmap_private(pixmap);
+
+if (pixmap_priv-type != GLAMOR_TEXTURE_ONLY)
+return 0;
+
+return pixmap_priv-base.fbo-tex;
+}
+
PixmapPtr
glamor_create_pixmap(ScreenPtr screen, int w, int h, int depth,
unsigned int usage)
diff --git a/glamor/glamor.h b/glamor/glamor.h
index eec6872..08ffd26 100644
--- a/glamor/glamor.h
+++ b/glamor/glamor.h
@@ -124,6 +124,8 @@ extern _X_EXPORT Bool glamor_close_screen(ScreenPtr screen);
extern _X_EXPORT void glamor_set_screen_pixmap(PixmapPtr screen_pixmap,
PixmapPtr *back_pixmap);
+extern _X_EXPORT uint32_t glamor_get_pixmap_texture(PixmapPtr pixmap);
+
/* @glamor_glyphs_init: Initialize glyphs internal data structures.
*
* @pScreen: Current screen pointer.
diff --git a/hw/kdrive/ephyr/Makefile.am b/hw/kdrive/ephyr/Makefile.am
index 6b790fd..040993c 100644
--- a/hw/kdrive/ephyr/Makefile.am
+++ b/hw/kdrive/ephyr/Makefile.am
@@ -27,12 +27,20 @@ AM_CPPFLAGS = \
@XEPHYR_INCS@ \
@XEPHYR_CFLAGS@ \
-I$(top_srcdir) \
+ -I$(top_srcdir)/glamor \
-I$(top_srcdir)/exa
if XV
XV_SRCS = ephyrvideo.c
endif
+if GLAMOR
+GLAMOR_SRCS = \
+ ephyr_glamor_glx.c \
+ ephyr_glamor_glx.h \
+ ()
+endif
+
if DRI
DRI_SRCS = \
ephyrdriext.c \
@@ -59,14 +67,24 @@ Xephyr_SOURCES = \
hostx.h \
$(XV_SRCS) \
$(DRI_SRCS) \
+ $(GLAMOR_SRCS) \
$()
+if GLAMOR
+AM_CPPFLAGS += $(XLIB_CFLAGS)
+XEPHYR_GLAMOR_LIB = \
+ $(top_builddir)/glamor/libglamor.la \
+ $(top_builddir)/glamor/libglamor_egl_stubs.la \
+ $()
+endif
+
Xephyr_LDADD = \
$(top_builddir)/exa/libexa.la \
+ $(XEPHYR_GLAMOR_LIB)\
@KDRIVE_LIBS@ \
@XEPHYR_LIBS@
-Xephyr_DEPENDENCIES = @KDRIVE_LOCAL_LIBS@
+Xephyr_DEPENDENCIES = @KDRIVE_LOCAL_LIBS@ $(XEPHYR_GLAMOR_LIB)
Xephyr_LDFLAGS = $(LD_EXPORT_SYMBOLS_FLAG)
diff --git a/hw/kdrive/ephyr/ephyr.c b/hw/kdrive/ephyr/ephyr.c
index 9681273..75a6fcb 100644
--- a/hw/kdrive/ephyr/ephyr.c
+++ b/hw/kdrive/ephyr/ephyr.c
@@ -43,9 +43,15 @@
#include ephyrglxext.h
#endif /* XF86DRI */
+#ifdef GLAMOR
+#include glamor.h
+#endif
+#include ephyr_glamor_glx.h
+
#include xkbsrv.h
extern int KdTsPhyScreen;
+extern Bool ephyr_glamor;
KdKeyboardInfo *ephyrKbd;
KdPointerInfo *ephyrMouse;
@@ -326,15 +332,19 @@ ephyrInternalDamageRedisplay(ScreenPtr pScreen)
int nbox;
BoxPtr pbox;
-nbox = RegionNumRects(pRegion);
-pbox = RegionRects(pRegion);
-
-while (nbox--) {
-hostx_paint_rect(screen,
- pbox-x1, pbox-y1,
- pbox-x1, pbox-y1,
- pbox-x2 - pbox-x1, pbox-y2 - pbox-y1);
-pbox++;
+if (ephyr_glamor) {
+ephyr_glamor_damage_redisplay(scrpriv-glamor, pRegion);
+} else {
+nbox
[PATCH 6/6] glamor: Add support for DRI3.
The render-nodes case is untested.
v2: Add a flag for wayland to suppress the native DRI3 support.
Wayland isn't running as a master itself, so it can't do the auth
on its own and has to ask the compositor to do it for us. Dropped
XXX about randr provider -- the conclusion from discussion with
keithp was that if the driver's dri3_open for a provider on a
different screen, that's a core dri3 bug.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor.h | 4 +-
glamor/glamor_egl.c | 78 +++
hw/xfree86/glamor_egl/Makefile.am | 5 ++-
3 files changed, 85 insertions(+), 2 deletions(-)
diff --git a/glamor/glamor.h b/glamor/glamor.h
index 20988f4..d3520ab 100644
--- a/glamor/glamor.h
+++ b/glamor/glamor.h
@@ -67,10 +67,12 @@ typedef enum glamor_pixmap_type {
#define GLAMOR_USE_SCREEN (1 1)
#define GLAMOR_USE_PICTURE_SCREEN (1 2)
#define GLAMOR_USE_EGL_SCREEN (1 3)
+#define GLAMOR_NO_DRI3 (1 4)
#define GLAMOR_VALID_FLAGS (GLAMOR_INVERTED_Y_AXIS\
| GLAMOR_USE_SCREEN\
| GLAMOR_USE_PICTURE_SCREEN \
-| GLAMOR_USE_EGL_SCREEN)
+| GLAMOR_USE_EGL_SCREEN\
+ | GLAMOR_NO_DRI3)
/* @glamor_init: Initialize glamor internal data structure.
*
diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
index 56d8913..c883777 100644
--- a/glamor/glamor_egl.c
+++ b/glamor/glamor_egl.c
@@ -50,6 +50,7 @@
#include glamor.h
#include glamor_priv.h
+#include dri3.h
static const char glamor_name[] = glamor;
@@ -68,6 +69,7 @@ struct glamor_egl_screen_private {
EGLDisplay display;
EGLContext context;
EGLint major, minor;
+char *device_path;
CreateScreenResourcesProcPtr CreateScreenResources;
CloseScreenProcPtr CloseScreen;
@@ -627,10 +629,67 @@ glamor_egl_has_extension(struct glamor_egl_screen_private
*glamor_egl,
return FALSE;
}
+static int
+glamor_dri3_open(ScreenPtr screen,
+ RRProviderPtr provider,
+ int *fdp)
+{
+ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
+struct glamor_egl_screen_private *glamor_egl =
+glamor_egl_get_screen_private(scrn);
+int fd;
+drm_magic_t magic;
+
+fd = open(glamor_egl-device_path, O_RDWR|O_CLOEXEC);
+if (fd 0)
+return BadAlloc;
+
+/* Before FD passing in the X protocol with DRI3 (and increased
+ * security of rendering with per-process address spaces on the
+ * GPU), the kernel had to come up with a way to have the server
+ * decide which clients got to access the GPU, which was done by
+ * each client getting a unique (magic) number from the kernel,
+ * passing it to the server, and the server then telling the
+ * kernel which clients were authenticated for using the device.
+ *
+ * Now that we have FD passing, the server can just set up the
+ * authentication on its own and hand the prepared FD off to the
+ * client.
+ */
+if (drmGetMagic(fd, magic) 0) {
+if (errno == EACCES) {
+/* Assume that we're on a render node, and the fd is
+ * already as authenticated as it should be.
+ */
+*fdp = fd;
+return Success;
+} else {
+close(fd);
+return BadMatch;
+}
+}
+
+if (drmAuthMagic(glamor_egl-fd, magic) 0) {
+close(fd);
+return BadMatch;
+}
+
+*fdp = fd;
+return Success;
+}
+
+static dri3_screen_info_rec glamor_dri3_info = {
+.version = 0,
+.open = glamor_dri3_open,
+.pixmap_from_fd = glamor_pixmap_from_fd,
+.fd_from_pixmap = glamor_fd_from_pixmap,
+};
+
void
glamor_egl_screen_init(ScreenPtr screen, struct glamor_context *glamor_ctx)
{
ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
+glamor_screen_private *glamor_priv = glamor_get_screen_private(screen);
struct glamor_egl_screen_private *glamor_egl =
glamor_egl_get_screen_private(scrn);
@@ -642,6 +701,23 @@ glamor_egl_screen_init(ScreenPtr screen, struct
glamor_context *glamor_ctx)
glamor_ctx-get_context = glamor_egl_get_context;
glamor_ctx-put_context = glamor_egl_put_context;
+
+if (glamor_egl-dri3_capable !(glamor_priv-flags GLAMOR_NO_DRI3)) {
+/* Tell the core that we have the interfaces for import/export
+ * of pixmaps.
+ */
+glamor_enable_dri3(screen);
+
+/* To do DRI3 device FD generation, we need to open a new fd
+ * to the same device we were handed in originally.
+ */
+glamor_egl-device_path = drmGetDeviceNameFromFd(glamor_egl-fd);
+
+if (!dri3_screen_init(screen, glamor_dri3_info)) {
+xf86DrvMsg(scrn-scrnIndex, X_ERROR
[PATCH 5/6] glamor: Rename the DRI-related pixmap functions.
There was confusion over whether they should have egl in the name, and
they had DRI3 in the name even though they're useful to have without
DRI3.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor.c | 10 +-
glamor/glamor.h | 54 +
glamor/glamor_egl.c | 12 ++--
3 files changed, 41 insertions(+), 35 deletions(-)
diff --git a/glamor/glamor.c b/glamor/glamor.c
index 85fd560..0516716 100644
--- a/glamor/glamor.c
+++ b/glamor/glamor.c
@@ -567,16 +567,16 @@ glamor_enable_dri3(ScreenPtr screen)
}
Bool
-glamor_is_dri3_support_enabled(ScreenPtr screen)
+glamor_supports_pixmap_import_export(ScreenPtr screen)
{
glamor_screen_private *glamor_priv = glamor_get_screen_private(screen);
return glamor_priv-dri3_enabled;
}
-int
-glamor_dri3_fd_from_pixmap(ScreenPtr screen,
- PixmapPtr pixmap, CARD16 *stride, CARD32 *size)
+_X_EXPORT int
+glamor_fd_from_pixmap(ScreenPtr screen,
+ PixmapPtr pixmap, CARD16 *stride, CARD32 *size)
{
glamor_pixmap_private *pixmap_priv;
glamor_screen_private *glamor_priv =
@@ -600,7 +600,7 @@ glamor_dri3_fd_from_pixmap(ScreenPtr screen,
}
int
-glamor_dri3_name_from_pixmap(PixmapPtr pixmap)
+glamor_name_from_pixmap(PixmapPtr pixmap, CARD16 *stride, CARD32 *size)
{
glamor_pixmap_private *pixmap_priv;
glamor_screen_private *glamor_priv =
diff --git a/glamor/glamor.h b/glamor/glamor.h
index 89e7d80..20988f4 100644
--- a/glamor/glamor.h
+++ b/glamor/glamor.h
@@ -173,21 +173,23 @@ extern _X_EXPORT int
glamor_egl_dri3_fd_name_from_tex(ScreenPtr, PixmapPtr,
unsigned int, Bool,
CARD16 *, CARD32 *);
-/* @glamor_is_dri3_support_enabled: Returns if DRI3 support is enabled.
+/* @glamor_supports_pixmap_import_export: Returns whether
+ * glamor_fd_from_pixmap(), glamor_name_from_pixmap(), and
+ * glamor_pixmap_from_fd() are supported.
*
* @screen: Current screen pointer.
*
- * To have DRI3 support enabled, glamor and glamor_egl need to be initialized,
- * and glamor_egl_init_textured_pixmap need to be called. glamor also
- * has to be compiled with gbm support.
- * The EGL layer need to have the following extensions working:
+ * To have DRI3 support enabled, glamor and glamor_egl need to be
+ * initialized. glamor also has to be compiled with gbm support.
+ *
+ * The EGL layer needs to have the following extensions working:
+ *
* .EGL_KHR_gl_texture_2D_image
* .EGL_EXT_image_dma_buf_import
- * If DRI3 support is not enabled, the following helpers will return an error.
* */
-extern _X_EXPORT Bool glamor_is_dri3_support_enabled(ScreenPtr screen);
+extern _X_EXPORT Bool glamor_supports_pixmap_import_export(ScreenPtr screen);
-/* @glamor_dri3_fd_from_pixmap: DRI3 helper to get a dma-buf fd from a pixmap.
+/* @glamor_fd_from_pixmap: Get a dma-buf fd from a pixmap.
*
* @screen: Current screen pointer.
* @pixmap: The pixmap from which we want the fd.
@@ -198,22 +200,26 @@ extern _X_EXPORT Bool
glamor_is_dri3_support_enabled(ScreenPtr screen);
* content.
* Returns the fd on success, -1 on error.
* */
-extern _X_EXPORT int glamor_dri3_fd_from_pixmap(ScreenPtr screen,
-PixmapPtr pixmap,
-CARD16 *stride, CARD32 *size);
+extern _X_EXPORT int glamor_fd_from_pixmap(ScreenPtr screen,
+ PixmapPtr pixmap,
+ CARD16 *stride, CARD32 *size);
-/* @glamor_dri3_name_from_pixmap: helper to get an gem name from a pixmap.
+/**
+ * @glamor_name_from_pixmap: Gets a gem name from a pixmap.
*
* @pixmap: The pixmap from which we want the gem name.
*
- * the pixmap and the buffer associated by the gem name will share the same
- * content. This function can be used by the DDX to support DRI2, but needs
- * glamor DRI3 support to be activated.
+ * the pixmap and the buffer associated by the gem name will share the
+ * same content. This function can be used by the DDX to support DRI2,
+ * and needs the same set of buffer export GL extensions as DRI3
+ * support.
+ *
* Returns the name on success, -1 on error.
* */
-extern _X_EXPORT int glamor_dri3_name_from_pixmap(PixmapPtr pixmap);
+extern _X_EXPORT int glamor_name_from_pixmap(PixmapPtr pixmap,
+ CARD16 *stride, CARD32 *size);
-/* @glamor_egl_dri3_pixmap_from_fd: DRI3 helper to get a pixmap from a dma-buf
fd.
+/* @glamor_pixmap_from_fd: Creates a pixmap to wrap a dma-buf fd.
*
* @screen: Current screen pointer.
* @fd: The dma-buf fd to import.
@@ -225,13 +231,13 @@ extern _X_EXPORT int
glamor_dri3_name_from_pixmap(PixmapPtr pixmap);
*
* Returns a valid pixmap if the import succeeded, else NULL.
* */
-extern _X_EXPORT PixmapPtr
[PATCH 4/6] xorg: Connect up the glamor XV code, xorg DDX-only for now.
Porting this code to be non-xorg-dependent is going to take
significant hacking, so just dump it in the glamoregl module for the
moment, so I can hack on it while regression testing.
v2: Fix compiler warnings by adding #include dix-config.h at the top,
don't try to auto-init (I'll try to fix the xv ABI later).
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/Makefile.am| 1 -
glamor/glamor.h | 5 -
glamor/glamor_eglmodule.c | 2 +-
glamor/glamor_xv.c| 17 ++---
hw/xfree86/glamor_egl/Makefile.am | 1 +
5 files changed, 12 insertions(+), 14 deletions(-)
diff --git a/glamor/Makefile.am b/glamor/Makefile.am
index 12a57c4..77492bc 100644
--- a/glamor/Makefile.am
+++ b/glamor/Makefile.am
@@ -37,7 +37,6 @@ libglamor_la_SOURCES = \
glamor_window.c\
glamor_fbo.c\
glamor_compositerects.c\
- glamor_xv.c\
glamor_utils.h\
glamor.h
diff --git a/glamor/glamor.h b/glamor/glamor.h
index 08ffd26..89e7d80 100644
--- a/glamor/glamor.h
+++ b/glamor/glamor.h
@@ -35,6 +35,9 @@
#include picturestr.h
#include fb.h
#include fbpict.h
+#ifdef GLAMOR_FOR_XORG
+#include xf86xv.h
+#endif
struct glamor_context;
@@ -434,7 +437,7 @@ extern _X_EXPORT Bool glamor_poly_line_nf(DrawablePtr
pDrawable, GCPtr pGC,
extern _X_EXPORT Bool glamor_poly_lines_nf(DrawablePtr drawable, GCPtr gc,
int mode, int n, DDXPointPtr
points);
-#if 0
+#ifdef GLAMOR_FOR_XORG
extern _X_EXPORT XF86VideoAdaptorPtr glamor_xv_init(ScreenPtr pScreen,
int num_texture_ports);
#endif
diff --git a/glamor/glamor_eglmodule.c b/glamor/glamor_eglmodule.c
index fb5b855..d7e1836 100644
--- a/glamor/glamor_eglmodule.c
+++ b/glamor/glamor_eglmodule.c
@@ -41,7 +41,7 @@ static XF86ModuleVersionInfo VersRec = {
MODINFOSTRING1,
MODINFOSTRING2,
XORG_VERSION_CURRENT,
-0, 5, 1, /* version */
+1, 0, 0, /* version */
ABI_CLASS_ANSIC,/* Only need the ansic layer */
ABI_ANSIC_VERSION,
MOD_CLASS_NONE,
diff --git a/glamor/glamor_xv.c b/glamor/glamor_xv.c
index dc39476..a4ad031 100644
--- a/glamor/glamor_xv.c
+++ b/glamor/glamor_xv.c
@@ -32,10 +32,14 @@
* Xv acceleration implementation
*/
-#include glamor_priv.h
+#ifdef HAVE_DIX_CONFIG_H
+#include dix-config.h
+#endif
-#ifdef GLAMOR_XV
#include xf86xv.h
+#define GLAMOR_FOR_XORG
+#include glamor_priv.h
+
#include X11/extensions/Xv.h
#include fourcc.h
/* Reference color space transform data */
@@ -614,12 +618,3 @@ glamor_xv_init(ScreenPtr screen, int num_texture_ports)
}
return adapt;
}
-#else
-#if 0
-XF86VideoAdaptorPtr
-glamor_xv_init(ScreenPtr screen, int num_texture_ports)
-{
-return NULL;
-}
-#endif
-#endif
diff --git a/hw/xfree86/glamor_egl/Makefile.am
b/hw/xfree86/glamor_egl/Makefile.am
index 827e033..bb1b511 100644
--- a/hw/xfree86/glamor_egl/Makefile.am
+++ b/hw/xfree86/glamor_egl/Makefile.am
@@ -24,6 +24,7 @@ module_LTLIBRARIES = libglamoregl.la
libglamoregl_la_SOURCES = \
$(top_srcdir)/glamor/glamor_egl.c \
$(top_srcdir)/glamor/glamor_eglmodule.c \
+ $(top_srcdir)/glamor/glamor_xv.c \
$()
libglamoregl_la_LDFLAGS = \
--
1.9.rc1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 6/6] glamor: Add support for DRI3.
davya...@free.fr writes:
Hi,
While for XWayland we want to provide our own dri3_open, we still want to
have glamor
enabling the dri3 support
That is rather a GLAMOR_NO_DRI3_SETUP flag
and
+if (glamor_egl-dri3_capable !(glamor_priv-flags GLAMOR_NO_DRI3)) {
+/* Tell the core that we have the interfaces for import/export
+ * of pixmaps.
+ */
+glamor_enable_dri3(screen);
+
+/* To do DRI3 device FD generation, we need to open a new fd
+ * to the same device we were handed in originally.
+ */
+glamor_egl-device_path = drmGetDeviceNameFromFd(glamor_egl-fd);
+
+if (!dri3_screen_init(screen, glamor_dri3_info)) {
+xf86DrvMsg(scrn-scrnIndex, X_ERROR,
+ Failed to initialize DRI3.\n);
+}
+}
would be like that:
+if (glamor_egl-dri3_capable) {
+/* Tell the core that we have the interfaces for import/export
+ * of pixmaps.
+ */
+glamor_enable_dri3(screen);
+
+if (!(glamor_priv-flags GLAMOR_NO_DRI3_SETUP)) {
+/* To do DRI3 device FD generation, we need to open a new fd
+ * to the same device we were handed in originally.
+ */
+glamor_egl-device_path = drmGetDeviceNameFromFd(glamor_egl-fd);
+
+if (!dri3_screen_init(screen, glamor_dri3_info)) {
+xf86DrvMsg(scrn-scrnIndex, X_ERROR,
+ Failed to initialize DRI3.\n);
+}
+}
+}
Otherwise, it looks fine.
Perhaps it would be better to detect if the device is a render-node or not,
and if it is a render-node, then prevent doing an IOCTL call for nothing.
Yeah, I thought you were all about using render nodes, in which case you
don't need auth, so you would want to fix the generic path to detect
that and not need custom code and flags for wayland.
pgpDjn2XeNsiN.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 4/6] xorg: Connect up the glamor XV code, xorg DDX-only for now.
Porting this code to be non-xorg-dependent is going to take
significant hacking, so just dump it in the glamoregl module for the
moment, so I can hack on it while regression testing.
v2: Fix compiler warnings by adding #include dix-config.h at the top,
don't try to auto-init (I'll try to fix the xv ABI later).
v3: Fix last minute breakage of having reintroduced xf86ScrnToScreen
(one of the compat macros). Just use the drawable's pScreen instead.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/Makefile.am| 1 -
glamor/glamor.h | 5 -
glamor/glamor_eglmodule.c | 2 +-
glamor/glamor_xv.c| 19 +++
hw/xfree86/glamor_egl/Makefile.am | 1 +
5 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/glamor/Makefile.am b/glamor/Makefile.am
index 12a57c4..77492bc 100644
--- a/glamor/Makefile.am
+++ b/glamor/Makefile.am
@@ -37,7 +37,6 @@ libglamor_la_SOURCES = \
glamor_window.c\
glamor_fbo.c\
glamor_compositerects.c\
- glamor_xv.c\
glamor_utils.h\
glamor.h
diff --git a/glamor/glamor.h b/glamor/glamor.h
index 08ffd26..89e7d80 100644
--- a/glamor/glamor.h
+++ b/glamor/glamor.h
@@ -35,6 +35,9 @@
#include picturestr.h
#include fb.h
#include fbpict.h
+#ifdef GLAMOR_FOR_XORG
+#include xf86xv.h
+#endif
struct glamor_context;
@@ -434,7 +437,7 @@ extern _X_EXPORT Bool glamor_poly_line_nf(DrawablePtr
pDrawable, GCPtr pGC,
extern _X_EXPORT Bool glamor_poly_lines_nf(DrawablePtr drawable, GCPtr gc,
int mode, int n, DDXPointPtr
points);
-#if 0
+#ifdef GLAMOR_FOR_XORG
extern _X_EXPORT XF86VideoAdaptorPtr glamor_xv_init(ScreenPtr pScreen,
int num_texture_ports);
#endif
diff --git a/glamor/glamor_eglmodule.c b/glamor/glamor_eglmodule.c
index fb5b855..d7e1836 100644
--- a/glamor/glamor_eglmodule.c
+++ b/glamor/glamor_eglmodule.c
@@ -41,7 +41,7 @@ static XF86ModuleVersionInfo VersRec = {
MODINFOSTRING1,
MODINFOSTRING2,
XORG_VERSION_CURRENT,
-0, 5, 1, /* version */
+1, 0, 0, /* version */
ABI_CLASS_ANSIC,/* Only need the ansic layer */
ABI_ANSIC_VERSION,
MOD_CLASS_NONE,
diff --git a/glamor/glamor_xv.c b/glamor/glamor_xv.c
index dc39476..fb90457 100644
--- a/glamor/glamor_xv.c
+++ b/glamor/glamor_xv.c
@@ -32,10 +32,14 @@
* Xv acceleration implementation
*/
-#include glamor_priv.h
+#ifdef HAVE_DIX_CONFIG_H
+#include dix-config.h
+#endif
-#ifdef GLAMOR_XV
#include xf86xv.h
+#define GLAMOR_FOR_XORG
+#include glamor_priv.h
+
#include X11/extensions/Xv.h
#include fourcc.h
/* Reference color space transform data */
@@ -430,7 +434,7 @@ glamor_xv_put_image(ScrnInfoPtr pScrn,
Bool sync,
RegionPtr clipBoxes, void *data, DrawablePtr pDrawable)
{
-ScreenPtr screen = xf86ScrnToScreen(pScrn);
+ScreenPtr screen = pDrawable-pScreen;
glamor_port_private *port_priv = (glamor_port_private *) data;
INT32 x1, x2, y1, y2;
int srcPitch, srcPitch2;
@@ -614,12 +618,3 @@ glamor_xv_init(ScreenPtr screen, int num_texture_ports)
}
return adapt;
}
-#else
-#if 0
-XF86VideoAdaptorPtr
-glamor_xv_init(ScreenPtr screen, int num_texture_ports)
-{
-return NULL;
-}
-#endif
-#endif
diff --git a/hw/xfree86/glamor_egl/Makefile.am
b/hw/xfree86/glamor_egl/Makefile.am
index 827e033..bb1b511 100644
--- a/hw/xfree86/glamor_egl/Makefile.am
+++ b/hw/xfree86/glamor_egl/Makefile.am
@@ -24,6 +24,7 @@ module_LTLIBRARIES = libglamoregl.la
libglamoregl_la_SOURCES = \
$(top_srcdir)/glamor/glamor_egl.c \
$(top_srcdir)/glamor/glamor_eglmodule.c \
+ $(top_srcdir)/glamor/glamor_xv.c \
$()
libglamoregl_la_LDFLAGS = \
--
1.9.rc1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 5/6 v2] glamor: Rename the DRI-related pixmap functions.
There was confusion over whether they should have egl in the name, and
they had DRI3 in the name even though they're useful to have without
DRI3.
v2: Just rename glamor_name_from_pixmap for now -- I'd accidentally
conflict-resolved in adding new parameters from a later commit.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor.c | 10 +-
glamor/glamor.h | 53 +
glamor/glamor_egl.c | 12 ++--
3 files changed, 40 insertions(+), 35 deletions(-)
diff --git a/glamor/glamor.c b/glamor/glamor.c
index 85fd560..fa753bb 100644
--- a/glamor/glamor.c
+++ b/glamor/glamor.c
@@ -567,16 +567,16 @@ glamor_enable_dri3(ScreenPtr screen)
}
Bool
-glamor_is_dri3_support_enabled(ScreenPtr screen)
+glamor_supports_pixmap_import_export(ScreenPtr screen)
{
glamor_screen_private *glamor_priv = glamor_get_screen_private(screen);
return glamor_priv-dri3_enabled;
}
-int
-glamor_dri3_fd_from_pixmap(ScreenPtr screen,
- PixmapPtr pixmap, CARD16 *stride, CARD32 *size)
+_X_EXPORT int
+glamor_fd_from_pixmap(ScreenPtr screen,
+ PixmapPtr pixmap, CARD16 *stride, CARD32 *size)
{
glamor_pixmap_private *pixmap_priv;
glamor_screen_private *glamor_priv =
@@ -600,7 +600,7 @@ glamor_dri3_fd_from_pixmap(ScreenPtr screen,
}
int
-glamor_dri3_name_from_pixmap(PixmapPtr pixmap)
+glamor_name_from_pixmap(PixmapPtr pixmap)
{
glamor_pixmap_private *pixmap_priv;
glamor_screen_private *glamor_priv =
diff --git a/glamor/glamor.h b/glamor/glamor.h
index 89e7d80..041004e 100644
--- a/glamor/glamor.h
+++ b/glamor/glamor.h
@@ -173,21 +173,23 @@ extern _X_EXPORT int
glamor_egl_dri3_fd_name_from_tex(ScreenPtr, PixmapPtr,
unsigned int, Bool,
CARD16 *, CARD32 *);
-/* @glamor_is_dri3_support_enabled: Returns if DRI3 support is enabled.
+/* @glamor_supports_pixmap_import_export: Returns whether
+ * glamor_fd_from_pixmap(), glamor_name_from_pixmap(), and
+ * glamor_pixmap_from_fd() are supported.
*
* @screen: Current screen pointer.
*
- * To have DRI3 support enabled, glamor and glamor_egl need to be initialized,
- * and glamor_egl_init_textured_pixmap need to be called. glamor also
- * has to be compiled with gbm support.
- * The EGL layer need to have the following extensions working:
+ * To have DRI3 support enabled, glamor and glamor_egl need to be
+ * initialized. glamor also has to be compiled with gbm support.
+ *
+ * The EGL layer needs to have the following extensions working:
+ *
* .EGL_KHR_gl_texture_2D_image
* .EGL_EXT_image_dma_buf_import
- * If DRI3 support is not enabled, the following helpers will return an error.
* */
-extern _X_EXPORT Bool glamor_is_dri3_support_enabled(ScreenPtr screen);
+extern _X_EXPORT Bool glamor_supports_pixmap_import_export(ScreenPtr screen);
-/* @glamor_dri3_fd_from_pixmap: DRI3 helper to get a dma-buf fd from a pixmap.
+/* @glamor_fd_from_pixmap: Get a dma-buf fd from a pixmap.
*
* @screen: Current screen pointer.
* @pixmap: The pixmap from which we want the fd.
@@ -198,22 +200,25 @@ extern _X_EXPORT Bool
glamor_is_dri3_support_enabled(ScreenPtr screen);
* content.
* Returns the fd on success, -1 on error.
* */
-extern _X_EXPORT int glamor_dri3_fd_from_pixmap(ScreenPtr screen,
-PixmapPtr pixmap,
-CARD16 *stride, CARD32 *size);
+extern _X_EXPORT int glamor_fd_from_pixmap(ScreenPtr screen,
+ PixmapPtr pixmap,
+ CARD16 *stride, CARD32 *size);
-/* @glamor_dri3_name_from_pixmap: helper to get an gem name from a pixmap.
+/**
+ * @glamor_name_from_pixmap: Gets a gem name from a pixmap.
*
* @pixmap: The pixmap from which we want the gem name.
*
- * the pixmap and the buffer associated by the gem name will share the same
- * content. This function can be used by the DDX to support DRI2, but needs
- * glamor DRI3 support to be activated.
+ * the pixmap and the buffer associated by the gem name will share the
+ * same content. This function can be used by the DDX to support DRI2,
+ * and needs the same set of buffer export GL extensions as DRI3
+ * support.
+ *
* Returns the name on success, -1 on error.
* */
-extern _X_EXPORT int glamor_dri3_name_from_pixmap(PixmapPtr pixmap);
+extern _X_EXPORT int glamor_name_from_pixmap(PixmapPtr pixmap);
-/* @glamor_egl_dri3_pixmap_from_fd: DRI3 helper to get a pixmap from a dma-buf
fd.
+/* @glamor_pixmap_from_fd: Creates a pixmap to wrap a dma-buf fd.
*
* @screen: Current screen pointer.
* @fd: The dma-buf fd to import.
@@ -225,13 +230,13 @@ extern _X_EXPORT int
glamor_dri3_name_from_pixmap(PixmapPtr pixmap);
*
* Returns a valid pixmap if the import succeeded, else NULL
Re: [PATCH 1/2] xf86Config: Fix warning: declaration of 'Pointer' shadows a global
Hans de Goede hdego...@redhat.com writes: This fixes the following compiler warning: xf86Config.c: In function 'checkCoreInputDevices': xf86Config.c:1136:18: warning: declaration of 'Pointer' shadows a global declaration [-Wshadow] InputInfoPtr Pointer, Keyboard; ^ In file included from xf86Xinput.h:57:0, from xf86Config.c:66: /opt/xorg/include/X11/extensions/XIproto.h:88:24: warning: shadowed declaration is here [-Wshadow] typedef unsigned char *Pointer; Signed-off-by: Hans de Goede hdego...@redhat.com Looks like keithp just hasn't pusehd the reviewed change for inputproto yet. I'd rather see that land. Patch 2/2 is: Reviewed-by: Eric Anholt e...@anholt.net (I had similar, but it got nitpicked and I just don't care what type gets used). pgpZYCmRHVfI_.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PULL] glamor xephyr and xorg changes
The following changes since commit b634e909895f6001e7d9543e1350b20c82c8c01c: hw/xwin: More closely follow ICCCM for setting input focus (2014-03-03 14:33:09 +) are available in the git repository at: git://people.freedesktop.org/~anholt/xserver glamor-pull-request for you to fetch changes up to da08316605b26830b4d8f8fb2d9e69471cdc80ab: glamor: Add support for DRI3. (2014-03-05 13:10:24 -0800) Eric Anholt (6): xephyr: Build support for rendering with glamor using a -glamor option. xephyr: Pass incoming XCB events to the Xlib event filter. xorg: Build a glamor_egl module. xorg: Connect up the glamor XV code, xorg DDX-only for now. glamor: Rename the DRI-related pixmap functions. glamor: Add support for DRI3. configure.ac | 14 ++ glamor/Makefile.am | 1 - glamor/glamor.c| 21 ++- glamor/glamor.h| 64 --- glamor/glamor_egl.c| 97 ++- glamor/glamor_eglmodule.c | 3 +- glamor/glamor_xv.c | 19 +-- hw/kdrive/ephyr/Makefile.am| 20 ++- hw/kdrive/ephyr/ephyr.c| 45 +++-- hw/kdrive/ephyr/ephyr.h| 14 ++ hw/kdrive/ephyr/ephyr_glamor_glx.c | 331 + hw/kdrive/ephyr/ephyr_glamor_glx.h | 73 hw/kdrive/ephyr/ephyrinit.c| 14 ++ hw/kdrive/ephyr/hostx.c| 126 +- hw/xfree86/Makefile.am | 7 +- hw/xfree86/glamor_egl/Makefile.am | 43 + include/dix-config.h.in| 3 + 17 files changed, 827 insertions(+), 68 deletions(-) create mode 100644 hw/kdrive/ephyr/ephyr_glamor_glx.c create mode 100644 hw/kdrive/ephyr/ephyr_glamor_glx.h create mode 100644 hw/xfree86/glamor_egl/Makefile.am pgpHAeLZZLXwW.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 3/6] glamor: Add a note about the state of GL_ARB_map_buffer_range.
GLES2 Xephyr is failing due to lack of glMapBuffer() with the read
bits set, and I decided to see if we can just switch everything to
glMapBufferRange(). I'm undecided, and it largely depends on whether
we find people are interested in using glamor for the windows X server.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/glamor/glamor.c b/glamor/glamor.c
index fa753bb..fe9f761 100644
--- a/glamor/glamor.c
+++ b/glamor/glamor.c
@@ -319,6 +319,19 @@ glamor_init(ScreenPtr screen, unsigned int flags)
gl_version = glamor_gl_get_version();
+/* We'd like to require GL_ARB_map_buffer_range or
+ * GL_OES_map_buffer_range, since it offers more information to
+ * the driver than plain old glMapBuffer() or glBufferSubData().
+ * It's been supported on Mesa on the desktop since 2009 and on
+ * GLES2 since October 2012. It's supported on Apple's iOS
+ * drivers for SGX535 and A7, but apparently not on most Android
+ * devices (the OES extension spec wasn't released until June
+ * 2012).
+ *
+ * 82% of 0 A.D. players (desktop GL) submitting hardware reports
+ * have support for it, with most of the ones lacking it being on
+ * Windows with Intel 4-series (G45) graphics or older.
+ */
if (glamor_priv-gl_flavor == GLAMOR_GL_DESKTOP) {
if (gl_version GLAMOR_GL_VERSION_ENCODE(1, 3)) {
ErrorF(Require OpenGL version 1.3 or later.\n);
--
1.9.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 5/6] glamor: Fix a mismatched glamor_get/put_context().
We don't call GL in this function any more, so we can just drop the
get.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_gradient.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/glamor/glamor_gradient.c b/glamor/glamor_gradient.c
index 9f6f1b1..6a7b528 100644
--- a/glamor/glamor_gradient.c
+++ b/glamor/glamor_gradient.c
@@ -46,8 +46,6 @@ static const char *
_glamor_create_getcolor_fs_source(ScreenPtr screen, int stops_count,
int use_array)
{
-glamor_screen_private *glamor_priv;
-
char *gradient_fs = NULL;
#define gradient_fs_getcolor\
@@ -174,9 +172,6 @@ _glamor_create_getcolor_fs_source(ScreenPtr screen, int
stops_count,
return gradient_color;\n
}\n;
-glamor_priv = glamor_get_screen_private(screen);
-glamor_get_context(glamor_priv);
-
if (use_array) {
XNFasprintf(gradient_fs,
gradient_fs_getcolor, stops_count, stops_count);
--
1.9.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 4/6] dix: Remove incorrect comment about privates.
PRIVATE_ALL was apparently dropped before this comment was added in commit 495fc3eb2d6c98bde82ae1278f89fcf131fd9bf8. Signed-off-by: Eric Anholt e...@anholt.net --- dix/privates.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/dix/privates.c b/dix/privates.c index e03b225..dd26c6f 100644 --- a/dix/privates.c +++ b/dix/privates.c @@ -325,11 +325,10 @@ grow_screen_specific_set(DevPrivateType type, unsigned bytes) /* * Register a private key. This takes the type of object the key will - * be used with, which may be PRIVATE_ALL indicating that this key - * will be used with all of the private objects. If 'size' is - * non-zero, then the specified amount of space will be allocated in - * the private storage. Otherwise, space for a single pointer will - * be allocated which can be set with dixSetPrivate + * be used. If 'size' is non-zero, then the specified amount of space + * will be allocated in the private storage. Otherwise, space for a + * single pointer will be allocated which can be set with + * dixSetPrivate */ Bool dixRegisterPrivateKey(DevPrivateKey key, DevPrivateType type, unsigned size) -- 1.9.0 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 2/6] glamor: Fix a spelling mistake in GLAMOR_PIXMAP_FBO_NOT_EXACT_SIZE.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_pixmap.c | 2 +-
glamor/glamor_render.c | 2 +-
glamor/glamor_utils.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/glamor/glamor_pixmap.c b/glamor/glamor_pixmap.c
index f1440f3..119e4d9 100644
--- a/glamor/glamor_pixmap.c
+++ b/glamor/glamor_pixmap.c
@@ -1528,7 +1528,7 @@ glamor_fixup_pixmap_priv(ScreenPtr screen,
glamor_pixmap_private *pixmap_priv)
drawable = pixmap_priv-base.pixmap-drawable;
-if (!GLAMOR_PIXMAP_FBO_NOT_EAXCT_SIZE(pixmap_priv))
+if (!GLAMOR_PIXMAP_FBO_NOT_EXACT_SIZE(pixmap_priv))
return TRUE;
old_fbo = pixmap_priv-base.fbo;
diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index 093a215..f8d103d 100644
--- a/glamor/glamor_render.c
+++ b/glamor/glamor_render.c
@@ -584,7 +584,7 @@ glamor_set_composite_texture(glamor_screen_private
*glamor_priv, int unit,
else if (glamor_priv-gl_flavor == GLAMOR_GL_ES2
|| pixmap_priv-type == GLAMOR_TEXTURE_LARGE) {
if (picture-transform
-|| (GLAMOR_PIXMAP_FBO_NOT_EAXCT_SIZE(pixmap_priv)))
+|| (GLAMOR_PIXMAP_FBO_NOT_EXACT_SIZE(pixmap_priv)))
repeat_type += RepeatFix;
}
if (repeat_type = RepeatFix) {
diff --git a/glamor/glamor_utils.h b/glamor/glamor_utils.h
index 9374c9d..f9550b7 100644
--- a/glamor/glamor_utils.h
+++ b/glamor/glamor_utils.h
@@ -53,7 +53,7 @@
*(_pyscale_) = 1.0 / (_pixmap_priv_)-base.fbo-height;
\
} while(0)
-#define GLAMOR_PIXMAP_FBO_NOT_EAXCT_SIZE(priv) \
+#define GLAMOR_PIXMAP_FBO_NOT_EXACT_SIZE(priv) \
(priv-base.fbo-width != priv-base.pixmap-drawable.width \
|| priv-base.fbo-height != priv-base.pixmap-drawable.height) \
--
1.9.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 6/6] xephyr: Don't forget to glViewport() before drawing the screen.
Fixes misrendering with cairogears. I had noticed the failure while
trying to figure out what was going on with traps. Cairogears was
apparently putting its results on the screen through putimage, which
is a texture upload, so the last GL drawing was done to the size of
the cairogears window, not the size of the xephyr screen.
---
hw/kdrive/ephyr/ephyr_glamor_glx.c | 15 +++
hw/kdrive/ephyr/ephyr_glamor_glx.h | 10 ++
hw/kdrive/ephyr/hostx.c| 4
3 files changed, 29 insertions(+)
diff --git a/hw/kdrive/ephyr/ephyr_glamor_glx.c
b/hw/kdrive/ephyr/ephyr_glamor_glx.c
index d56907f..eaf5654 100644
--- a/hw/kdrive/ephyr/ephyr_glamor_glx.c
+++ b/hw/kdrive/ephyr/ephyr_glamor_glx.c
@@ -67,6 +67,9 @@ struct ephyr_glamor {
GLuint texture_shader;
GLuint texture_shader_position_loc;
GLuint texture_shader_texcoord_loc;
+
+/* Size of the window that we're rendering to. */
+unsigned width, height;
};
static GLint
@@ -205,6 +208,7 @@ ephyr_glamor_damage_redisplay(struct ephyr_glamor *glamor,
glBindFramebuffer(GL_FRAMEBUFFER, 0);
glUseProgram(glamor-texture_shader);
+glViewport(0, 0, glamor-width, glamor-height);
glVertexAttribPointer(glamor-texture_shader_position_loc,
2, GL_FLOAT, FALSE, 0, position);
@@ -329,3 +333,14 @@ ephyr_glamor_get_visual(void)
return xcb_aux_find_visual_by_id(xscreen, visual_info-visualid);
}
+
+void
+ephyr_glamor_set_window_size(struct ephyr_glamor *glamor,
+ unsigned width, unsigned height)
+{
+if (!glamor)
+return;
+
+glamor-width = width;
+glamor-height = height;
+}
diff --git a/hw/kdrive/ephyr/ephyr_glamor_glx.h
b/hw/kdrive/ephyr/ephyr_glamor_glx.h
index 8995e1e..0c238cf 100644
--- a/hw/kdrive/ephyr/ephyr_glamor_glx.h
+++ b/hw/kdrive/ephyr/ephyr_glamor_glx.h
@@ -51,6 +51,10 @@ ephyr_glamor_glx_screen_fini(struct ephyr_glamor *glamor);
#ifdef GLAMOR
void
+ephyr_glamor_set_window_size(struct ephyr_glamor *glamor,
+ unsigned width, unsigned height);
+
+void
ephyr_glamor_damage_redisplay(struct ephyr_glamor *glamor,
struct pixman_region16 *damage);
@@ -60,6 +64,12 @@ ephyr_glamor_process_event(xcb_generic_event_t *xev);
#else /* !GLAMOR */
static inline void
+ephyr_glamor_set_window_size(struct ephyr_glamor *glamor,
+ unsigned width, unsigned height)
+{
+}
+
+static inline void
ephyr_glamor_damage_redisplay(struct ephyr_glamor *glamor,
struct pixman_region16 *damage)
{
diff --git a/hw/kdrive/ephyr/hostx.c b/hw/kdrive/ephyr/hostx.c
index 19c2ed2..66019a3 100644
--- a/hw/kdrive/ephyr/hostx.c
+++ b/hw/kdrive/ephyr/hostx.c
@@ -728,6 +728,8 @@ hostx_screen_init(KdScreenInfo *screen,
if (ephyr_glamor) {
*bytes_per_line = 0;
*bits_per_pixel = 0;
+ephyr_glamor_set_window_size(scrpriv-glamor,
+ scrpriv-win_width, scrpriv-win_height);
return NULL;
} else if (host_depth_matches_server(scrpriv)) {
*bytes_per_line = scrpriv-ximg-stride;
@@ -1213,6 +1215,8 @@ ephyr_glamor_init(ScreenPtr screen)
EphyrScrPriv *scrpriv = kd_screen-driver;
scrpriv-glamor = ephyr_glamor_glx_screen_init(scrpriv-win);
+ephyr_glamor_set_window_size(scrpriv-glamor,
+ scrpriv-win_width, scrpriv-win_height);
glamor_init(screen,
GLAMOR_USE_SCREEN |
--
1.9.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
little glamor cleanups (and a dix cleanup)
Here are some trivial patches from the glamor-server branch for review. I'm planning to send out the VBO changes next, which get us closer to making glamor not actually suck for performance. These are on the glamor-cleanups branch of my tree, branched from glamor-pull-request. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 1/6] glamor: remove dead global variable.
Signed-off-by: Eric Anholt e...@anholt.net --- glamor/glamor_pixmap.c | 1 - 1 file changed, 1 deletion(-) diff --git a/glamor/glamor_pixmap.c b/glamor/glamor_pixmap.c index 77197b5..f1440f3 100644 --- a/glamor/glamor_pixmap.c +++ b/glamor/glamor_pixmap.c @@ -697,7 +697,6 @@ glamor_color_convert_to_bits(void *src_bits, void *dst_bits, int w, int h, * Upload pixmap to a specified texture. * This texture may not be the one attached to it. **/ -int in_restore = 0; static void __glamor_upload_pixmap_to_texture(PixmapPtr pixmap, unsigned int *tex, GLenum format, -- 1.9.0 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] glx: Clear new FBConfig attributes to 0 by default.
The visualSelectGroup wasn't getting set (since our DRI drivers don't use it), and and since it's the top priority in the sort order, you got random sorting of your visuals unless malloc really returned you new memory. This manifested as Xephyr -glamor rendering to a multisampled window on my system, which as you might guess was slightly lower performance than expected. Signed-off-by: Eric Anholt e...@anholt.net --- glx/glxdricommon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/glx/glxdricommon.c b/glx/glxdricommon.c index 69d4b29..62cce13 100644 --- a/glx/glxdricommon.c +++ b/glx/glxdricommon.c @@ -132,7 +132,7 @@ createModeFromConfig(const __DRIcoreExtension * core, unsigned int attrib, value; int i; -config = malloc(sizeof *config); +config = calloc(1, sizeof *config); config-driConfig = driConfig; -- 1.9.0 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PULL] non-glamor build fix
I've got a few other patches with review on the list currently, but I want to give a little more time for anyone that cares to respond. A build fix seems important enough that we should shove it in now, though. The following changes since commit 78e508c9379b3976ac8e76b7aaa90ba86ad4e443: dix: Clear any existing selections before initializing privates (2014-03-06 17:15:11 -0800) are available in the git repository at: git://people.freedesktop.org/~anholt/xserver glamor-pull-request for you to fetch changes up to 5350ae1d38f3c69a26421e0866ede0d2ccc3aea4: Fix xephyr build in --disable-glamor case (2014-03-07 12:43:52 -0800) Jon TURNEY (1): Fix xephyr build in --disable-glamor case hw/kdrive/ephyr/hostx.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) pgpWseM6VsnVQ.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 1/6] xephyr: Build support for rendering with glamor using a -glamor option.
Jon TURNEY jon.tur...@dronecode.org.uk writes: On 25/02/2014 01:47, Eric Anholt wrote: v2: Avoid making the Ximage for the screen that we'll never use, and drive the screen pixmap creation for glamor ourselves. Signed-off-by: Eric Anholt e...@anholt.net Reviewed-by: Keith Packard kei...@keithp.com (v1) It seems this needs some more #ifdef GLAMOR/#endif guards to compile successfully when ./configured --disable-glamor See http://tinderbox.x.org/builds/2014-03-07-0004/logs/xserver/#build Sent out a pull request for the reviewed change. The ifdeffing is kind of ugly, but I'm already guilty of a bunch of that in this code. I like the idea of static inline stubs for compiled-out code, but it's only partially done in ephyr_glamor_glx.h so far. We can leave that as a cleanup for later. It would be nice to have a cleaner version of the static inline thing than what I've done currently. Not sure if preprocessor macros could be used to make doing that more sane, or less. pgp3Vr_8NY66t.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 8/9] glamor: Fix requested composite VBO size.
The argument to setup_composte_vbo is the number of verts.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_render.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index 7829977..63bddfd 100644
--- a/glamor/glamor_render.c
+++ b/glamor/glamor_render.c
@@ -1253,8 +1253,7 @@ glamor_composite_with_shader(CARD8 op,
vert_stride += 4;
}
-nrect_max = (vert_stride * nrect) GLAMOR_COMPOSITE_VBO_VERT_CNT ?
-(GLAMOR_COMPOSITE_VBO_VERT_CNT / vert_stride) : nrect;
+nrect_max = MIN(nrect, GLAMOR_COMPOSITE_VBO_VERT_CNT / 4);
while (nrect) {
int mrect, rect_processed;
@@ -1262,7 +1261,7 @@ glamor_composite_with_shader(CARD8 op,
float *vertices;
mrect = nrect nrect_max ? nrect_max : nrect;
-vertices = glamor_setup_composite_vbo(screen, mrect * vert_stride);
+vertices = glamor_setup_composite_vbo(screen, mrect * 4);
rect_processed = mrect;
vb_stride = glamor_priv-vb_stride / sizeof(float);
while (mrect--) {
--
1.9.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 5/9] glamor: Track the next vertex offset as we go for non-AA traps.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_trapezoid.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/glamor/glamor_trapezoid.c b/glamor/glamor_trapezoid.c
index 7bbee4b..a774c37 100644
--- a/glamor/glamor_trapezoid.c
+++ b/glamor/glamor_trapezoid.c
@@ -191,14 +191,16 @@ point_inside_trapezoid(int point[2], xTrapezoid *trap,
xFixed cut_y)
static void
glamor_emit_composite_vert(ScreenPtr screen,
+ float *vb,
const float *src_coords,
const float *mask_coords,
const float *dst_coords, int i)
{
glamor_screen_private *glamor_priv = glamor_get_screen_private(screen);
-float *vb = (float *) (glamor_priv-vb + glamor_priv-vbo_offset);
int j = 0;
+vb += i * glamor_priv-vb_stride / 4;
+
vb[j++] = dst_coords[i * 2 + 0];
vb[j++] = dst_coords[i * 2 + 1];
if (glamor_priv-has_source_coords) {
@@ -216,13 +218,17 @@ glamor_emit_composite_vert(ScreenPtr screen,
static void
glamor_emit_composite_triangle(ScreenPtr screen,
+ float *vb,
const float *src_coords,
const float *mask_coords,
const float *dst_coords)
{
-glamor_emit_composite_vert(screen, src_coords, mask_coords, dst_coords, 0);
-glamor_emit_composite_vert(screen, src_coords, mask_coords, dst_coords, 1);
-glamor_emit_composite_vert(screen, src_coords, mask_coords, dst_coords, 2);
+glamor_emit_composite_vert(screen, vb,
+ src_coords, mask_coords, dst_coords, 0);
+glamor_emit_composite_vert(screen, vb,
+ src_coords, mask_coords, dst_coords, 1);
+glamor_emit_composite_vert(screen, vb,
+ src_coords, mask_coords, dst_coords, 2);
}
static void
@@ -887,6 +893,8 @@ _glamor_trapezoids_with_shader(CARD8 op,
nclip_rect = nbox;
while (nclip_rect) {
+float *vb;
+
mclip_rect = (nclip_rect * ntrap * 4) ntriangle_per_loop ?
(ntriangle_per_loop / (4 * ntrap)) : nclip_rect;
@@ -904,8 +912,9 @@ _glamor_trapezoids_with_shader(CARD8 op,
NTRAPS_LOOP_AGAIN:
-glamor_setup_composite_vbo(screen,
- mclip_rect * traps_count * 4 * vert_stride);
+vb = glamor_setup_composite_vbo(screen,
+(mclip_rect * traps_count *
+ 4 * vert_stride));
clip_processed = mclip_rect;
while (mclip_rect--) {
@@ -963,8 +972,10 @@ _glamor_trapezoids_with_shader(CARD8 op,
source_texcoords[4], source_texcoords[5]);
}
-glamor_emit_composite_triangle(screen,
source_texcoords,
+glamor_emit_composite_triangle(screen, vb,
+ source_texcoords,
NULL, vertices);
+vb += 3 * glamor_priv-vb_stride / 4;
}
}
--
1.9.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 9/9] glamor: Use buffer_storage
v2:
- Make the default buffer size a #define. (by Markus Wick)
- Fix the return offset for mapping with buffer_storage. (oops!)
v3:
- Avoid GL error at first rendering from unmapping no buffer.
- Rebase on the glBindBuffer(GL_ARRAY_BUFFER, 0) change.
v4: Rebase on Markus's vbo init changes.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor.c | 2 ++
glamor/glamor_priv.h | 1 +
glamor/glamor_vbo.c | 51 +--
3 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/glamor/glamor.c b/glamor/glamor.c
index dc69c72..e856179 100644
--- a/glamor/glamor.c
+++ b/glamor/glamor.c
@@ -353,6 +353,8 @@ glamor_init(ScreenPtr screen, unsigned int flags)
glamor_gl_has_extension(GL_MESA_pack_invert);
glamor_priv-has_fbo_blit =
glamor_gl_has_extension(GL_EXT_framebuffer_blit);
+glamor_priv-has_buffer_storage =
+glamor_gl_has_extension(GL_ARB_buffer_storage);
glGetIntegerv(GL_MAX_RENDERBUFFER_SIZE, glamor_priv-max_fbo_size);
#ifdef MAX_FBO_SIZE
glamor_priv-max_fbo_size = MAX_FBO_SIZE;
diff --git a/glamor/glamor_priv.h b/glamor/glamor_priv.h
index 986e729..d15eabd 100644
--- a/glamor/glamor_priv.h
+++ b/glamor/glamor_priv.h
@@ -208,6 +208,7 @@ typedef struct glamor_screen_private {
enum glamor_gl_flavor gl_flavor;
int has_pack_invert;
int has_fbo_blit;
+int has_buffer_storage;
int max_fbo_size;
struct xorg_list
diff --git a/glamor/glamor_vbo.c b/glamor/glamor_vbo.c
index be2c2af..f736cbe 100644
--- a/glamor/glamor_vbo.c
+++ b/glamor/glamor_vbo.c
@@ -52,7 +52,49 @@ glamor_get_vbo_space(ScreenPtr screen, unsigned size, char
**vbo_offset)
glBindBuffer(GL_ARRAY_BUFFER, glamor_priv-vbo);
-if (glamor_priv-gl_flavor == GLAMOR_GL_DESKTOP) {
+if (glamor_priv-has_buffer_storage) {
+if (glamor_priv-vbo_size glamor_priv-vbo_offset + size) {
+if (glamor_priv-vbo_size)
+glUnmapBuffer(GL_ARRAY_BUFFER);
+
+if (size glamor_priv-vbo_size) {
+glamor_priv-vbo_size = MAX(GLAMOR_VBO_SIZE, size);
+
+/* We aren't allowed to resize glBufferStorage()
+ * buffers, so we need to gen a new one.
+ */
+glDeleteBuffers(1, glamor_priv-vbo);
+glGenBuffers(1, glamor_priv-vbo);
+glBindBuffer(GL_ARRAY_BUFFER, glamor_priv-vbo);
+
+assert(glGetError() == GL_NO_ERROR);
+glBufferStorage(GL_ARRAY_BUFFER, glamor_priv-vbo_size, NULL,
+GL_MAP_WRITE_BIT |
+GL_MAP_PERSISTENT_BIT |
+GL_MAP_COHERENT_BIT);
+
+if (glGetError() != GL_NO_ERROR) {
+/* If the driver failed our coherent mapping, fall
+ * back to the ARB_mbr path.
+ */
+glamor_priv-has_buffer_storage = false;
+glamor_priv-vbo_size = 0;
+return glamor_get_vbo_space(screen, size, vbo_offset);
+}
+}
+
+glamor_priv-vbo_offset = 0;
+glamor_priv-vb = glMapBufferRange(GL_ARRAY_BUFFER,
+ 0, glamor_priv-vbo_size,
+ GL_MAP_WRITE_BIT |
+ GL_MAP_INVALIDATE_BUFFER_BIT |
+ GL_MAP_PERSISTENT_BIT |
+ GL_MAP_COHERENT_BIT);
+}
+*vbo_offset = (void *)(uintptr_t)glamor_priv-vbo_offset;
+data = glamor_priv-vb + glamor_priv-vbo_offset;
+glamor_priv-vbo_offset += size;
+} else if (glamor_priv-gl_flavor == GLAMOR_GL_DESKTOP) {
if (glamor_priv-vbo_size glamor_priv-vbo_offset + size) {
glamor_priv-vbo_size = MAX(GLAMOR_VBO_SIZE, size);
glamor_priv-vbo_offset = 0;
@@ -99,7 +141,12 @@ glamor_put_vbo_space(ScreenPtr screen)
glamor_get_context(glamor_priv);
-if (glamor_priv-gl_flavor == GLAMOR_GL_DESKTOP) {
+if (glamor_priv-has_buffer_storage) {
+/* If we're in the ARB_buffer_storage path, we have a
+ * persistent mapping, so we can leave it around until we
+ * reach the end of the buffer.
+ */
+} else if (glamor_priv-gl_flavor == GLAMOR_GL_DESKTOP) {
glUnmapBuffer(GL_ARRAY_BUFFER);
} else {
glBufferData(GL_ARRAY_BUFFER, glamor_priv-vbo_offset,
--
1.9.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 1/9] glamor: Drop the set of the context to NULL at the end of glamor ops.
The theory here was that it (which I copied from EGL) existed to fix
up context switching with indirect GLX. But indirect GLX won't even
try to set the context again unless its lastContext field is cleared,
so we need to solve this a different way.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_glx.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/glamor/glamor_glx.c b/glamor/glamor_glx.c
index 311bf75..8f47c3d 100644
--- a/glamor/glamor_glx.c
+++ b/glamor/glamor_glx.c
@@ -53,13 +53,7 @@ glamor_glx_get_context(struct glamor_context *glamor_ctx)
static void
glamor_glx_put_context(struct glamor_context *glamor_ctx)
{
-if (--glamor_ctx-get_count)
-return;
-
-/* We actually reset the context, so that indirect GLX's EGL usage
- * won't get confused by ours.
- */
-glXMakeCurrent(glamor_ctx-display, None, NULL);
+--glamor_ctx-get_count;
}
Bool
--
1.9.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 2/9] glamor: Don't forget to set GL_INVALIDATE_RANGE_BIT on GL_ARB_mbr.
We don't need any current contents of the buffer, and this allows an implementation to make a temporary BO for a streamed upload if it wants to. Signed-off-by: Eric Anholt e...@anholt.net --- glamor/glamor_render.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c index f8d103d..98343c3 100644 --- a/glamor/glamor_render.c +++ b/glamor/glamor_render.c @@ -731,7 +731,8 @@ glamor_setup_composite_vbo(ScreenPtr screen, int n_verts) glamor_priv-vbo_offset, vert_size, GL_MAP_WRITE_BIT | - GL_MAP_UNSYNCHRONIZED_BIT); + GL_MAP_UNSYNCHRONIZED_BIT | + GL_MAP_INVALIDATE_RANGE_BIT); assert(glamor_priv-vb != NULL); glamor_priv-vb -= glamor_priv-vbo_offset; } -- 1.9.0 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 6/9] glamor: Track the next vertex offset as we go for AA traps.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_trapezoid.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/glamor/glamor_trapezoid.c b/glamor/glamor_trapezoid.c
index a774c37..4d2360d 100644
--- a/glamor/glamor_trapezoid.c
+++ b/glamor/glamor_trapezoid.c
@@ -607,7 +607,7 @@ _glamor_clip_trapezoid_vertex(xTrapezoid *trap, BoxPtr pbox,
return TRUE;
}
-static void
+static void *
glamor_setup_composite_vbo_for_trapezoid(ScreenPtr screen, int n_verts)
{
glamor_screen_private *glamor_priv = glamor_get_screen_private(screen);
@@ -701,6 +701,8 @@ glamor_setup_composite_vbo_for_trapezoid(ScreenPtr screen,
int n_verts)
glEnableVertexAttribArray(GLAMOR_VERTEX_RIGHT_PARAM);
glamor_put_context(glamor_priv);
+
+return glamor_priv-vb + glamor_priv-vbo_offset;
}
static Bool
@@ -1420,7 +1422,6 @@ _glamor_generate_trapezoid_with_shader(ScreenPtr screen,
PicturePtr picture,
BoxRec one_trap_bound;
int nrect_max;
int i, j;
-float *vertices;
float params[4];
glamor_priv = glamor_get_screen_private(screen);
@@ -1461,11 +1462,12 @@ _glamor_generate_trapezoid_with_shader(ScreenPtr
screen, PicturePtr picture,
nrect_max = GLAMOR_COMPOSITE_VBO_VERT_CNT / (4 *
GLAMOR_VERTEX_RIGHT_PARAM);
for (i = 0; i ntrap;) {
+float *vertices;
int mrect;
int stride;
mrect = (ntrap - i) nrect_max ? nrect_max : (ntrap - i);
-glamor_setup_composite_vbo_for_trapezoid(screen, 4 * mrect);
+vertices = glamor_setup_composite_vbo_for_trapezoid(screen, 4 * mrect);
stride = glamor_priv-vb_stride / sizeof(float);
for (j = 0; j mrect; j++) {
@@ -1488,8 +1490,7 @@ _glamor_generate_trapezoid_with_shader(ScreenPtr screen,
PicturePtr picture,
miTrapezoidBounds(1, ptrap, one_trap_bound);
-vertices =
-(float *) (glamor_priv-vb + glamor_priv-vbo_offset) + 2;
+vertices += 2;
glamor_set_tcoords_ext((pixmap_priv-base.pixmap-drawable.width),
(pixmap_priv-base.pixmap-drawable.height),
(one_trap_bound.x1), (one_trap_bound.y1),
@@ -1561,6 +1562,7 @@ _glamor_generate_trapezoid_with_shader(ScreenPtr screen,
PicturePtr picture,
}
params[2] = right_slope;
glamor_set_const_ext(params, 4, vertices, 4, stride);
+vertices += 4;
DEBUGF(trap_top = %f, trap_bottom = %f,
trap_left_x = %f, trap_left_y = %f, left_slope = %f,
@@ -1574,6 +1576,8 @@ _glamor_generate_trapezoid_with_shader(ScreenPtr screen,
PicturePtr picture,
glamor_priv-render_nr_verts += 4;
glamor_priv-vbo_offset += glamor_priv-vb_stride * 4;
+
+vertices += 3 * stride;
}
i += mrect;
--
1.9.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 7/9] glamor: Extract the streamed vertex data code used by Render.
We should be uploading any vertex data using this kind of upload
style, since it saves a bunch of extra copies of our vertex data.
v2:
- Add a simple comment about what the function does.
- Use get_vbo_space()'s return in trapezoids, instead of dereffing
glamor_priv-vb (by Markus Wick).
- Fix the double-unmapping by moving put_vbo_space() outside of
flush_composite_rects().
- Remove the rest of the composite_vbo_offset usage, and just always
use get_vbo_space()'s return value.
v3:
- Fix failure to put_vbo_space in traps when no prims were
generated.
- Unbind the VBO from put_vbo_space(). Keeps callers from
forgetting to do so.
v4:
- Split out some changes into the previous 3 commits while trying to
track down a regression.
- Fix regression due to rebase fail where glamor_priv-vbo_offset
wasn't incremented.
v5:
- Fix GLES2 VBO sizing.
- Add a comment about resize behavior.
- Move glamor_vbo.c init code to glamor_vbo.c from
glamor_render.c. (Derived from Markus's changes, but the GLES2 fix
dropped almost all of the code in the functions).
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/Makefile.am| 1 +
glamor/glamor.c | 2 +
glamor/glamor.h | 1 +
glamor/glamor_priv.h | 18 ++
glamor/glamor_render.c| 66 +++---
glamor/glamor_trapezoid.c | 72 +---
glamor/glamor_vbo.c | 138 ++
7 files changed, 184 insertions(+), 114 deletions(-)
create mode 100644 glamor/glamor_vbo.c
diff --git a/glamor/Makefile.am b/glamor/Makefile.am
index 77492bc..ffc8c23 100644
--- a/glamor/Makefile.am
+++ b/glamor/Makefile.am
@@ -34,6 +34,7 @@ libglamor_la_SOURCES = \
glamor_pixmap.c\
glamor_largepixmap.c\
glamor_picture.c\
+ glamor_vbo.c \
glamor_window.c\
glamor_fbo.c\
glamor_compositerects.c\
diff --git a/glamor/glamor.c b/glamor/glamor.c
index fe9f761..dc69c72 100644
--- a/glamor/glamor.c
+++ b/glamor/glamor.c
@@ -439,6 +439,7 @@ glamor_init(ScreenPtr screen, unsigned int flags)
ps-DestroyPicture = glamor_destroy_picture;
glamor_init_composite_shaders(screen);
#endif
+glamor_init_vbo(screen);
glamor_init_pixmap_fbo(screen);
glamor_init_solid_shader(screen);
glamor_init_tile_shader(screen);
@@ -478,6 +479,7 @@ glamor_release_screen_priv(ScreenPtr screen)
#ifdef RENDER
glamor_fini_composite_shaders(screen);
#endif
+glamor_fini_vbo(screen);
glamor_fini_pixmap_fbo(screen);
glamor_fini_solid_shader(screen);
glamor_fini_tile_shader(screen);
diff --git a/glamor/glamor.h b/glamor/glamor.h
index e12f497..e25dc73 100644
--- a/glamor/glamor.h
+++ b/glamor/glamor.h
@@ -324,6 +324,7 @@ extern _X_EXPORT int glamor_create_gc(GCPtr gc);
extern _X_EXPORT void glamor_validate_gc(GCPtr gc, unsigned long changes,
DrawablePtr drawable);
+
/* Glamor rendering/drawing functions with XXX_nf.
* nf means no fallback within glamor internal if possible. If glamor
* fail to accelerate the operation, glamor will return a false, and the
diff --git a/glamor/glamor_priv.h b/glamor/glamor_priv.h
index b23c12b..986e729 100644
--- a/glamor/glamor_priv.h
+++ b/glamor/glamor_priv.h
@@ -220,8 +220,15 @@ typedef struct glamor_screen_private {
/* vertext/elment_index buffer object for render */
GLuint vbo, ebo;
+/** Next offset within the VBO that glamor_get_vbo_space() will use. */
int vbo_offset;
int vbo_size;
+/**
+ * Pointer to glamor_get_vbo_space()'s current VBO mapping.
+ *
+ * Note that this is not necessarily equal to the pointer returned
+ * by glamor_get_vbo_space(), so it can't be used in place of that.
+ */
char *vb;
int vb_stride;
Bool has_source_coords, has_mask_coords;
@@ -744,6 +751,17 @@ void glamor_triangles(CARD8 op,
void glamor_pixmap_init(ScreenPtr screen);
void glamor_pixmap_fini(ScreenPtr screen);
+/* glamor_vbo.c */
+
+void glamor_init_vbo(ScreenPtr screen);
+void glamor_fini_vbo(ScreenPtr screen);
+
+void *
+glamor_get_vbo_space(ScreenPtr screen, unsigned size, char **vbo_offset);
+
+void
+glamor_put_vbo_space(ScreenPtr screen);
+
/**
* Download a pixmap's texture to cpu memory. If success,
* One copy of current pixmap's texture will be put into
diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index 69a22d9..7829977 100644
--- a/glamor/glamor_render.c
+++ b/glamor/glamor_render.c
@@ -403,12 +403,10 @@ glamor_init_composite_shaders(ScreenPtr screen)
{
glamor_screen_private *glamor_priv;
unsigned short *eb;
-float *vb = NULL;
int eb_size;
glamor_priv = glamor_get_screen_private(screen);
glamor_get_context(glamor_priv);
-glGenBuffers(1, glamor_priv-vbo);
glGenBuffers(1, glamor_priv-ebo);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, glamor_priv-ebo);
@@ -419,9
Re: [PATCH 5/9] glamor: Track the next vertex offset as we go for non-AA traps.
Keith Packard kei...@keithp.com writes: Markus Wick mar...@selfnet.de writes: Am 2014-03-09 05:07, schrieb Eric Anholt: +vb += i * glamor_priv-vb_stride / 4; This should be / sizeof(float) instead. presumably GLfloat? We've been pretty good about not using the ugly GL types so far. pgp8hQjHeUZZA.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 9/9] glamor: Use buffer_storage
Markus Wick mar...@selfnet.de writes:
Am 2014-03-09 05:07, schrieb Eric Anholt:
diff --git a/glamor/glamor_vbo.c b/glamor/glamor_vbo.c
index be2c2af..f736cbe 100644
--- a/glamor/glamor_vbo.c
+++ b/glamor/glamor_vbo.c
@@ -52,7 +52,49 @@ glamor_get_vbo_space(ScreenPtr screen, unsigned
size, char **vbo_offset)
glBindBuffer(GL_ARRAY_BUFFER, glamor_priv-vbo);
-if (glamor_priv-gl_flavor == GLAMOR_GL_DESKTOP) {
+if (glamor_priv-has_buffer_storage) {
+if (glamor_priv-vbo_size glamor_priv-vbo_offset + size) {
+if (glamor_priv-vbo_size)
+glUnmapBuffer(GL_ARRAY_BUFFER);
+
+if (size glamor_priv-vbo_size) {
+glamor_priv-vbo_size = MAX(GLAMOR_VBO_SIZE, size);
+
+/* We aren't allowed to resize glBufferStorage()
+ * buffers, so we need to gen a new one.
+ */
+glDeleteBuffers(1, glamor_priv-vbo);
+glGenBuffers(1, glamor_priv-vbo);
+glBindBuffer(GL_ARRAY_BUFFER, glamor_priv-vbo);
+
+assert(glGetError() == GL_NO_ERROR);
On release builds, glGetError won't be called and so this won't clear
the gl error log. So we'll fall back to the mbr code because of any gl
error somewhere in glamor.
Yeah, I think that's fine -- you shouldn't have any errors, anyway.
+glBufferStorage(GL_ARRAY_BUFFER,
glamor_priv-vbo_size, NULL,
+GL_MAP_WRITE_BIT |
+GL_MAP_PERSISTENT_BIT |
+GL_MAP_COHERENT_BIT);
+
+if (glGetError() != GL_NO_ERROR) {
+/* If the driver failed our coherent mapping, fall
+ * back to the ARB_mbr path.
+ */
+glamor_priv-has_buffer_storage = false;
+glamor_priv-vbo_size = 0;
glamor_put_context(glamor_priv);
Fixed.
Which kind of error do you expect for a driver which isn't able to map
coherent? I've only found a GL_OUT_OF_MEMORY, but this will invalidate
the complete gl state. So I guess there is no legal way to support
arb_buffer_storage without coherent mapping at all.
I wonder if the caller is supposed to expect GL_OOM from this path and
assume that the context isn't totally trashed like the general GL_OOM
case.
So far, it looks like we're going to just always support COHERENT in
Mesa.
pgp0yIZm78Y0J.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PULL] glamor cleanups and VBO changes (and glx fix)
keithp said he was comfortable with the level of review on these, so here goes. I dropped the two changes from the two series that didn't get review comments: glViewport() in ephyr, and dropping glXMakeCurrent(None). The following changes since commit 7f15e5aed79803fa6057fbfda7dfbacacc2e019d: Require video drivers to report that they support server managed fds (2014-03-10 09:08:46 +0100) are available in the git repository at: git://people.freedesktop.org/~anholt/xserver glamor-pull-request for you to fetch changes up to 6e5ea5487738cbca9d585d24e66eb65b93ad579c: glx: Clear new FBConfig attributes to 0 by default. (2014-03-10 13:31:14 -0700) Eric Anholt (14): glamor: remove dead global variable. glamor: Fix a spelling mistake in GLAMOR_PIXMAP_FBO_NOT_EXACT_SIZE. glamor: Add a note about the state of GL_ARB_map_buffer_range. dix: Remove incorrect comment about privates. glamor: Fix a mismatched glamor_get/put_context(). glamor: Don't forget to set GL_INVALIDATE_RANGE_BIT on GL_ARB_mbr. glamor: Move glamor_emit_composite_vert() to traps, where it's used. glamor: Track the next vertex offset as we go in render accel. glamor: Track the next vertex offset as we go for non-AA traps. glamor: Track the next vertex offset as we go for AA traps. glamor: Extract the streamed vertex data code used by Render. glamor: Fix requested composite VBO size. glamor: Use buffer_storage glx: Clear new FBConfig attributes to 0 by default. dix/privates.c| 9 +-- glamor/Makefile.am| 1 + glamor/glamor.c | 17 + glamor/glamor.h | 1 + glamor/glamor_gradient.c | 5 -- glamor/glamor_pixmap.c| 3 +- glamor/glamor_priv.h | 25 +-- glamor/glamor_render.c| 108 +-- glamor/glamor_trapezoid.c | 128 --- glamor/glamor_utils.h | 2 +- glamor/glamor_vbo.c | 186 ++ glx/glxdricommon.c| 2 +- 12 files changed, 314 insertions(+), 173 deletions(-) create mode 100644 glamor/glamor_vbo.c pgpPDOBx3qzSe.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 7/9] glamor: Extract the streamed vertex data code used by Render.
Markus Wick mar...@selfnet.de writes:
Am 2014-03-09 05:07, schrieb Eric Anholt:
diff --git a/glamor/glamor_vbo.c b/glamor/glamor_vbo.c
new file mode 100644
index 000..be2c2af
--- /dev/null
+++ b/glamor/glamor_vbo.c
@@ -0,0 +1,138 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person
obtaining a
+ * copy of this software and associated documentation files (the
Software),
+ * to deal in the Software without restriction, including without
limitation
+ * the rights to use, copy, modify, merge, publish, distribute,
sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom
the
+ * Software is furnished to do so, subject to the following
conditions:
+ *
+ * The above copyright notice and this permission notice (including
the next
+ * paragraph) shall be included in all copies or substantial portions
of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES
OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+/**
+ * @file glamor_vbo.c
+ *
+ * Helpers for managing streamed vertex bufffers used in glamor.
+ */
+
+#include glamor_priv.h
+
+/** Default size of the VBO, in bytes.
+ *
+ * If a single request is larger than this size, we'll resize the VBO
+ * and return an appropriate mapping, but we'll resize back down after
+ * that to avoid hogging that memory forever. We don't anticipate
+ * normal usage actually requiring larger VBO sizes.
+ */
+#define GLAMOR_VBO_SIZE (64 * 1024)
This is a bit too small imo. iirc glamor was used to split up renderings
to 64k vertices, not 64k bytes.
What is the cache implact on too big buffers? i965 must fall through to
LLC, so will it pollute the L1+L2 caches?
For non-coherent gpus, write combining also shouldn't pollute any
caches.
64k seems like plenty, but against a non-bufferstorage Mesa, 512k did
give 1.6% improvement, so I swapped to your value.
+
+/**
+ * Returns a pointer to @size bytes of VBO storage, which should be
+ * accessed by the GL using vbo_offset within the VBO.
+ */
+void *
+glamor_get_vbo_space(ScreenPtr screen, unsigned size, char
**vbo_offset)
+{
+glamor_screen_private *glamor_priv =
glamor_get_screen_private(screen);
+void *data;
+
+glamor_get_context(glamor_priv);
+
+glBindBuffer(GL_ARRAY_BUFFER, glamor_priv-vbo);
+
+if (glamor_priv-gl_flavor == GLAMOR_GL_DESKTOP) {
+if (glamor_priv-vbo_size glamor_priv-vbo_offset + size) {
+glamor_priv-vbo_size = MAX(GLAMOR_VBO_SIZE, size);
+glamor_priv-vbo_offset = 0;
+glBufferData(GL_ARRAY_BUFFER,
+ glamor_priv-vbo_size, NULL, GL_STREAM_DRAW);
+}
+
+data = glMapBufferRange(GL_ARRAY_BUFFER,
+glamor_priv-vbo_offset,
+size,
+GL_MAP_WRITE_BIT |
+GL_MAP_UNSYNCHRONIZED_BIT |
+GL_MAP_INVALIDATE_RANGE_BIT);
+assert(data != NULL);
+*vbo_offset = (void *)(uintptr_t)glamor_priv-vbo_offset;
(char *) instead of (void *).
Changed.
+glamor_priv-vbo_offset += size;
+} else {
+/* Return a pointer to the statically allocated non-VBO
+ * memory. We'll upload it through glBufferData() later.
+ */
+if (glamor_priv-vbo_size size) {
+glamor_priv-vbo_size = MAX(GLAMOR_VBO_SIZE, size);
+
+glBufferData(GL_ARRAY_BUFFER,
+ glamor_priv-vbo_size, NULL, GL_STREAM_DRAW);
Is this call needed at all? As we upload by glBufferData, we will alloc
the buffer then.
Nope, you're right.
+
+free(glamor_priv-vb);
+glamor_priv-vb = XNFalloc(size);
+}
+*vbo_offset = NULL;
+glamor_priv-vbo_offset = 0;
This variable is used for the size on uploading. So it must be set to
size.
Good catch. Fixed (and commented).
+void
+glamor_put_vbo_space(ScreenPtr screen)
+{
+glamor_screen_private *glamor_priv =
glamor_get_screen_private(screen);
+
+glamor_get_context(glamor_priv);
+
+if (glamor_priv-gl_flavor == GLAMOR_GL_DESKTOP) {
+glUnmapBuffer(GL_ARRAY_BUFFER);
+} else {
+glBufferData(GL_ARRAY_BUFFER, glamor_priv-vbo_offset,
+ glamor_priv-vb, GL_DYNAMIC_DRAW);
+}
+
+glBindBuffer(GL_ARRAY_BUFFER, 0);
+
+glamor_put_context(glamor_priv
Re: [PULL] glamor cleanups and VBO changes (and glx fix)
Eric Anholt e...@anholt.net writes: keithp said he was comfortable with the level of review on these, so here goes. I dropped the two changes from the two series that didn't get review comments: glViewport() in ephyr, and dropping glXMakeCurrent(None). The following changes since commit 7f15e5aed79803fa6057fbfda7dfbacacc2e019d: Require video drivers to report that they support server managed fds (2014-03-10 09:08:46 +0100) are available in the git repository at: git://people.freedesktop.org/~anholt/xserver glamor-pull-request for you to fetch changes up to 6e5ea5487738cbca9d585d24e66eb65b93ad579c: keithp pointed out that he had a problem with the dix comment change, which I'd missed in processing review. I've updated to drop the commit, with a new sha1 for the pull of 96a28e9c914d7ae9b269f73a27b99cbd3c465ac8. pgpibKNcA07gm.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 04/27] glamor: Move the EGL image to the normal pixmap private.
There's no reason to hide EGL from the rest of glamor, now that we
have epoxy.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_egl.c | 89 +++-
glamor/glamor_priv.h | 7 +
2 files changed, 47 insertions(+), 49 deletions(-)
diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
index 13799fc..f24cb28 100644
--- a/glamor/glamor_egl.c
+++ b/glamor/glamor_egl.c
@@ -54,10 +54,6 @@
static const char glamor_name[] = glamor;
-static DevPrivateKeyRec glamor_egl_pixmap_private_key_index;
-DevPrivateKey glamor_egl_pixmap_private_key =
-glamor_egl_pixmap_private_key_index;
-
static void
glamor_identify(int flags)
{
@@ -228,11 +224,13 @@ Bool
glamor_egl_create_textured_screen(ScreenPtr screen, int handle, int stride)
{
ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
+struct glamor_pixmap_private *pixmap_priv;
struct glamor_egl_screen_private *glamor_egl;
PixmapPtr screen_pixmap;
glamor_egl = glamor_egl_get_screen_private(scrn);
screen_pixmap = screen-GetScreenPixmap(screen);
+pixmap_priv = glamor_get_pixmap_private(screen_pixmap);
if (!glamor_egl_create_textured_pixmap(screen_pixmap, handle, stride)) {
xf86DrvMsg(scrn-scrnIndex, X_ERROR,
@@ -240,8 +238,7 @@ glamor_egl_create_textured_screen(ScreenPtr screen, int
handle, int stride)
return FALSE;
}
-glamor_egl-front_image = dixLookupPrivate(screen_pixmap-devPrivates,
- glamor_egl_pixmap_private_key);
+glamor_egl-front_image = pixmap_priv-base.image;
glamor_set_screen_pixmap(screen_pixmap, glamor_egl-back_pixmap);
return TRUE;
}
@@ -282,6 +279,8 @@ glamor_egl_create_textured_pixmap(PixmapPtr pixmap, int
handle, int stride)
ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
struct glamor_screen_private *glamor_priv =
glamor_get_screen_private(screen);
+struct glamor_pixmap_private *pixmap_priv =
+glamor_get_pixmap_private(pixmap);
struct glamor_egl_screen_private *glamor_egl;
EGLImageKHR image;
GLuint texture;
@@ -316,7 +315,7 @@ glamor_egl_create_textured_pixmap(PixmapPtr pixmap, int
handle, int stride)
glamor_create_texture_from_image(glamor_egl, image, texture);
glamor_set_pixmap_type(pixmap, GLAMOR_TEXTURE_DRM);
glamor_set_pixmap_texture(pixmap, texture);
-dixSetPrivate(pixmap-devPrivates, glamor_egl_pixmap_private_key, image);
+pixmap_priv-base.image = image;
ret = TRUE;
done:
@@ -331,6 +330,8 @@ glamor_egl_create_textured_pixmap_from_gbm_bo(PixmapPtr
pixmap, void *bo)
ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
struct glamor_screen_private *glamor_priv =
glamor_get_screen_private(screen);
+struct glamor_pixmap_private *pixmap_priv =
+glamor_get_pixmap_private(pixmap);
struct glamor_egl_screen_private *glamor_egl;
EGLImageKHR image;
GLuint texture;
@@ -350,7 +351,7 @@ glamor_egl_create_textured_pixmap_from_gbm_bo(PixmapPtr
pixmap, void *bo)
glamor_create_texture_from_image(glamor_egl, image, texture);
glamor_set_pixmap_type(pixmap, GLAMOR_TEXTURE_DRM);
glamor_set_pixmap_texture(pixmap, texture);
-dixSetPrivate(pixmap-devPrivates, glamor_egl_pixmap_private_key, image);
+pixmap_priv-base.image = image;
ret = TRUE;
done:
@@ -395,6 +396,8 @@ glamor_egl_dri3_fd_name_from_tex(ScreenPtr screen,
{
#ifdef GLAMOR_HAS_GBM
ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
+struct glamor_pixmap_private *pixmap_priv =
+glamor_get_pixmap_private(pixmap);
struct glamor_screen_private *glamor_priv =
glamor_get_screen_private(screen);
struct glamor_egl_screen_private *glamor_egl;
@@ -412,10 +415,8 @@ glamor_egl_dri3_fd_name_from_tex(ScreenPtr screen,
glamor_get_context(glamor_priv);
-image = dixLookupPrivate(pixmap-devPrivates,
- glamor_egl_pixmap_private_key);
-
-if (image == EGL_NO_IMAGE_KHR || image == NULL) {
+image = pixmap_priv-base.image;
+if (!image) {
image = eglCreateImageKHR(glamor_egl-display,
glamor_egl-context,
EGL_GL_TEXTURE_2D_KHR,
@@ -424,8 +425,7 @@ glamor_egl_dri3_fd_name_from_tex(ScreenPtr screen,
if (image == EGL_NO_IMAGE_KHR)
goto failure;
-dixSetPrivate(pixmap-devPrivates,
- glamor_egl_pixmap_private_key, image);
+pixmap_priv-base.image = image;
glamor_set_pixmap_type(pixmap, GLAMOR_TEXTURE_DRM);
}
@@ -530,20 +530,18 @@ static void
_glamor_egl_destroy_pixmap_image(PixmapPtr pixmap)
{
ScrnInfoPtr scrn = xf86ScreenToScrn(pixmap-drawable.pScreen);
-EGLImageKHR image;
struct glamor_egl_screen_private *glamor_egl =
glamor_egl_get_screen_private(scrn);
+struct glamor_pixmap_private *pixmap_priv =
+glamor_get_pixmap_private(pixmap
glamor-server subset patch bomb
keithp said he was tired of the glamor stuff trickling in and wanted to just review it all at once and be done. I know I hate reviewing giant patch series, but who am I to argue with someone who says they want to do more review? This series fixes a bunch of CopyPlane XTS tests in Xephyr, thanks to the GC prepare fixes if I remember right. There are a few patches that used to be in glamor-server that I dropped. Some were performance ideas that didn't produce measurable results (yet -- in one case, it's that I think I misplaced a spans patch I used to have, which was a prereq for another change being useful). Others just regressed things. So, if you've got your own glamor branches based off of my glamor-server, be careful not to carry that junk around. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 06/27] sync: Add a header include necessary to use misyncstr.h
Signed-off-by: Eric Anholt e...@anholt.net --- miext/sync/misyncstr.h | 1 + 1 file changed, 1 insertion(+) diff --git a/miext/sync/misyncstr.h b/miext/sync/misyncstr.h index b5bf6fd..ad69e8e 100644 --- a/miext/sync/misyncstr.h +++ b/miext/sync/misyncstr.h @@ -29,6 +29,7 @@ #define _MISYNCSTR_H_ #include dix.h +#include misync.h #include scrnintstr.h #include X11/extensions/syncconst.h -- 1.9.0 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 09/27] glamor: Drop duplicated lines for getting pixmap state in GetImage.
No change in generated code size -- apparently the compiler figured it
out.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_getimage.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/glamor/glamor_getimage.c b/glamor/glamor_getimage.c
index 5609e70..a932473 100644
--- a/glamor/glamor_getimage.c
+++ b/glamor/glamor_getimage.c
@@ -44,8 +44,6 @@ _glamor_get_image(DrawablePtr drawable, int x, int y, int w,
int h,
if (format != ZPixmap)
goto fall_back;
-pixmap = glamor_get_drawable_pixmap(drawable);
-glamor_get_drawable_deltas(drawable, pixmap, x_off, y_off);
if (!glamor_set_planemask(pixmap, planeMask)) {
glamor_fallback(Failedto set planemask in glamor_solid.\n);
--
1.9.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 21/27] glamor: Improve the performance of PushPixels by, well, pushing pixels.
Otherwise, mi will fall back to GetSpans()ing the bitmap, walking the
bitmap, computing spans to be filled, and calling FillSpans().
Improves x11perf -f8text by 759.373% +/- 3.33096% (n=166)
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_glyphblt.c | 115 +++
1 file changed, 115 insertions(+)
diff --git a/glamor/glamor_glyphblt.c b/glamor/glamor_glyphblt.c
index 6f754ce..0a99a95 100644
--- a/glamor/glamor_glyphblt.c
+++ b/glamor/glamor_glyphblt.c
@@ -91,15 +91,130 @@ glamor_poly_glyph_blt_nf(DrawablePtr pDrawable, GCPtr pGC,
}
static Bool
+glamor_push_pixels_points(GCPtr gc, PixmapPtr bitmap,
+ DrawablePtr drawable, int w, int h, int x, int y)
+{
+ScreenPtr screen = drawable-pScreen;
+glamor_screen_private *glamor_priv = glamor_get_screen_private(screen);
+PixmapPtr pixmap = glamor_get_drawable_pixmap(drawable);
+glamor_pixmap_private *pixmap_priv;
+uint8_t *bitmap_data = bitmap-devPrivate.ptr;
+int bitmap_stride = bitmap-devKind;
+int off_x, off_y;
+int yy, xx;
+GLfloat xscale, yscale;
+float color[4];
+unsigned long fg_pixel = gc-fgPixel;
+float *points, *next_point;
+int num_points = 0;
+char *vbo_offset;
+RegionPtr clip;
+
+if (w * h MAXINT / (2 * sizeof(float)))
+return FALSE;
+
+if (gc-fillStyle != FillSolid) {
+glamor_fallback(gc fillstyle not solid\n);
+return FALSE;
+}
+
+pixmap_priv = glamor_get_pixmap_private(pixmap);
+if (!GLAMOR_PIXMAP_PRIV_HAS_FBO(pixmap_priv))
+return FALSE;
+
+glamor_get_context(glamor_priv);
+if (!glamor_set_alu(screen, gc-alu)) {
+if (gc-alu == GXclear)
+fg_pixel = 0;
+else {
+glamor_fallback(unsupported alu %x\n, gc-alu);
+glamor_put_context(glamor_priv);
+return FALSE;
+}
+}
+
+if (!glamor_set_planemask(pixmap, gc-planemask)) {
+glamor_fallback(Failed to set planemask in %s.\n, __FUNCTION__);
+glamor_put_context(glamor_priv);
+return FALSE;
+}
+
+glamor_get_drawable_deltas(drawable, pixmap, off_x, off_y);
+
+glamor_set_destination_pixmap_priv_nc(pixmap_priv);
+pixmap_priv_get_dest_scale(pixmap_priv, xscale, yscale);
+
+glUseProgram(glamor_priv-solid_prog);
+
+glamor_get_rgba_from_pixel(fg_pixel,
+ color[0], color[1], color[2], color[3],
+ format_for_pixmap(pixmap));
+glUniform4fv(glamor_priv-solid_color_uniform_location, 1, color);
+
+points = glamor_get_vbo_space(screen, w * h * sizeof(float) * 2,
+ vbo_offset);
+next_point = points;
+
+clip = fbGetCompositeClip(gc);
+
+/* Note that because fb sets miTranslate in the GC, our incoming X
+ * and Y are in screen coordinate space (same for spans, but not
+ * other operations).
+ */
+for (yy = 0; yy h; yy++) {
+uint8_t *bitmap_row = bitmap_data + yy * bitmap_stride;
+for (xx = 0; xx w; xx++) {
+if (bitmap_row[xx / 8] (1 xx % 8)
+RegionContainsPoint(clip,
+x + xx,
+y + yy,
+NULL)) {
+next_point[0] = v_from_x_coord_x(xscale, x + xx + off_x + 0.5);
+if (glamor_priv-yInverted)
+next_point[1] = v_from_x_coord_y_inverted(yscale, y + yy +
off_y + 0.5);
+else
+next_point[1] = v_from_x_coord_y(yscale, y + yy + off_y +
0.5);
+
+next_point += 2;
+num_points++;
+}
+}
+}
+glVertexAttribPointer(GLAMOR_VERTEX_POS, 2, GL_FLOAT,
+ GL_FALSE, 2 * sizeof(float),
+ vbo_offset);
+glEnableVertexAttribArray(GLAMOR_VERTEX_POS);
+
+glamor_put_vbo_space(screen);
+
+glDrawArrays(GL_POINTS, 0, num_points);
+
+glDisableVertexAttribArray(GLAMOR_VERTEX_POS);
+glUseProgram(0);
+
+glamor_put_context(glamor_priv);
+
+return TRUE;
+}
+
+static Bool
_glamor_push_pixels(GCPtr pGC, PixmapPtr pBitmap,
DrawablePtr pDrawable, int w, int h, int x, int y,
Bool fallback)
{
+glamor_pixmap_private *pixmap_priv;
+
if (!fallback glamor_ddx_fallback_check_pixmap(pDrawable)
glamor_ddx_fallback_check_pixmap(pBitmap-drawable)
glamor_ddx_fallback_check_gc(pGC))
return FALSE;
+pixmap_priv = glamor_get_pixmap_private(pBitmap);
+if (pixmap_priv-type == GLAMOR_MEMORY) {
+if (glamor_push_pixels_points(pGC, pBitmap, pDrawable, w, h, x, y))
+return TRUE;
+}
+
miPushPixels(pGC, pBitmap, pDrawable, w, h, x, y);
return TRUE;
}
--
1.9.0
___
xorg-devel@lists.x.org: X.Org
[PATCH 08/27] glamor: Return the stride/size for glamor_dri3_name_from_pixmap(), too.
Just like for a caller of glamor_dri3_fd_from_pixmap(), otherwise the
consumer of that named buffer has no idea what GL chose for the
stride.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor.c | 4 ++--
glamor/glamor.h | 3 ++-
glamor/glamor_egl.c | 4 ++--
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/glamor/glamor.c b/glamor/glamor.c
index e298b04..5338d45 100644
--- a/glamor/glamor.c
+++ b/glamor/glamor.c
@@ -647,7 +647,7 @@ glamor_fd_from_pixmap(ScreenPtr screen,
}
int
-glamor_name_from_pixmap(PixmapPtr pixmap)
+glamor_name_from_pixmap(PixmapPtr pixmap, CARD16 *stride, CARD32 *size)
{
glamor_pixmap_private *pixmap_priv;
glamor_screen_private *glamor_priv =
@@ -663,7 +663,7 @@ glamor_name_from_pixmap(PixmapPtr pixmap)
return glamor_egl_dri3_fd_name_from_tex(pixmap-drawable.pScreen,
pixmap,
pixmap_priv-base.fbo-tex,
-TRUE, NULL, NULL);
+TRUE, stride, size);
default:
break;
}
diff --git a/glamor/glamor.h b/glamor/glamor.h
index be46a52..d05d2f4 100644
--- a/glamor/glamor.h
+++ b/glamor/glamor.h
@@ -210,7 +210,8 @@ extern _X_EXPORT int glamor_fd_from_pixmap(ScreenPtr screen,
*
* Returns the name on success, -1 on error.
* */
-extern _X_EXPORT int glamor_name_from_pixmap(PixmapPtr pixmap);
+extern _X_EXPORT int glamor_name_from_pixmap(PixmapPtr pixmap,
+ CARD16 *stride, CARD32 *size);
/* @glamor_pixmap_from_fd: Creates a pixmap to wrap a dma-buf fd.
*
diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
index f3835af..8123421 100644
--- a/glamor/glamor_egl.c
+++ b/glamor/glamor_egl.c
@@ -441,10 +441,10 @@ glamor_egl_dri3_fd_name_from_tex(ScreenPtr screen,
}
else {
if (glamor_get_fd_from_bo(glamor_egl-fd, bo, fd)) {
-*stride = pixmap-devKind;
-*size = pixmap-devKind * gbm_bo_get_height(bo);
}
}
+*stride = pixmap-devKind;
+*size = pixmap-devKind * gbm_bo_get_height(bo);
gbm_bo_destroy(bo);
failure:
--
1.9.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 02/27] glamor: Drop the set of the context to NULL at the end of glamor ops.
The theory here was that it (which I copied from EGL) existed to fix
up context switching with indirect GLX. But indirect GLX won't even
try to set the context again unless its lastContext field is cleared,
so we need to solve this a different way.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_glx.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/glamor/glamor_glx.c b/glamor/glamor_glx.c
index 311bf75..8f47c3d 100644
--- a/glamor/glamor_glx.c
+++ b/glamor/glamor_glx.c
@@ -53,13 +53,7 @@ glamor_glx_get_context(struct glamor_context *glamor_ctx)
static void
glamor_glx_put_context(struct glamor_context *glamor_ctx)
{
-if (--glamor_ctx-get_count)
-return;
-
-/* We actually reset the context, so that indirect GLX's EGL usage
- * won't get confused by ours.
- */
-glXMakeCurrent(glamor_ctx-display, None, NULL);
+--glamor_ctx-get_count;
}
Bool
--
1.9.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 13/27] glamor: Rename a variable to be more descriptive.
The valid_ prefix was used above to describe our allocation that
gets reused multiple times, which is totally unrelated.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_fill.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/glamor/glamor_fill.c b/glamor/glamor_fill.c
index d5843b7..12b8c37 100644
--- a/glamor/glamor_fill.c
+++ b/glamor/glamor_fill.c
@@ -226,17 +226,17 @@ _glamor_solid_boxes(PixmapPtr pixmap, BoxPtr box, int
nbox, float *color)
while (nbox) {
int box_cnt, i;
-float *valid_vertices;
+float *next_box;
-valid_vertices = pvertices;
+next_box = pvertices;
box_cnt = nbox valid_nbox ? valid_nbox : nbox;
for (i = 0; i box_cnt; i++) {
glamor_set_normalize_vcoords(pixmap_priv, xscale, yscale,
box[i].x1, box[i].y1,
box[i].x2, box[i].y2,
glamor_priv-yInverted,
- valid_vertices);
-valid_vertices += 4 * 2;
+ next_box);
+next_box += 4 * 2;
}
if (box_cnt == 1)
glDrawArrays(GL_TRIANGLE_FAN, 0, box_cnt * 4);
--
1.9.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 10/27] glamor: Fix stack overflow in glamor_solid vertex handling.
ARRAY_SIZE(vertices) is 32 (floating point values), so we need to divide by the number of floats in a box like we do in the overflow case below. Signed-off-by: Eric Anholt e...@anholt.net --- glamor/glamor_fill.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/glamor/glamor_fill.c b/glamor/glamor_fill.c index dda55ea..75c952c 100644 --- a/glamor/glamor_fill.c +++ b/glamor/glamor_fill.c @@ -189,7 +189,7 @@ _glamor_solid_boxes(PixmapPtr pixmap, BoxPtr box, int nbox, float *color) GLfloat xscale, yscale; float vertices[32]; float *pvertices = vertices; -int valid_nbox = ARRAY_SIZE(vertices); +int valid_nbox = ARRAY_SIZE(vertices) / (4 * 2); glamor_set_destination_pixmap_priv_nc(pixmap_priv); -- 1.9.0 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 12/27] glamor: Fix some integer overflow errors.
Imagine a nbox that was (UINT_MAX + small number) / (4 * 2 *
sizeof(float)). We'd malloc a few bytes after the integer overflow,
but glamor_set_normalize_vcoords would write over gigabytes of heap.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_fill.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/glamor/glamor_fill.c b/glamor/glamor_fill.c
index aaa7783..d5843b7 100644
--- a/glamor/glamor_fill.c
+++ b/glamor/glamor_fill.c
@@ -200,10 +200,10 @@ _glamor_solid_boxes(PixmapPtr pixmap, BoxPtr box, int
nbox, float *color)
pixmap_priv_get_dest_scale(pixmap_priv, xscale, yscale);
-if (nbox * 4 * 2 ARRAY_SIZE(vertices)) {
+if (nbox valid_nbox) {
int allocated_box;
-if (nbox * 6 GLAMOR_COMPOSITE_VBO_VERT_CNT) {
+if (nbox GLAMOR_COMPOSITE_VBO_VERT_CNT / 6) {
allocated_box = GLAMOR_COMPOSITE_VBO_VERT_CNT / 6;
}
else
--
1.9.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 01/27] xephyr: Don't forget to glViewport() before drawing the screen.
Fixes misrendering with cairogears. I had noticed the failure while
trying to figure out what was going on with traps. Cairogears was
apparently putting its results on the screen through putimage, which
is a texture upload, so the last GL drawing was done to the size of
the cairogears window, not the size of the xephyr screen.
Signed-off-by: Eric Anholt e...@anholt.net
---
hw/kdrive/ephyr/ephyr_glamor_glx.c | 15 +++
hw/kdrive/ephyr/ephyr_glamor_glx.h | 10 ++
hw/kdrive/ephyr/hostx.c| 4
3 files changed, 29 insertions(+)
diff --git a/hw/kdrive/ephyr/ephyr_glamor_glx.c
b/hw/kdrive/ephyr/ephyr_glamor_glx.c
index d56907f..eaf5654 100644
--- a/hw/kdrive/ephyr/ephyr_glamor_glx.c
+++ b/hw/kdrive/ephyr/ephyr_glamor_glx.c
@@ -67,6 +67,9 @@ struct ephyr_glamor {
GLuint texture_shader;
GLuint texture_shader_position_loc;
GLuint texture_shader_texcoord_loc;
+
+/* Size of the window that we're rendering to. */
+unsigned width, height;
};
static GLint
@@ -205,6 +208,7 @@ ephyr_glamor_damage_redisplay(struct ephyr_glamor *glamor,
glBindFramebuffer(GL_FRAMEBUFFER, 0);
glUseProgram(glamor-texture_shader);
+glViewport(0, 0, glamor-width, glamor-height);
glVertexAttribPointer(glamor-texture_shader_position_loc,
2, GL_FLOAT, FALSE, 0, position);
@@ -329,3 +333,14 @@ ephyr_glamor_get_visual(void)
return xcb_aux_find_visual_by_id(xscreen, visual_info-visualid);
}
+
+void
+ephyr_glamor_set_window_size(struct ephyr_glamor *glamor,
+ unsigned width, unsigned height)
+{
+if (!glamor)
+return;
+
+glamor-width = width;
+glamor-height = height;
+}
diff --git a/hw/kdrive/ephyr/ephyr_glamor_glx.h
b/hw/kdrive/ephyr/ephyr_glamor_glx.h
index 8995e1e..0c238cf 100644
--- a/hw/kdrive/ephyr/ephyr_glamor_glx.h
+++ b/hw/kdrive/ephyr/ephyr_glamor_glx.h
@@ -51,6 +51,10 @@ ephyr_glamor_glx_screen_fini(struct ephyr_glamor *glamor);
#ifdef GLAMOR
void
+ephyr_glamor_set_window_size(struct ephyr_glamor *glamor,
+ unsigned width, unsigned height);
+
+void
ephyr_glamor_damage_redisplay(struct ephyr_glamor *glamor,
struct pixman_region16 *damage);
@@ -60,6 +64,12 @@ ephyr_glamor_process_event(xcb_generic_event_t *xev);
#else /* !GLAMOR */
static inline void
+ephyr_glamor_set_window_size(struct ephyr_glamor *glamor,
+ unsigned width, unsigned height)
+{
+}
+
+static inline void
ephyr_glamor_damage_redisplay(struct ephyr_glamor *glamor,
struct pixman_region16 *damage)
{
diff --git a/hw/kdrive/ephyr/hostx.c b/hw/kdrive/ephyr/hostx.c
index 859beca..0a9eb46 100644
--- a/hw/kdrive/ephyr/hostx.c
+++ b/hw/kdrive/ephyr/hostx.c
@@ -731,6 +731,8 @@ hostx_screen_init(KdScreenInfo *screen,
if (ephyr_glamor) {
*bytes_per_line = 0;
*bits_per_pixel = 0;
+ephyr_glamor_set_window_size(scrpriv-glamor,
+ scrpriv-win_width, scrpriv-win_height);
return NULL;
} else if (host_depth_matches_server(scrpriv)) {
*bytes_per_line = scrpriv-ximg-stride;
@@ -1218,6 +1220,8 @@ ephyr_glamor_init(ScreenPtr screen)
EphyrScrPriv *scrpriv = kd_screen-driver;
scrpriv-glamor = ephyr_glamor_glx_screen_init(scrpriv-win);
+ephyr_glamor_set_window_size(scrpriv-glamor,
+ scrpriv-win_width, scrpriv-win_height);
glamor_init(screen,
GLAMOR_USE_SCREEN |
--
1.9.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 07/27] glamor: Drop the body of the function for enabling DRI3 extensions.
The flag is already being set at glamor_egl_screen_init() time, so no
need for the driver to separately call this. That said, leave the
function around to keep the ABI compatibility.
---
glamor/glamor.h | 8
glamor/glamor_egl.c | 7 +--
2 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/glamor/glamor.h b/glamor/glamor.h
index 9cda46d..be46a52 100644
--- a/glamor/glamor.h
+++ b/glamor/glamor.h
@@ -247,14 +247,6 @@ extern _X_EXPORT PixmapPtr glamor_pixmap_from_fd(ScreenPtr
screen,
* */
extern _X_EXPORT Bool glamor_egl_init(ScrnInfoPtr scrn, int fd);
-/* @glamor_egl_init_textured_pixmap: Initialization for textured pixmap
allocation.
- *
- * @screen: Current screen pointer.
- *
- * This function must be called before any textured pixmap's creation including
- * the screen pixmap. Could be called from DDX's screenInit function after the
calling
- * to glamor_init..
- */
extern _X_EXPORT Bool glamor_egl_init_textured_pixmap(ScreenPtr screen);
/* @glamor_egl_create_textured_screen: Create textured screen pixmap.
diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
index f24cb28..f3835af 100644
--- a/glamor/glamor_egl.c
+++ b/glamor/glamor_egl.c
@@ -831,14 +831,9 @@ glamor_egl_init(ScrnInfoPtr scrn, int fd)
return TRUE;
}
+/** Stub to retain compatibility with pre-server-1.16 ABI. */
Bool
glamor_egl_init_textured_pixmap(ScreenPtr screen)
{
-ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
-struct glamor_egl_screen_private *glamor_egl =
-glamor_egl_get_screen_private(scrn);
-
-if (glamor_egl-dri3_capable)
-glamor_enable_dri3(screen);
return TRUE;
}
--
1.9.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 17/27] glamor: Drop unused GLAMOR_ACCESS_WO.
Nothing was using it, and it was going to complicate the
glamor_prepare_access bugfixing I'm going to do next.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_pixmap.c | 11 +--
glamor/glamor_priv.h | 1 -
2 files changed, 1 insertion(+), 11 deletions(-)
diff --git a/glamor/glamor_pixmap.c b/glamor/glamor_pixmap.c
index 119e4d9..f4782e6 100644
--- a/glamor/glamor_pixmap.c
+++ b/glamor/glamor_pixmap.c
@@ -1216,8 +1216,6 @@ _glamor_download_sub_pixmap_to_cpu(PixmapPtr pixmap,
GLenum format,
gl_access = GL_READ_ONLY;
gl_usage = GL_STREAM_READ;
break;
-case GLAMOR_ACCESS_WO:
-return bits;
case GLAMOR_ACCESS_RW:
gl_access = GL_READ_WRITE;
gl_usage = GL_DYNAMIC_DRAW;
@@ -1472,8 +1470,7 @@ glamor_download_pixmap_to_cpu(PixmapPtr pixmap,
glamor_access_t access)
stride = pixmap-devKind;
-if (access == GLAMOR_ACCESS_WO
-|| glamor_priv-gl_flavor == GLAMOR_GL_ES2
+if (glamor_priv-gl_flavor == GLAMOR_GL_ES2
|| (!glamor_priv-has_pack_invert !glamor_priv-yInverted)
|| pixmap_priv-type == GLAMOR_TEXTURE_LARGE) {
data = malloc(stride * pixmap-drawable.height);
@@ -1603,12 +1600,6 @@ glamor_get_sub_pixmap(PixmapPtr pixmap, int x, int y,
int w, int h,
return NULL;
w = (x + w) pixmap-drawable.width ? (pixmap-drawable.width - x) : w;
h = (y + h) pixmap-drawable.height ? (pixmap-drawable.height - y) : h;
-if (access == GLAMOR_ACCESS_WO) {
-sub_pixmap = glamor_create_pixmap(pixmap-drawable.pScreen, w, h,
- pixmap-drawable.depth,
- GLAMOR_CREATE_PIXMAP_CPU);
-return sub_pixmap;
-}
glamor_priv = glamor_get_screen_private(pixmap-drawable.pScreen);
pixmap_priv = glamor_get_pixmap_private(pixmap);
diff --git a/glamor/glamor_priv.h b/glamor/glamor_priv.h
index 52dad35..7f41025 100644
--- a/glamor/glamor_priv.h
+++ b/glamor/glamor_priv.h
@@ -288,7 +288,6 @@ typedef struct glamor_screen_private {
typedef enum glamor_access {
GLAMOR_ACCESS_RO,
GLAMOR_ACCESS_RW,
-GLAMOR_ACCESS_WO,
} glamor_access_t;
enum glamor_fbo_state {
--
1.9.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 22/27] glamor: Improve the performance of PolyGlyphBlt.
Using the same idea as the previous PushPixels code, just make points
for each point in the glyph. This is an advantage over the pushpixels
fallback because we can batch the BO mappings and draw calls across
glyphs.
Improves performance of x11perf -f8text by 773.389% +/- 3.50754% (n=10).
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_glyphblt.c | 138 +++
1 file changed, 138 insertions(+)
diff --git a/glamor/glamor_glyphblt.c b/glamor/glamor_glyphblt.c
index 0a99a95..5d785a0 100644
--- a/glamor/glamor_glyphblt.c
+++ b/glamor/glamor_glyphblt.c
@@ -27,6 +27,141 @@
*/
#include glamor_priv.h
+#include dixfontstr.h
+
+static Bool
+glamor_poly_glyph_blt_pixels(DrawablePtr drawable, GCPtr gc,
+ int x, int y, unsigned int nglyph,
+ CharInfoPtr *ppci)
+{
+ScreenPtr screen = drawable-pScreen;
+glamor_screen_private *glamor_priv = glamor_get_screen_private(screen);
+PixmapPtr pixmap = glamor_get_drawable_pixmap(drawable);
+glamor_pixmap_private *pixmap_priv;
+int off_x, off_y;
+GLfloat xscale, yscale;
+float color[4];
+unsigned long fg_pixel = gc-fgPixel;
+char *vbo_offset;
+RegionPtr clip;
+int num_points, max_points;
+float *points = NULL;
+
+x += drawable-x;
+y += drawable-y;
+
+if (gc-fillStyle != FillSolid) {
+glamor_fallback(gc fillstyle not solid\n);
+return FALSE;
+}
+
+pixmap_priv = glamor_get_pixmap_private(pixmap);
+if (!GLAMOR_PIXMAP_PRIV_HAS_FBO(pixmap_priv))
+return FALSE;
+
+glamor_get_context(glamor_priv);
+if (!glamor_set_alu(screen, gc-alu)) {
+if (gc-alu == GXclear)
+fg_pixel = 0;
+else {
+glamor_fallback(unsupported alu %x\n, gc-alu);
+glamor_put_context(glamor_priv);
+return FALSE;
+}
+}
+
+if (!glamor_set_planemask(pixmap, gc-planemask)) {
+glamor_fallback(Failed to set planemask in %s.\n, __FUNCTION__);
+glamor_put_context(glamor_priv);
+return FALSE;
+}
+
+glamor_get_drawable_deltas(drawable, pixmap, off_x, off_y);
+
+glamor_set_destination_pixmap_priv_nc(pixmap_priv);
+pixmap_priv_get_dest_scale(pixmap_priv, xscale, yscale);
+
+glUseProgram(glamor_priv-solid_prog);
+
+glamor_get_rgba_from_pixel(fg_pixel,
+ color[0], color[1], color[2], color[3],
+ format_for_pixmap(pixmap));
+glUniform4fv(glamor_priv-solid_color_uniform_location, 1, color);
+
+clip = fbGetCompositeClip(gc);
+
+glEnableVertexAttribArray(GLAMOR_VERTEX_POS);
+
+max_points = 500;
+num_points = 0;
+while (nglyph--) {
+CharInfoPtr charinfo = *ppci++;
+int w = GLYPHWIDTHPIXELS(charinfo);
+int h = GLYPHHEIGHTPIXELS(charinfo);
+uint8_t *glyphbits = FONTGLYPHBITS(NULL, charinfo);
+
+if (w h) {
+int glyph_x = x + charinfo-metrics.leftSideBearing;
+int glyph_y = y - charinfo-metrics.ascent;
+int glyph_stride = GLYPHWIDTHBYTESPADDED(charinfo);
+int xx, yy;
+
+for (yy = 0; yy h; yy++) {
+uint8_t *glyph_row = glyphbits + glyph_stride * yy;
+for (xx = 0; xx w; xx++) {
+int pt_x_i = glyph_x + xx;
+int pt_y_i = glyph_y + yy;
+float pt_x_f, pt_y_f;
+if (!(glyph_row[xx / 8] (1 xx % 8)))
+continue;
+
+if (!RegionContainsPoint(clip, pt_x_i, pt_y_i, NULL))
+continue;
+
+if (!num_points) {
+points = glamor_get_vbo_space(screen,
+ max_points * 2 *
sizeof(float),
+ vbo_offset);
+
+glVertexAttribPointer(GLAMOR_VERTEX_POS, 2, GL_FLOAT,
+ GL_FALSE, 2 * sizeof(float),
+ vbo_offset);
+}
+
+pt_x_f = v_from_x_coord_x(xscale, pt_x_i + off_x + 0.5);
+if (glamor_priv-yInverted)
+pt_y_f = v_from_x_coord_y_inverted(yscale, pt_y_i +
off_y + 0.5);
+else
+pt_y_f = v_from_x_coord_y(yscale, pt_y_i + off_y +
0.5);
+
+points[num_points * 2 + 0] = pt_x_f;
+points[num_points * 2 + 1] = pt_y_f;
+num_points++;
+
+if (num_points == max_points) {
+glamor_put_vbo_space(screen);
+glDrawArrays(GL_POINTS, 0, num_points);
+num_points = 0;
+}
+}
+}
+}
+
+x += charinfo
[PATCH 16/27] glamor: Replace some goofy enum-likes with a real enum.
This unpacks the bitfield into an int size, but my experience has been
that packing bitfields doesn't matter for performance.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_fbo.c | 2 +-
glamor/glamor_priv.h | 25 -
2 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/glamor/glamor_fbo.c b/glamor/glamor_fbo.c
index 281cf83..640b6fd 100644
--- a/glamor/glamor_fbo.c
+++ b/glamor/glamor_fbo.c
@@ -505,7 +505,7 @@ glamor_pixmap_attach_fbo(PixmapPtr pixmap,
glamor_pixmap_fbo *fbo)
case GLAMOR_TEXTURE_LARGE:
case GLAMOR_TEXTURE_ONLY:
case GLAMOR_TEXTURE_DRM:
-pixmap_priv-base.gl_fbo = 1;
+pixmap_priv-base.gl_fbo = GLAMOR_FBO_NORMAL;
if (fbo-tex != 0)
pixmap_priv-base.gl_tex = 1;
else {
diff --git a/glamor/glamor_priv.h b/glamor/glamor_priv.h
index 4dc2c75..52dad35 100644
--- a/glamor/glamor_priv.h
+++ b/glamor/glamor_priv.h
@@ -291,8 +291,21 @@ typedef enum glamor_access {
GLAMOR_ACCESS_WO,
} glamor_access_t;
-#define GLAMOR_FBO_NORMAL 1
-#define GLAMOR_FBO_DOWNLOADED 2
+enum glamor_fbo_state {
+/** There is no storage attached to the pixmap. */
+GLAMOR_FBO_UNATTACHED,
+/**
+ * The pixmap has FBO storage attached, but devPrivate.ptr doesn't
+ * point at anything.
+ */
+GLAMOR_FBO_NORMAL,
+/**
+ * The FBO is present and can be accessed as a linear memory
+ * mapping through devPrivate.ptr.
+ */
+GLAMOR_FBO_DOWNLOADED,
+};
+
/* glamor_pixmap_fbo:
* @list:to be used to link to the cache pool list.
* @expire: when push to cache pool list, set a expire count.
@@ -324,12 +337,6 @@ typedef struct glamor_pixmap_fbo {
/*
* glamor_pixmap_private - glamor pixmap's private structure.
- * @gl_fbo:
- * 0 - The pixmap doesn't has a fbo attached to it.
- * GLAMOR_FBO_NORMAL - The pixmap has a fbo and can be accessed
normally.
- * GLAMOR_FBO_DOWNLOADED - The pixmap has a fbo and already downloaded to
- * CPU, so it can only be treated as a in-memory
pixmap
- * if this bit is set.
* @gl_tex: The pixmap is in a gl texture originally.
* @is_picture: The drawable is attached to a picture.
* @pict_format: the corresponding picture's format.
@@ -403,7 +410,7 @@ typedef struct glamor_pixmap_clipped_regions {
typedef struct glamor_pixmap_private_base {
glamor_pixmap_type_t type;
-unsigned char gl_fbo:2;
+enum glamor_fbo_state gl_fbo;
unsigned char is_picture:1;
unsigned char gl_tex:1;
glamor_pixmap_fbo *fbo;
--
1.9.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 25/27] glamor: Add an assert about an invariant the upload code relies on.
Signed-off-by: Eric Anholt e...@anholt.net --- glamor/glamor_pixmap.c | 1 + 1 file changed, 1 insertion(+) diff --git a/glamor/glamor_pixmap.c b/glamor/glamor_pixmap.c index f4782e6..ff07483 100644 --- a/glamor/glamor_pixmap.c +++ b/glamor/glamor_pixmap.c @@ -725,6 +725,7 @@ __glamor_upload_pixmap_to_texture(PixmapPtr pixmap, unsigned int *tex, glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST); glPixelStorei(GL_UNPACK_ALIGNMENT, 4); +assert(pbo || bits != 0); if (bits == NULL) glBindBuffer(GL_PIXEL_UNPACK_BUFFER, pbo); if (non_sub) -- 1.9.0 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 23/27] glamor: Improve the performance of line fallbacks.
If the lines aren't solid-filled vert/horiz solid-filled rectangles,
we fall back. libreoffice has some diagonal lines, and the
performance of the fallback path was atrocious. Just fall back to
mi's spans instead, so that we don't do an upload/download.
Improves x11perf -seg100 by 863.652% +/- 9.8968% (n=5)
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_polylines.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/glamor/glamor_polylines.c b/glamor/glamor_polylines.c
index 697fc9e..1adf45d 100644
--- a/glamor/glamor_polylines.c
+++ b/glamor/glamor_polylines.c
@@ -51,8 +51,9 @@ _glamor_poly_lines(DrawablePtr drawable, GCPtr gc, int mode,
int n,
/* This ends up in miSetSpans, which is accelerated as well as we
* can hope X wide lines will be.
*/
-goto wide_line;
+goto fail;
}
+
if (gc-lineStyle != LineSolid) {
glamor_fallback(non-solid fill line style %d\n, gc-lineStyle);
goto fail;
@@ -104,19 +105,19 @@ _glamor_poly_lines(DrawablePtr drawable, GCPtr gc, int
mode, int n,
glamor_ddx_fallback_check_gc(gc))
return FALSE;
-if (gc-lineWidth == 0) {
-if (glamor_prepare_access(drawable, GLAMOR_ACCESS_RW)
-glamor_prepare_access_gc(gc)) {
-fbPolyLine(drawable, gc, mode, n, points);
-}
-glamor_finish_access_gc(gc);
-glamor_finish_access(drawable);
-}
-else {
- wide_line:
-/* fb calls mi functions in the lineWidth != 0 case. */
-fbPolyLine(drawable, gc, mode, n, points);
+switch (gc-lineStyle) {
+case LineSolid:
+if (gc-lineWidth == 0)
+miZeroLine(drawable, gc, mode, n, points);
+else
+miWideLine(drawable, gc, mode, n, points);
+break;
+case LineOnOffDash:
+case LineDoubleDash:
+miWideDash(drawable, gc, mode, n, points);
+break;
}
+
return TRUE;
}
--
1.9.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 19/27] glamor: Rely on nested mappings to handle src==dst and !prepare bugs.
Now that the core deals with that for us, we can avoid all this extra
carefulness.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_addtraps.c | 2 +-
glamor/glamor_copyarea.c | 14 ++
glamor/glamor_copyplane.c| 13 +++--
glamor/glamor_core.c | 17 -
glamor/glamor_fill.c | 11 +--
glamor/glamor_fillspans.c| 11 +--
glamor/glamor_getspans.c | 2 +-
glamor/glamor_picture.c | 4 ++--
glamor/glamor_polyfillrect.c | 11 +--
glamor/glamor_polylines.c| 11 +--
glamor/glamor_priv.h | 4 ++--
glamor/glamor_putimage.c | 2 +-
glamor/glamor_render.c | 27 +++
glamor/glamor_setspans.c | 2 +-
glamor/glamor_triangles.c| 15 ++-
glamor/glamor_utils.h| 33 -
16 files changed, 82 insertions(+), 97 deletions(-)
diff --git a/glamor/glamor_addtraps.c b/glamor/glamor_addtraps.c
index 655d87e..fdc0f42 100644
--- a/glamor/glamor_addtraps.c
+++ b/glamor/glamor_addtraps.c
@@ -40,8 +40,8 @@ _glamor_add_traps(PicturePtr pPicture,
if (glamor_prepare_access_picture(pPicture, GLAMOR_ACCESS_RW)) {
fbAddTraps(pPicture, x_off, y_off, ntrap, traps);
-glamor_finish_access_picture(pPicture, GLAMOR_ACCESS_RW);
}
+glamor_finish_access_picture(pPicture);
return TRUE;
}
diff --git a/glamor/glamor_copyarea.c b/glamor/glamor_copyarea.c
index d6bcacd..b367e03 100644
--- a/glamor/glamor_copyarea.c
+++ b/glamor/glamor_copyarea.c
@@ -570,15 +570,13 @@ _glamor_copy_n_to_n(DrawablePtr src,
glamor_get_drawable_location(src),
glamor_get_drawable_location(dst));
-if (glamor_prepare_access(dst, GLAMOR_ACCESS_RW)) {
-if (dst == src || glamor_prepare_access(src, GLAMOR_ACCESS_RO)) {
-fbCopyNtoN(src, dst, gc, box, nbox,
- dx, dy, reverse, upsidedown, bitplane, closure);
-if (dst != src)
-glamor_finish_access(src, GLAMOR_ACCESS_RO);
-}
-glamor_finish_access(dst, GLAMOR_ACCESS_RW);
+if (glamor_prepare_access(dst, GLAMOR_ACCESS_RW)
+glamor_prepare_access(src, GLAMOR_ACCESS_RO)) {
+fbCopyNtoN(src, dst, gc, box, nbox,
+ dx, dy, reverse, upsidedown, bitplane, closure);
}
+glamor_finish_access(src);
+glamor_finish_access(dst);
ok = TRUE;
done:
diff --git a/glamor/glamor_copyplane.c b/glamor/glamor_copyplane.c
index c42d33e..50e9cf3 100644
--- a/glamor/glamor_copyplane.c
+++ b/glamor/glamor_copyplane.c
@@ -38,12 +38,13 @@ _glamor_copy_plane(DrawablePtr pSrc, DrawablePtr pDst,
GCPtr pGC,
glamor_ddx_fallback_check_pixmap(pDst))
goto fail;
-glamor_prepare_access(pDst, GLAMOR_ACCESS_RW);
-glamor_prepare_access(pSrc, GLAMOR_ACCESS_RO);
-*pRegion = fbCopyPlane(pSrc, pDst, pGC, srcx, srcy, w, h,
- dstx, dsty, bitPlane);
-glamor_finish_access(pSrc, GLAMOR_ACCESS_RO);
-glamor_finish_access(pDst, GLAMOR_ACCESS_RW);
+if (glamor_prepare_access(pDst, GLAMOR_ACCESS_RW)
+glamor_prepare_access(pSrc, GLAMOR_ACCESS_RO)) {
+*pRegion = fbCopyPlane(pSrc, pDst, pGC, srcx, srcy, w, h,
+ dstx, dsty, bitPlane);
+}
+glamor_finish_access(pSrc);
+glamor_finish_access(pDst);
return TRUE;
fail:
diff --git a/glamor/glamor_core.c b/glamor/glamor_core.c
index 7a7ca08..c0994c1 100644
--- a/glamor/glamor_core.c
+++ b/glamor/glamor_core.c
@@ -303,7 +303,7 @@ glamor_fini_finish_access_shaders(ScreenPtr screen)
}
void
-glamor_finish_access(DrawablePtr drawable, glamor_access_t access_mode)
+glamor_finish_access(DrawablePtr drawable)
{
PixmapPtr pixmap = glamor_get_drawable_pixmap(drawable);
glamor_pixmap_private *pixmap_priv = glamor_get_pixmap_private(pixmap);
@@ -365,7 +365,7 @@ glamor_prepare_access_gc(GCPtr gc)
if (!glamor_prepare_access(gc-tile.pixmap-drawable,
GLAMOR_ACCESS_RO)) {
if (gc-stipple)
-glamor_finish_access(gc-stipple-drawable, GLAMOR_ACCESS_RO);
+glamor_finish_access(gc-stipple-drawable);
return FALSE;
}
}
@@ -379,9 +379,9 @@ void
glamor_finish_access_gc(GCPtr gc)
{
if (gc-fillStyle == FillTiled)
-glamor_finish_access(gc-tile.pixmap-drawable, GLAMOR_ACCESS_RO);
+glamor_finish_access(gc-tile.pixmap-drawable);
if (gc-stipple)
-glamor_finish_access(gc-stipple-drawable, GLAMOR_ACCESS_RO);
+glamor_finish_access(gc-stipple-drawable);
}
Bool
@@ -455,7 +455,7 @@ glamor_validate_gc(GCPtr gc, unsigned long changes,
DrawablePtr drawable)
(old_tile-drawable, GLAMOR_ACCESS_RO)) {
new_tile =
fb24_32ReformatTile(old_tile, drawable-bitsPerPixel
[PATCH 14/27] glamor: Rename more solid fill variables to clean up the code.
Now the error path of allocation is more obvious: We leave things in
the a-few-boxes-at-a-time stack memory state.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_fill.c | 34 --
1 file changed, 16 insertions(+), 18 deletions(-)
diff --git a/glamor/glamor_fill.c b/glamor/glamor_fill.c
index 12b8c37..f8b39a5 100644
--- a/glamor/glamor_fill.c
+++ b/glamor/glamor_fill.c
@@ -187,9 +187,9 @@ _glamor_solid_boxes(PixmapPtr pixmap, BoxPtr box, int nbox,
float *color)
glamor_screen_private *glamor_priv = glamor_get_screen_private(screen);
glamor_pixmap_private *pixmap_priv = glamor_get_pixmap_private(pixmap);
GLfloat xscale, yscale;
-float vertices[32];
-float *pvertices = vertices;
-int valid_nbox = ARRAY_SIZE(vertices) / (4 * 2);
+float stack_vertices[32];
+float *vertices = stack_vertices;
+int valid_nbox = ARRAY_SIZE(stack_vertices) / (4 * 2);
glamor_set_destination_pixmap_priv_nc(pixmap_priv);
@@ -201,19 +201,17 @@ _glamor_solid_boxes(PixmapPtr pixmap, BoxPtr box, int
nbox, float *color)
pixmap_priv_get_dest_scale(pixmap_priv, xscale, yscale);
if (nbox valid_nbox) {
-int allocated_box;
+int allocated_nbox;
+float *new_vertices;
-if (nbox GLAMOR_COMPOSITE_VBO_VERT_CNT / 6) {
-allocated_box = GLAMOR_COMPOSITE_VBO_VERT_CNT / 6;
-}
+if (nbox GLAMOR_COMPOSITE_VBO_VERT_CNT / 6)
+allocated_nbox = GLAMOR_COMPOSITE_VBO_VERT_CNT / 6;
else
-allocated_box = nbox;
-pvertices = malloc(allocated_box * 4 * 2 * sizeof(float));
-if (pvertices)
-valid_nbox = allocated_box;
-else {
-pvertices = vertices;
-valid_nbox = ARRAY_SIZE(vertices) / (4 * 2);
+allocated_nbox = nbox;
+new_vertices = malloc(allocated_nbox * 4 * 2 * sizeof(float));
+if (new_vertices) {
+vertices = new_vertices;
+valid_nbox = allocated_nbox;
}
}
@@ -221,14 +219,14 @@ _glamor_solid_boxes(PixmapPtr pixmap, BoxPtr box, int
nbox, float *color)
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, glamor_priv-ebo);
glVertexAttribPointer(GLAMOR_VERTEX_POS, 2, GL_FLOAT,
- GL_FALSE, 2 * sizeof(float), pvertices);
+ GL_FALSE, 2 * sizeof(float), vertices);
glEnableVertexAttribArray(GLAMOR_VERTEX_POS);
while (nbox) {
int box_cnt, i;
float *next_box;
-next_box = pvertices;
+next_box = vertices;
box_cnt = nbox valid_nbox ? valid_nbox : nbox;
for (i = 0; i box_cnt; i++) {
glamor_set_normalize_vcoords(pixmap_priv, xscale, yscale,
@@ -253,8 +251,8 @@ _glamor_solid_boxes(PixmapPtr pixmap, BoxPtr box, int nbox,
float *color)
box += box_cnt;
}
-if (pvertices != vertices)
-free(pvertices);
+if (vertices != stack_vertices)
+free(vertices);
glDisableVertexAttribArray(GLAMOR_VERTEX_POS);
glUseProgram(0);
--
1.9.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 26/27] glamor: Don't forget to unmap our PBOs before usng them to upload.
From the GL_ARB_vertex_buffer_object spec:
After the client has specified the contents of a mapped data store,
and before the data in that store are dereferenced by any GL commands,
the mapping must be relinquished by calling
boolean UnmapBufferARB(enum target);
Our mappings were only getting reaped at PBO destroy time, after the
upload. If the GL implementation wasn't coherent, it would have used
stale data to do the texture upload.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_pixmap.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/glamor/glamor_pixmap.c b/glamor/glamor_pixmap.c
index ff07483..f54b348 100644
--- a/glamor/glamor_pixmap.c
+++ b/glamor/glamor_pixmap.c
@@ -726,8 +726,10 @@ __glamor_upload_pixmap_to_texture(PixmapPtr pixmap,
unsigned int *tex,
glPixelStorei(GL_UNPACK_ALIGNMENT, 4);
assert(pbo || bits != 0);
-if (bits == NULL)
+if (bits == NULL) {
glBindBuffer(GL_PIXEL_UNPACK_BUFFER, pbo);
+glUnmapBuffer(GL_PIXEL_UNPACK_BUFFER);
+}
if (non_sub)
glTexImage2D(GL_TEXTURE_2D, 0, iformat, w, h, 0, format, type, bits);
else
--
1.9.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 18/27] glamor: Allow nested mapping of pixmaps.
The common pattern is to do nested if statements making calls to
prepare_access() and then pop those mappings back off in each set of
braces. Some cases checked for src == dst to avoid leaking mappings,
but others didn't. Others didn't even do the nested mappings, so a
failure in the outer map would result in trying to umap the inner and
failing.
By allowing nested mappings, we can fix both problems by not requiring
the care from the caller, plus we can allow a simpler nesting of all
the prepares in one if statement.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_core.c | 19 ++-
glamor/glamor_priv.h | 6 ++
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/glamor/glamor_core.c b/glamor/glamor_core.c
index 5883809..7a7ca08 100644
--- a/glamor/glamor_core.c
+++ b/glamor/glamor_core.c
@@ -105,6 +105,19 @@ Bool
glamor_prepare_access(DrawablePtr drawable, glamor_access_t access)
{
PixmapPtr pixmap = glamor_get_drawable_pixmap(drawable);
+glamor_pixmap_private *pixmap_priv = glamor_get_pixmap_private(pixmap);
+
+if (pixmap-devPrivate.ptr) {
+/* Already mapped, nothing needs to be done. Note that we
+ * aren't allowing promotion from RO to RW, because it would
+ * require re-mapping the PBO.
+ */
+assert(!GLAMOR_PIXMAP_PRIV_HAS_FBO(pixmap_priv) ||
+ access == GLAMOR_ACCESS_RO ||
+ pixmap_priv-base.mapped_for_write);
+return TRUE;
+}
+pixmap_priv-base.mapped_for_write = (access == GLAMOR_ACCESS_RW);
return glamor_download_pixmap_to_cpu(pixmap, access);
}
@@ -300,7 +313,11 @@ glamor_finish_access(DrawablePtr drawable, glamor_access_t
access_mode)
if (!GLAMOR_PIXMAP_PRIV_HAS_FBO_DOWNLOADED(pixmap_priv))
return;
-if (access_mode != GLAMOR_ACCESS_RO) {
+/* If we are doing a series of unmaps from a nested map, we're done. */
+if (!pixmap-devPrivate.ptr)
+return;
+
+if (pixmap_priv-base.mapped_for_write) {
glamor_restore_pixmap_to_texture(pixmap);
}
diff --git a/glamor/glamor_priv.h b/glamor/glamor_priv.h
index 7f41025..24a3575 100644
--- a/glamor/glamor_priv.h
+++ b/glamor/glamor_priv.h
@@ -410,6 +410,12 @@ typedef struct glamor_pixmap_clipped_regions {
typedef struct glamor_pixmap_private_base {
glamor_pixmap_type_t type;
enum glamor_fbo_state gl_fbo;
+/**
+ * If devPrivate.ptr is non-NULL (meaning we're within
+ * glamor_prepare_access), determies whether we should re-upload
+ * that data on glamor_finish_access().
+ */
+bool mapped_for_write;
unsigned char is_picture:1;
unsigned char gl_tex:1;
glamor_pixmap_fbo *fbo;
--
1.9.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
