刚才怎么发到it168的blog去了，cu的跳转有我呢? it168不能超过一万字，发不了，分了两篇

还是觉得这边好，发这边一篇。

kdrive的xvide的加速的实现。

首先xvideo本来也是在驱动里面实现的，实际上我们先要做一个驱动。

kdrive硬件加速驱动的实现，其实就是kaa的实现，kaa分xserver这边和driver这边，xserver这边会提供一种机制

这个机制就是当gc操作的时候会判断一下回调函数是否注册，如果注册就使用回调函数，如果没有注册就使用软件的实现，

而注册这个回调函数就是在kdrive的驱动里面来实现的。因为kdrive不能动态装载驱动，所以驱动都是直接编译到Xserver

里面的，也就是说编译出来的Xfbdev是直接带了驱动的。

我们先看看代码的布局，之前是在xserver 1.5.x的基础上来实现的，大概就以1.5.3来讲吧

关于kdrive和xserver的关系之前说过，kdrive是xserver的一种,xserver在xorg的代码树里面有好几种实现，但是大体的代码都是共用的

比如基本的事件处理，clip等等代码都是共用的。hw目录下面就是不同的xserver的实现。xorg只是其中一种，如前所说，kdrive和xorg有很多

代码是共用的，所以xorg的代码更新过快，kdrive更新过慢，导致kdrive的有很多事件处理有问题。

本来应该先说kaa的实现的，但是因为xivdeo的实现比较简单，所以先说。

我们先看看xvideo的工作流程，就是说xvideo到底是怎么发挥作用的。

xvideo的目的是为了把video或者frame输出直接输出到屏幕上面，尽量少的转存，尽量多的利用硬件加速，而xorg是管理最后输出的(目前是这样)

所以需要在xserver里面有一个扩展这个就是Xv的扩展了，

这里需要一个图片说明

我们看到最原始的数据无非是一个视频文件，我们先假定这个文件是一个mpeg4的文件。然后通过demux之后就有不同的数据流，比如音频，视频，还有其他的，

但是我们这里先只关注视频，视频流出来之后就经过解码，解码完成之后就成了一帧一帧的图片，和放电影的原理是一样的。然后我们就要把这个图片显示

到屏幕上面，最终的输出函数一般都是XPutImage,XvPutImage,XvShmPutImage类似这样的函数。

当然使用shm的版本会比不使用shm的版本要快很多了，Xshm本来也是Xserver的一个扩展，这个主要是为了减少数据的copy

一般来说写的好的播放器都会判断一些xserver是否支持shm扩展，如果支持，就会使用shm的函数。比如mplayer，gstreamer(xvimagesink)

因为Xserver这个框架是C/S模式的，说这个很好理解，但是很多人还是知其然不知其所以然，我们从原始的架构来理解。

原始的X是可以通过网络来传输的，但是因为这种模式我们现在用的不是很多了，除了ssh -X abc@192.168.1.100这样的用法之外，可能我们

很少会用到这样的远程传输，我们本机一般用的是unix socket。也就是说所有的请求，实际上是这样的，

我们编写应用程序里面会有XPutImage的函数，实际上这个函数是由libX11来提供的(如果我没有记错的话),XvSHmPutImage这样的函数是由libXext来实现的。

这个里面的代码实际上就是封装一个X的请求，然后通过Xsend发送出去。然后Xserver那边会dispatch这些消息，由对应的扩展或者函数来处理，因为这些Xext初始化

的时候会告诉Xserver这类消息由自己的扩展来处理。

所以想想如果是一个很大帧的数据，都走socket的话是很慢的，所以有了Xshm就好很多了，shm，和我们普通的shm是一样的，就是共享内存了，就是用户程序和

xserver共享一个内存空间，当用户程序填充帧的时候实际上就直接写到xserver的内存空间了(需要图片说明)，然后xserver可以直接显示出去，这样会节省很多空间

Ximage这个数据接口是有data指针的，但是如果是shm的版本就没有，里面会带一个地址。XshmImage.这些内容都是凭记忆写的，可能会有漏误

