Android 在Renderscript中使用大小不确定的输出分配

我正试图用最有效的方法来处理作为RS内核输出的不确定大小的数组。我会在out分配中发送最后一个相关数组槽的索引，但我了解到，在内核执行之后，没有一个好的方法将全局值传递回java。我决定再次“缩小”这个过程，这使我找到了下面的模式

例如，假设我们有一个包含两个极坐标数组的结构的输入分配；类似于bellow中的set_pair：

typedef struct polar_tag{
  uint8_t angle;
  uint32_t mag;
} polar;

typedef struct polar_set_tag{
  uint8_t filled_slots;
  polar coordinates[60];
} polar_set;

typedef struct set_pair_tag{
  polar_set probe_set;
  polar_set candidate_set;
} set_pair;

我们希望在集合之间找到相似的坐标对，所以我们设置了一个内核来决定哪些极坐标是相似的（如果有的话）。如果它们相似，我们将其加载到类似于“匹配集合”的输出分配中：

---

使用“填充的插槽”之类的指令创建分配是使用RS处理此类不确定I/O的最有效（或唯一）的方法，还是有更好的方法？

我想我尝试的方法是进行两次传递

对于0-2情况：

设置：对于每个坐标，分配一个数组以容纳最大预期对数（2）

通过1：运行coords，通过将当前项与其他coords的子集进行比较来查找对。选择子集以避免内核在另一个要比较的坐标上运行时出现重复答案

传递2：将#1的结果合并回列表或任何其他您想要的数据结构。如果坐标数很小，则可以作为可调用的运行

对于0-N情况：

这变得更难了。我可能会做一些与上面类似的事情，但每个坐标数组的大小适合典型的成对数。对于（希望很少）数量的溢出，使用原子在溢出缓冲区中保留一个插槽。这里的问题是，我认为大多数GPU驱动程序不会对今天的atomics非常满意。在CPU ref上运行得很好

---

有很多方法可以做到这一点。一个重要的决策点围绕着比较的成本，即找到这些点与编写结果的成本

你能告诉我更多的细节吗？你认为北极熊会怎样？是0-1还是0-n？为了这个例子，这将改变可用的选项。0-2，但是我对如何处理0-n的情况感兴趣。

typedef struct matching_pair_tag{
  uint8_t probe_index;
  uint8_t candidate_index;
} matching_pair;

typedef struct matching_set_tag{
  matching_pair pairs[120];
  uint8_t filled_slots;
} matching_set;