Android HardwareComposer中的fence机制

    最近在写HardwareComposer,这东西的主要功能简单来说,就是把SurfaceFlinger准备好的各个layer data送到需要的地方去,以aosp中hardware/samsung_slsi/exynos5/libhwc 这个hwc为例,就是把layer data送到/dev/graphics/fb0去显示.

    不过所谓的"sf准备好的layer",其实未必真的准备好了.

    举个例子来说,gralloc分配的一块buffer在apk和sf之间共享,apk作为buffer的producer,sf作为buffer的consumer.apk执行完必要的gl绘图操作后,会把buffer的控制权交给sf,sf再把buffer对应的handle交给hwc做compose,这个时候apk中gl的func虽然都已经return了,但是真正的操作可能还在gpu的queue里面,buffer的内容还没有更新.如果hwc把buffer信息送到fb driver后,fb driver马上就把buffer内容显示到画面上的话,看到的就是错误的画面.反过来也是一样,当画面的内容还在显示状态,apk又在同一块buffer上重新绘制,也会出现类似问题.所以,这就需要一个producer和consumer之间的同步机制,也就是本篇要讨论的fence.

    我们来看下fence在hwc是如何运用的,当sf有内容需要hwc去显示的时候,sf会call hwc的set函数(其实在这之前还会call prepare,不过prepare不会处理fence).set函数return之前不必等待每个layer真正的准备好,只要正确处理了fence,buffer在ready的时候会signal相关的fence,通知真正消费buffer data的人.

hardware/libhardware/include/hardware/hwcomposer.h

    int (*set)(struct hwc_composer_device_1 *dev,                size_t numDisplays, hwc_display_contents_1_t** displays);

其中hwc_display_contents_1_t是这样定义的(忽略和fence无关的部分):

typedef struct hwc_display_contents_1 {    int retireFenceFd;    size_t numHwLayers;    hwc_layer_1_t hwLayers[0];} hwc_display_contents_1_t;

    numHwLayers表示这次需要显示的layer个数,hwLyaers[0]是一个大小为0的数组,指向numHwLayers的下一个地址,sf在构建hwc_display_contents_1_t的时候会根据numHwLayers来分配大小为sizeof(hwc_display_contents_1_t)+numHwLayers*sizeof(hwc_layer_1_t)的memory,这样hwLyaers就指向了真正保存了numHwLayers个hwc_layer_1_t的地址.

    retireFenceFd需要在这次composition retire后被singal,对于physical display来说,retire的概念是:当下个画面替换掉本次画面的时候.对于virtual display来说,retire的概念是:当内容被完整的写进outbuffer,并可以被read的时候.总的来说就是本次composition的结果不再被需要的时候,就可以把hwc_display_contents_1_t标记为retire了.

    retireFenceFd控制的是整个composition,也就是整组的layer.

    再来看hwc_layer_1_t

typedef struct hwc_layer_1 {    ...    buffer_handle_t handle;    int acquireFenceFd;    int releaseFenceFd;    ...} hwc_layer_1_t;

    handle就是本layer对应的buffer.set函数被call到的时候并不知道buffer是否真正ready,acquireFenceFd会在buffer内容真正ready的时候被signal,hwc要负责close acquireFenceFd.set函数return之前并不能保证buffer内容已经使用完毕,不再需要,所以hwc需要负责为这个buffer构建一个fence,releaseFenceFd在set函数return之前被set起来,sf会等待releaseFenceFd被signal之后才会把buffer拿去重用,sf要负责close releaseFenceFd.

    acquireFenceFd和releaseFenceFd控制的是单个layer.

    仍然以hardware/samsung_slsi/exynos5/libhwc/为例,(简化code只保留和fence相关的部分,完整code请参考aosp):

static int exynos5_set(struct hwc_composer_device_1 *dev,        size_t numDisplays, hwc_display_contents_1_t** displays){    if (!numDisplays || !displays)        return 0;    exynos5_hwc_composer_device_1_t *pdev =            (exynos5_hwc_composer_device_1_t *)dev;    hwc_display_contents_1_t *fimd_contents = displays[HWC_DISPLAY_PRIMARY];    int fimd_err = 0;    if (fimd_contents)        fimd_err = exynos5_set_fimd(pdev, fimd_contents);    return fimd_err;}

    set函数拿到编号为HWC_DISPLAY_PRIMARY的hwc_display_contents_1_t,也就是andorid内建主显示屏需要显示的内容,call到exynos5_set_fimd.

static int exynos5_set_fimd(exynos5_hwc_composer_device_1_t *pdev,        hwc_display_contents_1_t* contents){    hwc_layer_1_t *fb_layer = NULL;    int err = 0;    int fence;    if (!err) {        fence = exynos5_post_fimd(pdev, contents);        if (fence < 0)            err = fence;    }    for (size_t i = 0; i < NUM_HW_WINDOWS; i++) {int dup_fd = dup(fence);        layer.releaseFenceFd = dup_fd;    }    contents->retireFenceFd = fence;    return err;}

    exynos5_post_fimd return了int fence,fence其实是个fd,hwc把这个fd dup了n次,赋值给每个layer的releaseFeceFd,最后在把fence本身赋值给整个layer组的retireFenceFd.也就是说,retireFenceFd和所有的releaseFenceFd对应到kernel中都是同一个file.截至目前为止,acqireFenceFd还没有出场,肯定还在exynos5_post_fimd 中.

