阿童木:GPU任务的抽象

如果你和我年纪相仿,你一定知道"鉄腕アトム"翻译过来是铁臂阿童木。其实,铁臂阿童木不光胳膊是铁的,不然他可能不能合理地站到地面上,或者要拿着大顶。。。所以阿童木和我们这章要关注的内容有什么关系,其实没啥关系。。。有毒吧,launch GPU程序的时候你又不需要拿着大顶。 当然,如果随便起个这个中二的名字作为章节名字,那太没有品味了。所以,其实,在Mali驱动里,对GPU任务的抽象class叫做atom。。。

可以猜到,应该有两种atom,一个是用户创建的要传给driver的(base_jd_atom_v2),一个是driver内部对任务的抽象(kbase_jd_atom)。在我开来这种设计最大的好处就是把和任务本身无关的信息都存在driver的抽象里,在base_jd_atom_v2里只有12个变量,然而在kbase_jd_atom里有五十多个变量,多出来的这些变量就是又硬件生成的,用户根本不想关心的玩意儿。

对于base_jd_atom_v2,最重要的一个变量就是jc,这个变量是个地址,指向前一章提到的那段GPU机器码。我没找到资料不难猜测,当host代码准备launch GPU代码的时候,就是造个base_jd_atom_v2,GPU代码用OpenCL啥的编好,拿这个jc一指,最后通过中断调用这个API。

同时,用户还可以指定一个prio,用来代表这个任务的priority。还有一个变量叫做atom_number,相当于这个atom的id,应该是程序自己决定的。当然,因为GPU允许异步执行,这就要考虑依赖的问题,所以用户可以把当前atom所依赖的atom(s)加到一个叫pre_dep的变量里。这个变量是个class,里面只有两个变量,一个是atom的id,一个是依赖的种类。只有当依赖都满足的时候,这个atom才会被(执行 || 提交到GPU里)。

花开两朵,各表一枝。对于kbase_jd_atom,就是driver眼中的任务了,既然是driver眼中的,那我们为什么要关心呢?所以就不讲了吧。。。好吧,这本书叫driver详解。

  1. 首先katom里有一个work_struct,就是Linux的work_queue里放的那个work_struct。

  2. 有一个时间戳,这个时间戳记录了这个atom是什么时候提交给GPU的

  3. kctx:指向这个atom属于哪个context,这个东西不在base_jd_atom_v2里,所以提交base_jd_atom_v2的时候需要把kctx也给传进去

  4. 有三个关于dependency的东西,dep_head存储了被这个atom block住的atoms,dep_item存储了和这个atom依赖相同东西的atoms,最后dep里有这个atom所依赖的两个atom

  5. 指向GPU机器码的jc和其复制softjob_data

  6. 还有其他许许多多的内容

我突然发现atom有很多关于softjob的问题,我决定先挖个坑,等弄明白了再来填坑。