-Yaong-

导航

 
 
WW-Mutexes
 
在GPU中一次Render可能会涉及到对多个buffer的引用。
所以在command buffer提交到GPU前,需要等到所有依赖的buffer可用。
因为这些buffer可能被多个设备或进程所共享,所以相比单个buffer,增加了deadlock的风险。
这不能简单地通过一个 buffer mutex锁来等待buffer可用,因为这些buffer通常受控于应用程序.
比如Vertex shader中用到的vertex data: input attributes buffer 和 vertex index buffer,或者是fragment shader中用到的texel buffer、uniform buffer等,以及用作render的frambuffer。
所以没有一个机制能保证这些buffer以相同的顺序出现在各个共享进程中。
为解决这样的问题linux kernel中引入了WW-Mutexes锁。
WW-Mutexes与mutex是本质上是相同的,加锁的方式也类似。
 
WW-Mutexes的工作机制大概是,首先将要引用的buffer的锁加入到一个list里面,然后依次对list中的锁进行上锁操作,对单个锁的获取可能会失败,即该锁已被其他人占用。
当出现锁获取失败时,接下来WW-Mutexes会有分两种情况来解决冲突:
1.如果当前正在加锁的进程(transaction)比已加锁的进程新(younger),那么当前进程的加锁操作会被终止,停止之前释放(unlock)已成功获取到的锁,然后等待重新对list的锁进行再次加锁操作。
2.如果当前正在加锁的进程(transaction)比已加锁的进程旧(older),那么当前进程会等待,直到占用该锁的进程释放锁。
 
举个例子:
A:
    lock-list: B0, B1, B2, B3
    locked:    B0, B1, B2
    locking:   B3
B:
    lock-list: B1, B3, B4
    locked:    B3
    locking:   B1
1.如上有A、B两个进程,假如B比A晚(younger)启动,B进程正在对B1进行加锁,但是B1已被A进程上锁了,所以B进程加锁失败,因为B比A新,所以B需要释放到它已获取到的锁B4,然后重新等待对B1,B3,B4的加锁。
2.相反,如果B比A早(older)启动,那么B对B1加锁失败后,B会等待,直到B1被A释放。接着看A的情况,A正在对B3进行加锁(假设A在B开始等待后对B3加锁),但B3已被B锁住,按同样的规则,这是A比B新,那么A要被中断,并释放掉已获取到的B0、B1、B2,并重新开始下一轮对B0, B1, B2, B3进行加锁。因为A释放掉B1,那么B就能停止等待,获取到B1了。一旦获取到B lock-list中所有buffer的锁后,B就能对这些buffer进行相应的操作,完毕后再释放掉所有的锁,A进程也就有机会重新获取到所需的锁了。
 
使用方法:
官方文档列举了3种用法,这里只列出一种,其他请参考:https://www.kernel.org/doc/html/latest/locking/ww-mutex-design.html
 
/* 静态初始化一个 ww_class */
static DEFINE_WW_CLASS(ww_class);
 
/* 要被加锁的对象,在其中嵌入 struct ww_mutex lock */
struct obj {
      struct ww_mutex lock;
      /* obj data */
};
 
/* 需要获取的对象组成的list */
struct obj_entry {
      struct list_head head;
      struct obj *obj;
};
 
int lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
{
      struct obj *res_obj = NULL;
      struct obj_entry *contended_entry = NULL;
      struct obj_entry *entry;
 
 
     /* 加锁前对ww_acquire_ctx进行初始化 */
      ww_acquire_init(ctx, &ww_class);
 
 
retry:
      /* 一次从list中取出要加锁的对象,并对其进行加锁操作 */
      list_for_each_entry (entry, list, head) {
              if (entry->obj == res_obj) {
                      res_obj = NULL;
                      continue;
              }
          /* 加锁操作,如果出现冲突,且当前进程较旧,会等待在 ww_mutex_lock()中,与mutex_lock()类似 */
              ret = ww_mutex_lock(&entry->obj->lock, ctx);
              if (ret < 0) {
            /* 加锁失败,并且当前进行较新,当前进行将被终止继续获取剩余的锁,记录下冲突对象 */
                      contended_entry = entry;
                      goto err;
              }
      }
 
      ww_acquire_done(ctx);
      return 0;
 
err:
      /* 在进行下一轮加锁前,释放掉已获取到的锁 */
      list_for_each_entry_continue_reverse (entry, list, head)
              ww_mutex_unlock(&entry->obj->lock); /* 与mutex_unlock类似 */
 
      if (res_obj)
              ww_mutex_unlock(&res_obj->lock);
 
      if (ret == -EDEADLK) {
        /* 在开始下一轮的加锁前,使用ww_mutex_lock_slow()获取上一轮有冲突的锁,ww_mutex_lock_slow()会一直休眠,直到该锁可用为止 */
              /* we lost out in a seqno race, lock and retry.. */
              ww_mutex_lock_slow(&contended_entry->obj->lock, ctx);
              res_obj = contended_entry->obj;
        /* 跳转到下一轮的加锁操作 */
              goto retry;
      }
      ww_acquire_fini(ctx);
 
      return ret;
}
 
