OGL Api
api
glFlush
-> cmClush pContext中保存了command buffer，这个command buf是由kernel的cmbufmgr管理的
在GetSpace时，如果request的space大于free space，就会立即调用cmFlush。其他位置的cmFlush都是手动call的
fence cb
callback是一个结构体 包含了回调函数 能对回调函数执行不同的额外操作，这个额外操作就是这个array_callback 对于syncobject，回调函数也要执行同步到syncobject的操作
kernel - usermode 同步机制
在usermode叫做syncobject对应到kernel就是dma-fence。 dma-fence的fops有两个重要的成员：signaled和enable_signaling,signaled函数用于检测fence是否被signal。在标准kernel的drm中，第一次wait_fence就会call两次这个函数，如果fence回不来，就调enable_signaling函数将目的task挂到回调结构体中（cb）。在执行dma_fence_signal()会call cb和目的函数，实现cpu的异步，而不是死等。
wait cpu / wait gpu
zx_gem_object_fence_await 当cpu操作bo 或者bo的allocation正在使用无法更新时，死等fence回来。 zx_get_bo_wait_fences 在下task之前将bo需要等的fence全部拿出来，在dma_fence_driver里去等。
fence_id
关于hardware的fence id,每个engine单独++。这个只是hardware上使用的，存在task_dma里的，供私有driver和中断识别的。原生kernel的dma_fence结构体并没有fence_id，通过handle或者list_ptr能访问到。
fence type
在mapping和dmatask都在一个ringbuffer时，mapping和page遵循先来后到的原则，driver code永远保证先mapping在下dma task。这时hardware的fence一部分来自bo的wait fence，另一部分来自syncobject，都是来自usermode。
- bo fence :Bo的wait fence来自本身的bo write-read操作，在add fence和attach fence是会加读fence和写fence。wait的时候get fence只get读fence就好了。
- syncobject fence :而syncobject来自user下发的syncobject 如果需要等其他bo的fence回来，则需要先get bo的fence再get syncobject的fence。
special case：当mapping和dmatask不在同一个ringbuffer时，kernelmode通过下dma task前查询mapping的fence是否回来。 例如 dce task_fence并不写入csp的wait_fences中，而是直接调wait_fence确保dce操作执行完成。而普通的bo fence，在下task前会检查can fence是否回来。
顶层的VAO VBO
创建使用glGen buffers arrays只是在GL context中分配了几个序数，如果没有管理器（就是分配序数的结构）则创建，其他什么都不做
bind初始化buffer或者arrays的顶层information，一般是来根据不同的GL api和target参数，决定GL context的touch位置和属性. VAO仅在GL层，没有到server层，VAO的Update属性传到server层就是操作VBO。所以VBO在bind时如果Context中没有VAO会给一个默认对象。