【发布时间】：2012-10-07 08:57:13
【问题描述】：
【问题讨论】：
-
Java 支持线程，这意味着您可以使用并行处理。我不确定是否必须设置 JVM 以使用更多的处理器/内核（如果可用），或者这是否由 JVM 默认（或操作系统）处理。
-
这篇论文是同一主题：ieeexplore.ieee.org/xpl/…
【发布时间】：2012-10-07 08:57:13
【问题描述】：
没有理由不能使用 Hadoop。
如果您要同时使用 Hadoop 的“map”和“reduce”阶段，这意味着在 Hadoop 节点之间拆分每个 帧。
如果您只是使用每个节点来渲染单独的帧，那么使用 Hadoop 几乎没有什么好处，尽管上面 cmets 中提到的论文摘要表明 HDFS 可以很好地访问场景数据和渲染帧。
我用 Java 编写了一个随机光线追踪器，它目前是多线程的。在这段代码中，我为每个像素收集了大量的样本，因此在 Hadoop 中，收集这些样本以产生最终的像素输出将很好地对应于 Hadoop 的“减少”阶段。
【讨论】：
-
感谢您的回答。
both the "map" and "reduce" phases of Hadoop, that implies splitting each frame嗯。为什么两者都有？我认为在 Map 步骤中，我需要将一个大框架拆分为多个“迷你框架”，然后将每个迷你框架放入 Hadoop 节点。在减少步骤中，我需要从节点获取结果，并将处理后的迷你帧组合成一个大帧。这是对的？哪个尺寸必须有框架？每帧数百千兆字节？并且每一帧都必须以千兆像素为单位进行定义？ （我认为没有理由在较小的帧尺寸下使用 Hadoop）。 -
那么在 Hadoop 节点之间分割整个帧呢？每帧都会处理一个大帧，完成后我会得到几帧并将这些帧组合成一个“迷你电影”？
-
@MyTitle 减少阶段也应该能够并行化 - 当需要采用（线性）帧序列将它们编码成视频时，这不太可能有用。对于单个帧，您可以按像素行或（例如）64x64 块，根据您的渲染模型来分割它们。
我不明白为什么不这样做，只要您的应用不需要很短的响应时间（大约不到一分钟）。 IE。它很可能对 3D 游戏毫无用处，但如果您正在制作电影并且必须处理大量镜头或其他东西，那么它可能是有意义的。
【讨论】：
这应该是可能的 - 因为大多数几何任务可以以并行方式执行（您有顶点和三角形，并根据投影矩阵对它们执行计算）和以管道方式执行，因为不可见的图元将被从进一步计算中删除
【讨论】：