话说回来，Xvideo在xserver这边对应的处理流程。

xserver无非也会接收到XshmPutimage的请求，这个在Xserver里面xorg-server-1.5.3/Xext/shm.c里面实现的

static int

SProcShmPutImage(client)

ClientPtr client;

{

register int n;

REQUEST(xShmPutImageReq);

swaps(&stuff->length, n);

REQUEST_SIZE_MATCH(xShmPutImageReq);

swapl(&stuff->drawable, n);

swapl(&stuff->gc, n);

swaps(&stuff->totalWidth, n);

swaps(&stuff->totalHeight, n);

swaps(&stuff->srcX, n);

swaps(&stuff->srcY, n);

swaps(&stuff->srcWidth, n);

swaps(&stuff->srcHeight, n);

swaps(&stuff->dstX, n);

swaps(&stuff->dstY, n);

swapl(&stuff->shmseg, n);

swapl(&stuff->offset, n);

return ProcShmPutImage(client);

}

ProcShmPutImage这个函数会调用下面的函数下面调用的是XPutImage的注册回调函数了，

(*pGC->ops->PutImage) (pDraw, pGC, stuff->depth,

stuff->dstX, stuff->dstY,

stuff->totalWidth, stuff->srcHeight,

stuff->srcX, stuff->format,

shmdesc->addr + stuff->offset +

(stuff->srcY * length));

从dispatch开始看

Xext/xvdisp.c

#define XVCALL(name) Xv##name

ProcXvPutImage

最后调用的是这个，

return XVCALL(diPutImage)(client, pDraw, pPort, pGC,

stuff->src_x, stuff->src_y,

stuff->src_w, stuff->src_h,

stuff->drw_x, stuff->drw_y,

stuff->drw_w, stuff->drw_h,

pImage, (unsigned char*)(&stuff[1]), FALSE,

stuff->width, stuff->height);

实际上是下面的函数XvdiPutImage

Xext/xvmain.c这个函数是xvideo的具体实现,当然xorg和kdrive实际上都用这里的代码。

XvdiPutImage

调用下面的回调函数了

return (* pPort->pAdaptor->ddPutImage)(client, pDraw, pPort, pGC,

src_x, src_y, src_w, src_h,

drw_x, drw_y, drw_w, drw_h,

image, data, sync, width, height);

我们要实现的自然就是ddPutImage了。

这个函数就是gc注册的了，这里我们使用kdrive的框架，自然就是kaa去注册的了。

然后kaa的具体实现，也就是我们的驱动，会注册kaa的函数。

所有kdrive的函数都在

xorg-server-1.5.3/hw/kdrive

ailantian@vax:/mnt/sdb1/ubd/soft/xorg/temp/xorg-server-1.5.3/hw/kdrive$ ls

ati    ephyr  fake   i810   mach64       Makefile.in  neomagic  pm2   sdl     smi  vesa

chips  epson  fbdev  linux  Makefile.am  mga          nvidia    r128  sis300  src  via

ailantian@vax:/mnt/sdb1/ubd/soft/xorg/temp/xorg-server-1.5.3/hw/kdrive$ pwd

这下面基本每个目录都是一个driver，比如有intel 810, ati,等等，很多驱动了。

kaa这个框架是在hw/kdrive/kaa.c里面实现的，至于xvideo的框架的实现就是在kxv里面来实现的了。

我们的驱动里面通过一定的机制实际上会调用到下面这个函数，

KdXVInitAdaptors

pa->pScreen = pScreen;

pa->ddAllocatePort = KdXVAllocatePort;

pa->ddFreePort = KdXVFreePort;

pa->ddPutVideo = KdXVPutVideo;

pa->ddPutStill = KdXVPutStill;

pa->ddGetVideo = KdXVGetVideo;

pa->ddGetStill = KdXVGetStill;

pa->ddStopVideo = KdXVStopVideo;

pa->ddPutImage = KdXVPutImage;