dev->fd = open("/dev/graphics/fb0", O_RDWR);

static int exynos5_post_fimd(exynos5_hwc_composer_device_1_t *pdev,        hwc_display_contents_1_t* contents){    exynos5_hwc_post_data_t *pdata = &pdev->bufs;    struct s3c_fb_win_config_data win_data;    struct s3c_fb_win_config *config = win_data.config;    memset(config, 0, sizeof(win_data.config));    for (size_t i = 0; i < NUM_HW_WINDOWS; i++)        config[i].fence_fd = -1;    for (size_t i = 0; i < NUM_HW_WINDOWS; i++) {        int layer_idx = pdata->overlay_map[i];        if (layer_idx != -1) {            hwc_layer_1_t &layer = contents->hwLayers[layer_idx];            private_handle_t *handle =                    private_handle_t::dynamicCast(layer.handle);            exynos5_config_overlay(&layer, config[i], pdev);        }    }    int ret = ioctl(pdev->fd, S3CFB_WIN_CONFIG, &win_data);    for (size_t i = 0; i < NUM_HW_WINDOWS; i++)        if (config[i].fence_fd != -1)            close(config[i].fence_fd);    return win_data.fence;}

    每个layer对应一个config,所有的config组成win_data,exynos5_config_overlay会从每个layer中抽取config的需要的信息填写进cofnig,最后整个win_data作为参数,通过S3CFB_WIN_CONFIG ioctl送去fb0了,exynos5_post_fimd return的fence其实是经由fb driver处理后的win_data.fence.

    acqireFenceFd还是没有出现,但是我们注意到,在ioctl之前,每个config的fence_fd被设成-1,ioctl之后,又再次判断fence_fd,如果不是-1,就close它.config.fence_fd一定和acqireFenceFd有关!不过在这里就close fence_fd会不会有点太早了?这个fence不再需要了吗?不是说set函数返回之前不需要等待acquireFenceFd被signal吗?我们再进去exynos5_config_overlay看看.

static void exynos5_config_overlay(hwc_layer_1_t *layer, s3c_fb_win_config &cfg,        exynos5_hwc_composer_device_1_t *pdev){    private_handle_t *handle = private_handle_t::dynamicCast(layer->handle);    exynos5_config_handle(handle, layer->sourceCrop, layer->displayFrame,            layer->blending, layer->acquireFenceFd, cfg, pdev);}

static void exynos5_config_handle(private_handle_t *handle,        hwc_rect_t &sourceCrop, hwc_rect_t &displayFrame,        int32_t blending, int fence_fd, s3c_fb_win_config &cfg,        exynos5_hwc_composer_device_1_t *pdev){    uint32_t x, y;    uint32_t w = WIDTH(displayFrame);    uint32_t h = HEIGHT(displayFrame);    uint8_t bpp = exynos5_format_to_bpp(handle->format);    uint32_t offset = (sourceCrop.top * handle->stride + sourceCrop.left) * bpp / 8;    cfg.state = cfg.S3C_FB_WIN_STATE_BUFFER;    cfg.fd = handle->fd;    cfg.x = x;    cfg.y = y;    cfg.w = w;    cfg.h = h;    cfg.format = exynos5_format_to_s3c_format(handle->format);    cfg.offset = offset;    cfg.stride = handle->stride * bpp / 8;    cfg.blending = exynos5_blending_to_s3c_blending(blending);    cfg.fence_fd = fence_fd;}

    acquireFenceFd终于出现了,它作为每个layer对应的config的cfg.fence_fd,经由S3CFB_WIN_CONFIG  ioctrl送去了fb driver.既然送去了fb driver,那么fence的生死就由driver负责了,hwc不用再理会.所以上面exynos5_post_fimd 才把每个layer的config.fence_fd,也就是layer->acquireFenceFd给close掉了.

    至此,hwc中对于fence的处理流程就走完了,总结一下:

    1. hwc把所有的layer->acquireFenceFd一起送到fb driver后,就把layer->acquireFenceFd close,把fence的管理权交给fb driver.

    2. ioctl rentrun时,win_data.fence被driver填写为一个新的fd,这个fd被dup n次并赋值给每个layer的layer->releaseFenceFd.

    3. win_data.fence赋值给整个hwc_display_contents_1_t,也就是所有layer组合的retireFenceFd.

    4.之后releaseFenceFd和retaireFenceFd的生死就交给sf来负责了.

    接下来的讨论进入fd driver,请参考Android fb driver中的fence机制