Android HardwareComposer中的fence机制

转自：http://blog.csdn.net/ear5cm/article/details/45080305

      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

[cpp]   view plain  copy

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

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

[cpp]   view plain  copy

1. typedef struct hwc_display_contents_1 {  
2.     int retireFenceFd;  
3.     size_t numHwLayers;  
4.     hwc_layer_1_t hwLayers[0];  
5.   
6. } 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

[cpp]   view plain  copy

1. typedef struct hwc_layer_1 {  
2.     ...  
3.     buffer_handle_t handle;  
4.     int acquireFenceFd;  
5.     int releaseFenceFd;  
6.     ...  
7. } 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):

[cpp]   view plain  copy

1. static int exynos5_set(struct hwc_composer_device_1 *dev,  
2.         size_t numDisplays, hwc_display_contents_1_t** displays)  
3. {  
4.     if (!numDisplays || !displays)  
5.         return 0;  
6.   
7.     exynos5_hwc_composer_device_1_t *pdev =  
8.             (exynos5_hwc_composer_device_1_t *)dev;  
9.     hwc_display_contents_1_t *fimd_contents = displays[HWC_DISPLAY_PRIMARY];  
10.     int fimd_err = 0;  
11.   
12.     if (fimd_contents)  
13.         fimd_err = exynos5_set_fimd(pdev, fimd_contents);  
14.     return fimd_err;  
15. }  

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

[cpp]   view plain  copy

1. static int exynos5_set_fimd(exynos5_hwc_composer_device_1_t *pdev,  
2.         hwc_display_contents_1_t* contents)  
3. {  
4.     hwc_layer_1_t *fb_layer = NULL;  
5.     int err = 0;  
6.   
7.     int fence;  
8.     if (!err) {  
9.         fence = exynos5_post_fimd(pdev, contents);  
10.         if (fence < 0)  
11.             err = fence;  
12.     }  
13.     for (size_t i = 0; i < NUM_HW_WINDOWS; i++) {  
14.     int dup_fd = dup(fence);  
15.         layer.releaseFenceFd = dup_fd;  
16.     }  
17.     contents->retireFenceFd = fence;  
18.   
19.     return err;  
20. }  

    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 中.

[cpp]   view plain  copy

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

[cpp]   view plain  copy

1. static int exynos5_post_fimd(exynos5_hwc_composer_device_1_t *pdev,  
2.         hwc_display_contents_1_t* contents)  
3. {  
4.     exynos5_hwc_post_data_t *pdata = &pdev->bufs;  
5.     struct s3c_fb_win_config_data win_data;  
6.     struct s3c_fb_win_config *config = win_data.config;  
7.   
8.     memset(config, 0, sizeof(win_data.config));  
9.     for (size_t i = 0; i < NUM_HW_WINDOWS; i++)  
10.         config[i].fence_fd = -1;  
11.   
12.     for (size_t i = 0; i < NUM_HW_WINDOWS; i++) {  
13.         int layer_idx = pdata->overlay_map[i];  
14.         if (layer_idx != -1) {  
15.             hwc_layer_1_t &layer = contents->hwLayers[layer_idx];  
16.             private_handle_t *handle =  
17.                     private_handle_t::dynamicCast(layer.handle);  
18.   
19.             exynos5_config_overlay(&layer, config[i], pdev);  
20.         }  
21.     }  
22.       
23.     int ret = ioctl(pdev->fd, S3CFB_WIN_CONFIG, &win_data);  
24.     for (size_t i = 0; i < NUM_HW_WINDOWS; i++)  
25.         if (config[i].fence_fd != -1)  
26.             close(config[i].fence_fd);  
27.     return win_data.fence;  
28. }  

    每个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看看。

[cpp]   view plain  copy

1. static void exynos5_config_overlay(hwc_layer_1_t *layer, s3c_fb_win_config &cfg,  
2.         exynos5_hwc_composer_device_1_t *pdev)  
3. {  
4.     private_handle_t *handle = private_handle_t::dynamicCast(layer->handle);  
5.     exynos5_config_handle(handle, layer->sourceCrop, layer->displayFrame,  
6.             layer->blending, layer->acquireFenceFd, cfg, pdev);  
7. }  

[cpp]   view plain  copy

1. static void exynos5_config_handle(private_handle_t *handle,  
2.         hwc_rect_t &sourceCrop, hwc_rect_t &displayFrame,  
3.         int32_t blending, int fence_fd, s3c_fb_win_config &cfg,  
4.         exynos5_hwc_composer_device_1_t *pdev)  
5. {  
6.     uint32_t x, y;  
7.     uint32_t w = WIDTH(displayFrame);  
8.     uint32_t h = HEIGHT(displayFrame);  
9.     uint8_t bpp = exynos5_format_to_bpp(handle->format);  
10.     uint32_t offset = (sourceCrop.top * handle->stride + sourceCrop.left) * bpp / 8;  
11.   
12.     cfg.state = cfg.S3C_FB_WIN_STATE_BUFFER;  
13.     cfg.fd = handle->fd;  
14.     cfg.x = x;  
15.     cfg.y = y;  
16.     cfg.w = w;  
17.     cfg.h = h;  
18.     cfg.format = exynos5_format_to_s3c_format(handle->format);  
19.     cfg.offset = offset;  
20.     cfg.stride = handle->stride * bpp / 8;  
21.     cfg.blending = exynos5_blending_to_s3c_blending(blending);  
22.     cfg.fence_fd = fence_fd;  
23. }  

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