xorg 硬件加速浅析 系列 kdrive的xvide的加速的实现

刚才怎么发到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，所以我就没再做这个工作了。