void unlock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
{
    struct obj_entry *entry;
 
    list_for_each_entry (entry, list, head)
        ww_mutex_unlock(&entry->obj->lock);  //依次释放list中的锁
 
    ww_acquire_fini(ctx);
}
 
dma_resv
 
GEM object主要是提供了graphics memory manager,正是前文中提到的GPU buffer对象(linux kernel中还有其他的buffer管理对象)。
本文主要整理了GEM的中用到的同步方法,不对其他方面做讲解。
GEM中主要用到WW-Mutexes和dma-fence来做同步,而这两者被封装到dma_resv中。
而dma_resv实际上是提供了所谓的隐式同步(implicit synchronization、implicit fence)。
reservation object提供了管理共享和独占fence的机制。
一个reservation object上只能添加一个独占fence(通常对于写操作),或添加多个共享fence(读操作)。
这类似于RCU的概念,一个reservation object管理的对象能支持并发的read操作,但是只支持同时一个写入操作。
 
Dma-fence是用在kernel内部的跨设备(cross-device)的DMA操作同步原语,比如GPU向framebuffer做rendering,而displaying在读取framebuffer前需要确保GPU已完成rendering操作,即读操作之前,确保写操作已完成。
Dma-fence通常有两种状态,signaled 和 unsignaled。在这里,通常unsignaled表示buffer还在被使用,signaled表示buffer已使用完毕。
因为Dma-fence是为跨设备间的同步而设计,这里有多种使用dma-fence方式:
1、explicit fencing:单个dma-fence通过以文件描述符(file descriptor)的形式暴露给用户层,用户层可以把该文件描述符传递给其他进程,因为是对应用层可见的,所以叫这类dma-fence为explicit fencing。
2、implicit fencing:其实就是对用户层不可见的dma-fence,通常存储在dma_resv中,在通过dma_buf在内核中传递。
 
GEM buffer object的定义如下(省略了与本文无关的成员):
struct drm_gem_object {
    … …
  struct dma_resv *resv;
  struct dma_resv _resv;
    … …
};
 
resv
    Pointer to reservation object associated with the this GEM object.
    Normally (resv == &**_resv**) except for imported GEM objects.
_resv
    A reservation object for this GEM object.
    This is unused for imported GEM objects.
 
GEM中对WW-Mutexes和dma-fence是通过dma_resv来实现的,dma_resv的定义如下:
struct dma_resv {
    struct ww_mutex lock;
    seqcount_ww_mutex_t seq;
 
    struct dma_fence __rcu *fence_excl;
    struct dma_resv_list __rcu *fence;
};
 
我们最终要关注的对象实际上是dma_resv。
简单的说,我们关注的buffer对象,在这里就是一个GEM对象,而这个GEM对象的同步操作是由GEM中的dma_resv提供的。
因为在这片文章中,不会涉及buffer同步以为的内容(例如backing memory),所以接下来在讨论dma_resv时,实际上就是在讨论单个GEM对象的同步,也即是单个buffer对象的同步。
 
前文已将谈到,在GPU的操作中涉及到多buffer的同步互斥问题,需要一次性准备好GPU的pipeline上所需要的buffer。
当使用这组buffer时,很可能这组buffer也被其他人使用。
如果针对单个buffer加锁(如mutex),会有死锁的风险(deadlock),比如A、B两个进程都需要同时引用两个buffer,分别对两个buffer加锁,A获得buffer0,B获得buffer1,当A在对buffer1加锁就会死锁,同样的B也会在加锁buffer0时死锁。
所以就引入了WW-Mutexes来解决这样的冲突,Linux DRM中的GEM提供了对WW-Mutexes的支持。。
进一步,我们发现在GPU上,对buffer的操作有读有写,比如texture buffer、uniform buffer是只读的,framebuffer可读可写。
写操作必须是独占式的,但读操作却可以被共享,所以又引入了dma-fence来达到这样的目的。
dma_resv把WW-Mutexes和dma-fence相结合,达到多buffer间同步的最优化。
 
