我正在尝试运行 100000 个或更多粒子。 我一直在观看许多演示着色器和 OpenCL 强大功能的教程和其他示例。
在我看到的一个示例中，粒子的位置是根据您的鼠标指针(您用一只手握住的物理设备和屏幕上的光标)的位置计算的。 每个粒子的位置存储为 RGB。 R是x，G是y，B是z。并传递给像素着色器。然后每个颜色像素被绘制为之后的粒子位置。
但是我觉得这种做法很荒谬。
- 难道不应该避免这种方法或编码风格吗？
- 难道我不应该学习如何使用 OpenCL 并利用 GPU 多线程的强大功能来直接陈述和传递我想要的代码吗？
最佳答案
Isn't this approach or coding style rather to be avoided?
为什么？
着色器的全部意义在于让你能够做你想做的事，更有效地表达你想做的事，并让你自己更好地控制硬件。
你永远不应该，永远害怕为不同的功能重新设计一些东西。纹理不存储颜色；它们存储数据，可以是颜色，但也可以是其他东西。您越早停止将纹理视为图片，您作为图形程序员的表现就会越好。
GPU 和 API 的存在是为了使用。按照您认为合适的方式使用它；不允许您认为 API 应该如何使用来限制您。
Shoudn't I learn how to use OpenCL and use the power of GPU's multithreading to directly state and pass my intended code?
昨天，我会说"is"。但是，今天发布了:OpenGL compute shaders .
事实上，OpenGL ARB 和 Khronos 创建了这种着色器类型等等，这默认了 OpenCL/OpenGL 互操作不是生成用于渲染目的的数据的最有效方式。毕竟，如果是的话，OpenGL 就不需要具有通用的计算功能。有 3 个版本的 GL 4.x 没有提供这个。它现在就在这里的事实基本上是 ARB 说，“是的，好的，我们需要这个。”
如果由许多制造硬件的人组成的 ARB 认为 CL/GL 互操作不是最快的方法，那么很明显您应该使用计算着色器。
当然，如果您现在正尝试做某事，那将无济于事；只有 NVIDIA 支持计算着色器。甚至那只是在测试版驱动程序中。 AMD 需要几个月的时间才能获得对它们的支持，而在这种支持变得足够稳固和稳定以供使用之前，还需要更多的时间。
即便如此，您也不需要计算着色器来生成数据。人们用过transform feedback and geometry shaders to do LOD and frustum culling for instanced rendering.不要害怕跳出“OpenGL 绘制东西”的框框进行思考。
关于c++ - (渲染粒子)我应该学习shader还是OpenCL？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11838246/