android - 计算任意大小的 3D 体积的推荐方法

Question

提出我的问题:

我正在编写自定义卷积(用于 CNN)，其中任意大小的 HxWxD 输入量与 FxFxD 过滤器进行卷积。 D 可以是 3 或 4，但也可以更多。我是 RenderScript 的新手，目前正在研究可能创建一个可以在未来使用的框架的方法，所以我不想以一种可能很快就会被弃用的方式结束使用 API。我现在的目标是 23，但可能需要在某个时候回到 18-19，这有待讨论。

看来，如果我定义一个 3D 分配并在内核中使用 float 作为输入参数的类型，内核会访问每个元素，也沿着 Z 轴。像这样:

内核:

void __attribute__((kernel)) convolve(float in, uint32_t x, uint32_t y, uint32_t z){
    rsDebug("x y z: ", x, y, z);
}

Java:

Allocation in;
Type.Builder tb = new Type.Builder(mRS, Element.F32(mRS));
Type in_type = tb.setX(W).setY(H).setZ(D).create();
in = Allocation.createTyped(mRS, in_type);
//...
mKonvoScript.forEach_convolve(in);

当 W=H=5 且 D=3 时，3D 体积中有 75 个 float 。运行程序打印 75 个输出:

x y: {0.000000, 0.000000, 0.000000} x y: {1.000000, 0.000000, 0.000000} ... x y: {0.000000, 0.000000, 1.000000} x y: {1.000000, 0.000000, 1.000000} ...

等等

该模式重复 3x25 次。

OTOH 引用文献不清楚 z 坐标，答案在 renderscript: accessing 'z' coordinate说明不支持 z 坐标参数。

我还需要将过滤器绑定(bind)到内核中的 rs_allocation 变量。现在我有:

内核:

rs_allocation gFilter;
//...
float f = rsGetElementAt_float(gFilter, 1,2,3);

Java:

Allocation filter;
Type filter_type = tb.setX(F).setY(F).setZ(D).create();
filter = Allocation.createTyped(mRS, filter_type);

这似乎运行良好(没有编译或运行时错误)。但是从 2014 年开始有一个 SE 条目指出从版本 20 开始我们只能绑定(bind)一维分配，这与我的结果相矛盾。

那里有很多相互矛盾和过时的信息，所以我希望内部人士可以对此发表评论，并从可持续性和最优性的角度推荐一种方法。

(1) 我是否应该继续使用传递的 xyz 坐标来计算与绑定(bind) 3D 分配的卷积？或者这种方法会在某个时候被弃用吗？

(2) 还有其他方法可以做到这一点，例如我可以将所有分配重新整形为一维，将它们传递到内核并使用索引算法。这也将允许将某些值彼此靠近放置。另一种方法可能是将输入的 3D 体积分割为深度为 4 的 block ，并在类型中使用 float4。假设 (1) 可以使用，从优化的角度来看，与其他方法相比，使用 (1) 是否有缺点？

(3) 一般来说，是否存在理想的内存布局公式，例如出于优化原因将问题重新表述为 float3 或 float4 深度，而不是像 (1) 这样的“直接”方法？

Answer 1

1) 现在支持 z 作为您可以查询的坐标，所以我以前的答案已经过时了。这也是您上面的示例代码不会生成编译器错误的原因(假设您的目标是相对现代的 API 级别)。

2) 停止使用 bind() 甚至是一维事物(这是我们现在唯一支持的一种，但即使那样也不是什么好技术)。您可以在 .rs 文件中使用 rs_allocation 作为全局变量，并使用 Java 中的 set_() 来获得对这些全局分配的同等访问权限。然后使用适当类型的 rsGetElementAt_() 和 rsSetElementAt_*() 直接在 .rs 文件中读取/写入。

3) 像这样进行内存布局优化可能对某些设备有益，而对其他设备则更糟。如果您可以使用常规的 x/y/z API，那么这些 API 将为实现提供高效布局的最佳机会。