使用步骤:
kernel中已经做了很好的封装,涉及到几个函数的调用,我总结的步骤如下:
1、调用drm_gem_lock_reservations()获取GPU一次rendering所用到的buffer的锁ww_mutex
2、成功获取到所有buffer的ww_mutex锁后,针对每个buffer在GPU中的使用情况添加不同的dma-fence,
     如果GPU中会读取某个buffer,则通过函数dma_resv_add_shared_fence()添加一个共享dma-fence;
     如果GPU会写每个buffer,则通过函数dma_resv_add_excl_fence()添加一个独占的dma-fence。
      注意在调用dma_resv_add_excl_fence()前,需要确保在这之前添加的share fence均处于unsignaled状态,就是确保写之前,读操作已全比完成。
3、完成fence的添加后,调用drm_gem_unlock_reservations()释放这组buffer的ww_mutex
4、接下来,当其他进程或设备要对某个buffer做操作前,需要判断dma-fence的情况。
     假如我要读取framebuffer的内容用于屏幕显示,那就是读之前,需要确保写结束,调用函数dma_resv_get_excl_rcu(), 读取独占dma-fence,确保其为unsignaled状态。
     例如,我们看看KMS的atomic中的plane frambuffer 的操作:
     读取独占dma-fence:
  
  int drm_gem_fb_prepare_fb(struct drm_plane *plane,
                  struct drm_plane_state *state)
    {
        struct drm_gem_object *obj;
        struct dma_fence *fence;
 
        if (!state->fb)
            return 0;
 
        obj = drm_gem_fb_get_obj(state->fb, 0);
        fence = dma_resv_get_excl_rcu(obj->resv);
        drm_atomic_set_fence_for_plane(state, fence);
 
        return 0;
    }
 
     在KMS的atomic操作中,会等待独占dma-fence被signal,代码如下:
    
    int drm_atomic_helper_wait_for_fences(struct drm_device *dev,
                          struct drm_atomic_state *state,
                          bool pre_swap)
    {
        struct drm_plane *plane;
        struct drm_plane_state *new_plane_state;
        int i, ret;
 
 
        for_each_new_plane_in_state(state, plane, new_plane_state, i) {
            if (!new_plane_state->fence)
                continue;
 
 
            WARN_ON(!new_plane_state->fb);
 
 
            /*
             * If waiting for fences pre-swap (ie: nonblock), userspace can
             * still interrupt the operation. Instead of blocking until the
             * timer expires, make the wait interruptible.
             */
            ret = dma_fence_wait(new_plane_state->fence, pre_swap);
            if (ret)
                return ret;
 
 
            dma_fence_put(new_plane_state->fence);
            new_plane_state->fence = NULL;
        }
 
 
        return 0;
    }
 
代码简析:
函数drm_gem_lock_reservations()的加锁过程就是,上文中提到的ww_mutexes的典型用法代码如下:
int
drm_gem_lock_reservations(struct drm_gem_object **objs, int count,
              struct ww_acquire_ctx *acquire_ctx)
{
    int contended = -1;
    int i, ret;
 
    ww_acquire_init(acquire_ctx, &reservation_ww_class);
 
retry:
    if (contended != -1) {
        struct drm_gem_object *obj = objs[contended];
 
        ret = dma_resv_lock_slow_interruptible(obj->resv,
                                 acquire_ctx);
        if (ret) {
            ww_acquire_done(acquire_ctx);
            return ret;
        }
    }
 
    for (i = 0; i < count; i++) {
        if (i == contended)
            continue;
 
        ret = dma_resv_lock_interruptible(objs[i]->resv,
                                acquire_ctx);
        if (ret) {
            int j;
 
            for (j = 0; j < i; j++)
                dma_resv_unlock(objs[j]->resv);
 
            if (contended != -1 && contended >= i)
                dma_resv_unlock(objs[contended]->resv);
 
            if (ret == -EDEADLK) {
                contended = i;
                goto retry;
            }
 
            ww_acquire_done(acquire_ctx);
            return ret;
        }
    }
 
    ww_acquire_done(acquire_ctx);
 
    return 0;
}
 
参考文档:
 
posted on 2021-01-26 21:50  -Yaong-  阅读(193)  评论(0编辑  收藏