linux GPU上多个buffer间的同步 —— ww_mutex、dma-fence的使用 笔记

原文链接：https://www.cnblogs.com/yaongtime/p/14111134.html

 

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;

}

 

参考文档：

https://www.kernel.org/doc/html/latest/locking/ww-mutex-design.html

https://www.kernel.org/doc/html/latest/gpu/drm-mm.html