pa->ddSetPortAttribute = KdXVSetPortAttribute;

pa->ddGetPortAttribute = KdXVGetPortAttribute;

pa->ddQueryBestSize = KdXVQueryBestSize;

pa->ddQueryImageAttributes = KdXVQueryImageAttributes;

实际上我们只关注

pa->ddPutImage = KdXVPutImage;

这个函数是在xserver的xvideo扩展里面被调用的。

也就是说kxv实际上是一个框架，然后会有人来填充KdXVPutImage这样的回调函数的，这个就是我们kaa驱动里面要做的事情了。

其实i810等等这些驱动可以直接参考，我们可以直接copy一下一个目录，然后作为自己驱动开发的基础，然后改改makefile就行了。

这里还是以ati作为例子来讲解吧，我自己的代码写的比较乱，可能还有其他一些问题，所以不便贴出来。

一般来说xvideo的实现都是在xxx_video.c里面实现的，比如我们看ati的，就是在ati_video.c里面了。

其实代码量比较小。

其实输出出去，最终还是这个函数，

ATIPutImage,然后这个函数一般会调用DisplayVideo这样的函数，不过这个只是开发者的习惯而已。

那么先看看框架。

以ati为例，注册回调函数从哪里开始，

grep一下代码就知道了，实际上是这个。

ATISetupImageVideo

ATIInitVideo调用ATISetupImageVideo

看个人的喜好了，反正是要注册这些回调函数了，

下面是关键代码,所谓的框架都在这里了。

static KdVideoAdaptorPtr

ATISetupImageVideo(ScreenPtr pScreen)

{

KdScreenPriv(pScreen);

ATIScreenInfo(pScreenPriv);

KdVideoAdaptorPtr adapt;

ATIPortPrivPtr pPortPriv;

int i;

atis->num_texture_ports = 16;

adapt = xcalloc(1, sizeof(KdVideoAdaptorRec) + atis->num_texture_ports *

(sizeof(ATIPortPrivRec) + sizeof(DevUnion)));

if (adapt == NULL)

return NULL;

adapt->type = XvWindowMask | XvInputMask | XvImageMask;

adapt->flags = VIDEO_CLIP_TO_VIEWPORT;

adapt->name = "ATI Texture Video";

adapt->nEncodings = 1;

adapt->pEncodings = DummyEncoding;

adapt->nFormats = NUM_FORMATS;

adapt->pFormats = Formats;

adapt->nPorts = atis->num_texture_ports;

adapt->pPortPrivates = (DevUnion*)(&adapt[1]);

pPortPriv =

(ATIPortPrivPtr)(&adapt->pPortPrivates[atis->num_texture_ports]);

for (i = 0; i < atis->num_texture_ports; i++)

adapt->pPortPrivates[i].ptr = &pPortPriv[i];

adapt->nAttributes = NUM_ATTRIBUTES;

adapt->pAttributes = Attributes;

adapt->pImages = Images;

adapt->nImages = NUM_IMAGES;

adapt->PutVideo = NULL;

adapt->PutStill = NULL;

adapt->GetVideo = NULL;

adapt->GetStill = NULL;

adapt->StopVideo = ATIStopVideo;

adapt->SetPortAttribute = ATISetPortAttribute;

adapt->GetPortAttribute = ATIGetPortAttribute;

adapt->QueryBestSize = ATIQueryBestSize;

adapt->PutImage = ATIPutImage;

adapt->ReputImage = ATIReputImage;

adapt->QueryImageAttributes = ATIQueryImageAttributes;

/* gotta uninit this someplace */

REGION_INIT(pScreen, &pPortPriv->clip, NullBox, 0);

atis->pAdaptor = adapt;

xvBrightness = MAKE_ATOM("XV_BRIGHTNESS");

xvSaturation = MAKE_ATOM("XV_SATURATION");

return adapt;

}

看看上面最重要的函数就是注册了    adapt->PutImage = ATIPutImage;

这个函数在最后就会被调用到。

