实时2D渲染到系统内存

Question

通过编写处理系统（ 非视频 ）内存中的图像/帧数据的视频滤镜，渲染2D图形，应该是跨平台的（至少是Windows，Linux和OSX ）并且工作得非常快，我查看了不同的渲染器，比如开罗 ， AGG和许多其他项目。 我不喜欢GPU要求，因此到目前为止我的重点是软件渲染。

令人遗憾的是， 开罗在复杂的路径和渐变上变得非常慢，并且通过微小的路径段产生了丑陋的几何缺陷， AGG也很慢，因为缺少优化需要用户进行大量工作，其他项目只是渲染到窗口或性能不重要对他们来说 Blend2D让我很好奇但是他的时间变得成熟了。

现在我问我：我应该渲染一个OpenGL帧缓冲区并通过几何库做2D到3D的东西，接受挑战从头开发软件渲染器（由SIMD，线程管道等加速）还是我想念一个适合我的图书馆？

推动与GPU相关的所有图形总是值得的，因为近来便宜的数据传输到视频内存和从视频内存传输，即使使用1080p或更大的图像？

Answer 1

典型的台式机CPU有4个处理核心，运行频率为2.5GHz。 现代桌面GPU （大约2010年）有48到480个着色器，运行频率为1.4GHz。 因此，就原始处理能力而言，GPU可以比CPU快7到70倍处理图形。

至于传输带宽，1080p图像是1920×1080像素，帧速率是每秒30帧，像素是4字节（32位）。 因此，实时1080p处理所需的总总线带宽是

1920 x 1080 x 30 x 4 = 248 MB/s

PCI Express 2.0 x16插槽的带宽为8000 MB / s。 也就是说CPU到GPU的传输速率不是问题。

所以，回答你的问题：是的，即使使用1080p或更大的图像，推送与GPU相关的所有图形总是值得的。

Answer 2

OpenCV的替代品可能是SDL 。 至少有一个教程和文档专门讨论将视频数据流式传输到硬件 。 当然，你必须用glsl重写你的过滤器来获得任何不错的加速度。

也就是说，听起来您的问题可能会从OpenCL或Cuda等GPU计算解决方案中获益更多。 在这种情况下，不涉及渲染，而是将数据发送到GPU内核，并在处理时将其恢复。 或者可以将它发送到OpenGL / DirectX（视频内存可以很容易地作为纹理重用而不会丢失性能）进行渲染。 如果您不想超越OpenGL api，还可以使用计算着色器 。 像传统着色器一样工作，除了它在传递中计算，但有一些额外的约束和限制。

Answer 3

你试过OpenCV吗？

它为软件和硬件渲染器提供了大量高度优化的函数库 ，用于实时图像处理和渲染。