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机制