大家可能会问这个adapt怎么会和上面的KdXVPutImage打上关系，这个自然是要注册的。

KdXVScreenInit->KdXVInitAdaptors

adaptorPriv->flags = adaptorPtr->flags;

adaptorPriv->PutVideo = adaptorPtr->PutVideo;

adaptorPriv->PutStill = adaptorPtr->PutStill;

adaptorPriv->GetVideo = adaptorPtr->GetVideo;

adaptorPriv->GetStill = adaptorPtr->GetStill;

adaptorPriv->StopVideo = adaptorPtr->StopVideo;

adaptorPriv->SetPortAttribute = adaptorPtr->SetPortAttribute;

adaptorPriv->GetPortAttribute = adaptorPtr->GetPortAttribute;

adaptorPriv->QueryBestSize = adaptorPtr->QueryBestSize;

adaptorPriv->QueryImageAttributes = adaptorPtr->QueryImageAttributes;

adaptorPriv->PutImage = adaptorPtr->PutImage;

adaptorPriv->ReputImage = adaptorPtr->ReputImage;

portPriv->AdaptorRec = adaptorPriv;

这个函数指针都放在了AdaptorRec这个里面，而这个是在KdXVXXXX函数里面被调用的。

比如

KdXVPutImage

到输出的时候就会尝试调用这个注册的回调函数了。

ret = (*portPriv->AdaptorRec->PutImage)(portPriv->screen, pDraw,

src_x, src_y, WinBox.x1, WinBox.y1,

src_w, src_h, drw_w, drw_h, format->id, data, width, height,

sync, &ClipRegion, portPriv->DevPriv.ptr);

而这个回调函数就是我们之前ATISetupImageVideo里面注册的函数，通过一系列周转到这里来的。

回到正题，只看最重要的部分，如何硬件加速输出的。其实看代码grep一下，肯定是和寄存器相关，或者mmio相关的，因为老的框架都是使用mmio的。

ATIPutImage里面加入了Xrandr的处理，这个我们可以先不管，主要是屏幕旋转会造成问题，所以需要处理一下，不过我们如果不旋转可以不关注这个代码了。

最关键的代码如下我们解码出来的图片是在内存里面，但是实际上我们要显示出去，必须放到显存里面，这里我不想讲kaa的内存管理了，偏离标题了，

if (pPortPriv->off_screen == NULL) {

pPortPriv->off_screen = KdOffscreenAlloc(screen->pScreen,

size * 2, 64, TRUE, ATIVideoSave, pPortPriv);

if (pPortPriv->off_screen == NULL)

return BadAlloc;

}

反正就是先我们要在显存里面划拨一个区域来存放这个图片才行。

下面有一段pixmap的判断，这个先不说，

总之，我们必须保证这个东西是在显存里面，无论是不是offscreen的。

然后就是下面的代码了，

switch(id) {

case FOURCC_YV12:

case FOURCC_I420:

top &= ~1;

nlines = ((((rot_y2 + 0xffff) >> 16) + 1) & ~1) - top;

KdXVCopyPlanarData(screen, buf, pPortPriv->src_addr, randr,

srcPitch, srcPitch2, dstPitch, rot_src_w, rot_src_h,

height, top, left, nlines, npixels, id);

break;

case FOURCC_UYVY:

case FOURCC_YUY2:

default:

nlines = ((rot_y2 + 0xffff) >> 16) - top;

KdXVCopyPackedData(screen, buf, pPortPriv->src_addr, randr,

srcPitch, dstPitch, rot_src_w, rot_src_h, top, left,

nlines, npixels);

break;

}

这个代码实际上是用来进行数据格式的转换的，也就是说，其实显卡所支持的硬件加速的格式是有限的，如果这个格式不被硬件所支持的话，我们就需要进行软件的

格式转换，这里xserver处理的有点死板，xserver到最后的输出的时候只支持两种格式，所以所有的格式都会转换成那两种格式，如果没有记错的话

