frederik
/
xserver
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Remove the exaAsyncPixmapGCOps mostly-unaccelerated ops vector, and always 

plug in the accelerated one, even if the destination pixmap is
    currently offscreen. This was a leftover from when kaa originally got
    accelerated offscreen pixmap support, and its only concievable use was
    to avoid a little overhead on ops to in-system pixmaps that weren't
    going to get migrated. At this point, we probably care more about just
    getting everything accelerated that we easily can, which should happen
    with the new migration support.
This commit is contained in:
Eric Anholt 2006-03-30 21:44:36 +00:00
parent b9203dc068
commit 759033703c
4 changed files with 18 additions and 49 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
ChangeLog
View File

@ -1,3 +1,17 @@
2006-03-30 Eric Anholt <anholt@FreeBSD.org>
* exa/exa.c: (exaValidateGC):
* exa/exa_priv.h:
* exa/exa_unaccel.c: (exaGetPixmapFirstPixel):
Remove the exaAsyncPixmapGCOps mostly-unaccelerated ops vector, and
always plug in the accelerated one, even if the destination pixmap is
currently offscreen. This was a leftover from when kaa originally got
accelerated offscreen pixmap support, and its only concievable use
was to avoid a little overhead on ops to in-system pixmaps that weren't
going to get migrated. At this point, we probably care more about just
getting everything accelerated that we easily can, which should happen
with the new migration support.
2006-03-30 Eric Anholt <anholt@FreeBSD.org>
* exa/exa_accel.c: (exaCopyWindow):

21
exa/exa.c
View File

@ -339,30 +339,15 @@ exaFinishAccess(DrawablePtr pDrawable, int index)
}
/**
* exaValidateGC() chooses between the accelerated and unaccelerated GC Ops
* vectors.
*
* The unaccelerated (exaAsyncPixmapGCOps) vector is chosen if the drawable is
* offscreen. This means that operations that affect only that drawable will
* not result in migration of the pixmap. However, exaAsyncPixmapGCOps does use
* the accelerated operations for the Copy* functions, because the other
* drawable involved might be in framebuffer and require synchronization before
* accessing it. This means that for the Copy* functions, even using
* exaAsyncPixmapGCOps may result in migration, and therefore acceleration.
*
* Because of how nonintuitive exaAsyncPixmapGCOps is, and the fact that its
* only use is for dubious performance reasons (and probably just historical
* reasons), it is likely to go away in the future.
* exaValidateGC() sets the ops to EXA's implementations, which may be
* accelerated or may sync the card and
*/
static void
exaValidateGC (GCPtr pGC, Mask changes, DrawablePtr pDrawable)
{
fbValidateGC (pGC, changes, pDrawable);
if (exaDrawableIsOffscreen (pDrawable))
pGC->ops = (GCOps *) &exaOps;
else
pGC->ops = (GCOps *) &exaAsyncPixmapGCOps;
pGC->ops = (GCOps *) &exaOps;
}
static GCFuncs exaGCFuncs = {

2
exa/exa_priv.h
View File

@ -301,7 +301,7 @@ void
exaGetSpans (DrawablePtr pDrawable, int wMax, DDXPointPtr ppt, int *pwidth,
int nspans, char *pdstStart);
extern const GCOps exaOps, exaAsyncPixmapGCOps;
extern const GCOps exaOps;
#ifdef RENDER
void

30
exa/exa_unaccel.c
View File

@ -362,33 +362,3 @@ exaGetPixmapFirstPixel (PixmapPtr pPixmap)
return pixel;
}
/*
* Only need to stall for CopyArea/CopyPlane, but we want to have the chance to
* do migration for CopyArea.
*/
const GCOps exaAsyncPixmapGCOps = {
ExaCheckFillSpans,
ExaCheckSetSpans,
ExaCheckPutImage,
exaCopyArea,
ExaCheckCopyPlane,
ExaCheckPolyPoint,
ExaCheckPolylines,
ExaCheckPolySegment,
ExaCheckPolyRectangle,
ExaCheckPolyArc,
ExaCheckFillPolygon,
ExaCheckPolyFillRect,
ExaCheckPolyFillArc,
miPolyText8,
miPolyText16,
miImageText8,
miImageText16,
ExaCheckImageGlyphBlt,
ExaCheckPolyGlyphBlt,
ExaCheckPushPixels
#ifdef NEED_LINEHELPER
,NULL
#endif
};