android - RenderScript 绑定(bind)指针与分配

Question

RenderScript 是否保证从 Java 层绑定(bind)的全局指针中的内存布局或跨度？

我读了somewhere最好使用 rsGetElementAt/rsSetElementAt 函数，因为不能保证布局。

但是elsewhere据说在针对 GPU 优化时要避免这些，而绑定(bind)指针是可以的。

---

在我的特殊情况下，我需要内核访问许多周围像素的值。到目前为止，我已经很好地处理了从 Java 层绑定(bind)的浮点指针。

Java:

script.set_width(inputWidth);
script.bind_input(inputAllocation);

回复:

int width;
float *input;

void root(const float *v_in, float *v_out, uint32_t x, uint32_t y) {
    int current = x + width * y;
    int above   = current - width;
    int below   = current + width;

    *v_out = input[above   - 1] + input[above  ] + input[above   + 1] +
             input[current - 1] + input[current] + input[current + 1] +
             input[below   - 1] + input[below  ] + input[below   + 1] ;
}

这是对我实际所做工作的微不足道的简化，只是为了通过示例轻松说明。实际上，我正在做更多的这些组合并同时使用多个输入图像，以至于简单地预先计算“上方”和“下方”行的位置有助于缩短处理时间。

只要保证内存是连续的并且与您通常期望的顺序相同，一切都很好，到目前为止我的测试设备上没有任何问题。

---

但如果这种内存布局确实不能在所有设备/处理器上得到保证，并且步幅实际上可能会有所不同，那么我的代码显然会中断，我将被迫使用 rsGetElementAt，例如:

Java:

script.set_input(inputAllocation);

回复:

rs_allocation input;

void root(const float *v_in, float *v_out, uint32_t x, uint32_t y) {
    *v_out = rsGetElementAt_float(input, x - 1, y - 1) + rsGetElementAt_float(input, x, y - 1) + rsGetElementAt_float(input, x + 1, y - 1) + 
             rsGetElementAt_float(input, x - 1, y    ) + rsGetElementAt_float(input, x, y    ) + rsGetElementAt_float(input, x + 1, y    ) + 
             rsGetElementAt_float(input, x - 1, y + 1) + rsGetElementAt_float(input, x, y + 1) + rsGetElementAt_float(input, x + 1, y + 1) ;
}

使用 rsGetElementAt() 的脚本的平均执行时间(710 毫秒)几乎是使用 input[] 的内核执行时间(390 毫秒)的两倍，我猜是因为每次调用都必须独立地重新计算给定 x,y 坐标的内存偏移量。

我的脚本需要连续运行，所以我试图从中获得所有可能的性能，忽略如此可观的加速将是一个真正的遗憾。

---

所以我想知道是否有人可以阐明这一点。

是否真的存在绑定(bind)指针不是完全顺序的情况，有没有办法强制它们是？

在这种情况下 rsGetElementAt() 是否真的有必要，或者继续使用依赖于预定义步幅的绑定(bind)指针是否安全？

Answer 1

对于简单的一维分配，只能保证绑定(bind)指针是连续的。应使用 get/setElementAt_ 访问具有多于一维的任何类型。

性能评价:

rsGetElementAt_float() 通常会优于 rsGetElementAt()，因为它知道类型并且可以避免跨步查找。所有类型化的 get/set 方法都是如此。

您正在测试哪个操作系统版本？ 4.4 对这种类型的代码进行了一些重大改进，在许多情况下应该能够将地址计算从循环中拉出来。

操纵指针的方法将强制某些 GPU 驱动程序回退到安全路径。

一些较新的驱动程序 (4.4.1) 将使用硬件地址计算单元来完全消除开销。