应该是YVYU,VYUY,也就是说xserver目前的框架，是将数据封装成这两个格式，然后给硬件的，当然，这个驱动是自己实现的，一般来说，硬件支持很多种格式，

还有我们看到上面的代码，从user application传递过来的之后四种格式，这个是因为我们的驱动只注册了四种格式，也就是说我们只支持这四种格式，

类似mplayer会通过函数来查询当前的驱动到底支持哪几种格式，xvinfo这个x自带的工具也可以看。

注册格式是在这个地方，如果硬件支持更多的比如NV12,NV21等可以加在这里，好像一般的嵌入式的处理器如果有2d处理的话，都会支持。

static KdImageRec Images[NUM_IMAGES] =

{

XVIMAGE_YUY2,

XVIMAGE_YV12,

XVIMAGE_I420,

XVIMAGE_UYVY

};

xserver默认只支持这几个fourcc，如果要更多，可以从别的驱动里面抄这些定义，或者抄mplayer或者pixman里面都有这些fourcc的定义。因为很多格式还没有被

标准化。

数据pack完成之后自然就是发送给硬件显示了。

这个就比较简单了，因为我们有一个缓冲区，这个缓冲区已经在显存里面了，我们要显示到屏幕的某个地方。

注意offscreen和online screen的区别，比如我们有一个显卡，显存500M，实际上只有很小一部分空间是对应在屏幕上面的。

一般来说，显卡操作显存，是比较快的，有各种不同的技术实现，各家也不一样。但是比内存是要快的，或者至少也要和内存的速度差不多，大块数据的搬运会比较快一些。

比如要从offscreen搬运到online screen，其实嵌入式来说，显存也是内存，划拨一块而已，但是这个操作一般不需要cpu参与了。

好，我们看看显示的过程，

一般驱动程序会单独写一个函数来处理这个过程。

这里其实只有两个需要注意的地方，一个就是clip的处理，一个就是composite的处理。

虽然说xvideo本身的设计是和composite背离的，不过xvideo也可以直接输出到一个texure或者是一个pixmap里面。因为无论是什么方式，无非是一块显存。

R128DisplayVideo

我们看看这个实现。

BoxPtr pBox = REGION_RECTS(&pPortPriv->clip);

int nBox = REGION_NUM_RECTS(&pPortPriv->clip);

这里是计算clip的，比如我们播放一个视频的时候，这个时候有菜单盖住屏幕，这样我们的输出区域就被剪切成多个区域了，2个或者说个等等。

我们就只能按小块输出了，每块单独输出，但是还是硬件加速的，我们看看循环就知道了。

while (nBox--) {

int srcX, srcY, dstX, dstY, srcw, srch, dstw, dsth;

dstX = pBox->x1 + dstxoff;

dstY = pBox->y1 + dstyoff;

dstw = pBox->x2 - pBox->x1;

dsth = pBox->y2 - pBox->y1;

srcX = (pBox->x1 - pPortPriv->dst_x1) *

pPortPriv->src_w / pPortPriv->dst_w;

srcY = (pBox->y1 - pPortPriv->dst_y1) *

pPortPriv->src_h / pPortPriv->dst_h;

srcw = pPortPriv->src_w - srcX;

srch = pPortPriv->src_h - srcY;

BEGIN_DMA(6);

OUT_RING(DMA_PACKET0(R128_REG_SCALE_SRC_HEIGHT_WIDTH, 2));

OUT_RING_REG(R128_REG_SCALE_SRC_HEIGHT_WIDTH,

(srch << 16) | srcw);

OUT_RING_REG(R128_REG_SCALE_OFFSET_0, pPortPriv->src_offset +

srcY * pPortPriv->src_pitch + srcX * 2);

OUT_RING(DMA_PACKET0(R128_REG_SCALE_DST_X_Y, 2));

OUT_RING_REG(R128_REG_SCALE_DST_X_Y, (dstX << 16) | dstY);

OUT_RING_REG(R128_REG_SCALE_DST_HEIGHT_WIDTH,

(dsth << 16) | dstw);

END_DMA();

pBox++;

}

里面的OUT_RING我们就不看了，简单点理解，就是硬件输出。

各家硬件不一样，这里的目的是一样的，就是输出区域。nBox就是我们区域的个数了。

我们要把buffer输出到一个指定的区域，指定的偏移就可以了。

至于composite，我们无非是要指定输出的区域就行了，这个区域如果不在online screen，我们就输出到pixmap了。

然后composite会管理输出，可能是windowmanager做这个或者是xcompmgr类似这样的程序。

DamageDamageRegion(pPortPriv->pDraw, &pPortPriv->clip);

这个是需要的。xv的框架输出，我们需要汇报一下，我们写了这个区域，如果有人也在使用这块区域，就需要知道这个事情。

所以实际上xv的框架涉及到的扩展比较多

Xv,Xcomposite,Xdamage,Xfixes,

大体上就是这样了，其他的函数都是一些辅助的函数，直接照抄就行了。

另外要说明的一点就是。各种不同的flag的作用。

VIDEO_CLIP_TO_VIEWPORT等等，这个是根据不同的显示模式来设置的。

overlay和texture是不一样的，overlay在现在好像用的很少了，不过因为是硬件的支持，可能比texture会快一些，毕竟一个单独的layer操作

起来加上硬件的alpha blending会快的多，而texture的输出，完全靠显卡，感觉现在的显卡虽然很强了，但是面对大量的数据的alpha blending

无论是从显存大小，还是数据传输还是计算能力，都还是不够的。pc如此，嵌入式更如此。

想想现在都是大分辨率1440x900这个是一般的小屏幕了，24bit depth,然后还要加上composite，需求加倍。内存占用就很多了，还有就是所有的窗口都要先

offscreen render一下，然后再说alpha blending，很慢，我也不知道composite有什么好，为了酷炫，就要付出更多的代价。

唉，用的是fcitx的全拼打字，还是有点慢的，上面的东西写了一个半小时，其他事情也还比较多

kaa不知道什么时候写了。

kdriver+kaa+kxv

xorg+exa+xv

两个框架其实是类似的，xorg扩展性更强一些，可以动态装载。

xorg的input 自动探测也比较简单，还像说说。evdev统一天下还需时日。

晕，输入居然多余的万字了，我太能了:)

看来我写小说还挺快，一个半小时能超过一万字呢

漏掉一点就是为什么要使用xvideo

这个之前的文章说过，就是我们从mpeg4或者h264等等文件解码出来的实际上是yuv的数据，比如可能是yuv422的

但是我们的屏幕实际上是rgb的，不同的系统不一样了，比如我们的pc一般rgb888的，对于嵌入式来说可能会选择rgb565这样的，所以就需要转换，

这个yuv转rgb是需要很多计算量的，另外就是硬件缩放，比如解码出来的图像是vga或者wvga的，我们要全屏显示的时候就需要缩放，这个时候也非常占用cpu。

没记错的话，应该都是浮点运算。虽然coretex-a8等等都有了vfp等等指令，但是实际上，这点性能还是远远不够。还有就是xvideo的设计就是为了快速的输出，

所以从框架上来说是很精简的，为了快速显示而设计的。

不过有一点要注意就是profile,我们一般会profile一下，看看这个xvideo的实现性能在什么地方，因为现在输出都是由硬件来做的，所以cpu占用很少，

后来用oprofile看的时候发现其实cpu占用最多的地方居然在数据封装的地方，也就是我们把用户程序传递过来的数据封装成硬件支持的格式。

这个地方还是可以用汇编优化一下的。改善很明显。毕竟是驱动里面最"热"的地方。

不过后来因为迁移到了xorg，所以kdrive这边的实现，包括kaa的驱动和xvideo的实现都没再继续用了

xorg这边有芯片提供商在开发xorg的dri+exa的driver，所以我就没再做这个工作了。

阅读(2453) | 评论(1) | 转发(0) |