为什么硬件加速的矢量图形没有被删除？

我正在开发一个涉及以60fps实时处理矢量路径的应用程序，而关于该主题的信息很少，我感到非常惊讶。最初，我尝试使用CoreGraphics来实现我的想法，但是对于我的目的而言，它的表现并不理想。然后，我发现有一个用于硬件加速矢量图形的Khronos标准称为OpenVG，并且值得庆幸的是，一个善良的人写了一个名为MonkVG的OpenGL ES半实现。

但是，尽管事实上OpenVG是一个非常实用的API，但Khronos似乎还是放弃了它。根据Wikipedia的说法，自2011年以来，工作组“决定……不召开任何常规会议以进一步实现标准化”。据我所知，该文档仅包含一个参考卡。而且，互联网上几乎没有OpenVG的任何示例。我可以在眨眼之间找到数百个OpenGL教程，但是OpenVG似乎明显缺失。

您可能会认为，在当今分辨率迅速提高的世界中，硬件加速矢量将更为重要，而且似乎许多公司正在实现自己的方式。例如，Qt和Flash具有用于硬件加速矢量的方案，并且许多Adobe的工具都可以选择硬件加速。但是，当标准已经存在时，车轮似乎正在被彻底改造！

关于OpenVG，我是否缺少某些东西，使其不适合实际使用？还是仅仅是因为标准没有及时赶上而现在注定要变得晦涩难懂？您认为将来是否存在用于硬件加速矢量图形的标准化API的空间，还是使用基于栅格的传统技术会更容易？还是矢量在进入之前就只是在走出去？

更新：请参阅答复底部

这个答案来得太晚了，但是我希望对其他人有所启发（特别是现在C ++标准委员会希望将Cairo纳入std）：

没人真正关心“加速矢量图形”的原因是因为GPU的工作方式。GPU使用大规模并行化和SIMD功能为每个像素着色。AMD通常工作在64x64 8x8像素的块中，而NVIDIA卡通常工作在32x32 4x4像素的块中[请参阅底部的更新]

即使他们正在渲染3D三角形，GPU也会在该三角形覆盖的整个四边形上工作。因此，如果三角形不覆盖块中的所有8x8像素（对于nvidia，则为4x4），GPU将计算未覆盖像素的颜色，然后丢弃结果。换句话说，浪费了未覆盖像素的处理能力。虽然这看起来很浪费，但是当与大量GPU内核配对时，它对于渲染大型 3D三角形非常有用（此处有更多详细信息：优化基本光栅化器）。

因此，当我们回顾基于矢量的栅格化时，您会注意到在绘制线条时，即使它们很粗，也会有巨大的空白空间。大量的处理能力的浪费，更重要的带宽（这是消耗电力的主要原因，和通常是一个瓶颈）所以，除非你正在绘制为8的厚度倍数的水平或垂直线，并且它完美对准到8个像素边界会浪费很多处理能力和带宽。

可以通过计算要渲染的船体来减少“浪费”的数量（就像NV_path_rendering一样），但是GPU仍被限制为8x8 / 4x4块（也可能是NVIDIA的GPU基准以更高的分辨率更好地缩放，即pixel_covered / pixel_wasted比）低得多）。

这就是为什么许多人甚至不关心“矢量硬件加速”的原因。GPU根本不适合该任务。

NV_path_rendering比标准更多的是例外，他们引入了使用模板缓冲区的新颖技巧。支持压缩并可以大大减少带宽使用。

尽管如此，我仍然对NV_path_rendering持怀疑态度，并且有一点谷歌搜索表明，使用OpenGL时的Qt（又名推荐方式）比NVIDIA的NV_path_rendering快得多：NV路径渲染 换句话说，NVIDIA的幻灯片“偶然地”比较了XRender的XRender版本Qt 哎呀

Qt开发人员没有坦率地说“使用硬件加速的所有矢量绘图都更快”，而是坦率地承认硬件加速的矢量绘图并不总是更好（请参阅其渲染方式说明：Qt图形和性能– OpenGL）

而且，我们还没有涉及“实时编辑”矢量图形的部分，该部分需要即时生成三角带。在编辑复杂的svg时，实际上可能会增加严重的开销。

是否更好，很大程度上取决于应用程序。关于您最初的问题“为什么还没有开始”，我希望现在得到答复：要考虑许多不利因素和制约因素，常常使很多人持怀疑态度，甚至可能使他们偏向于不实施。

更新：我已经指出数字是完全不合时宜的，因为提到的GPU不会以64x64和32x32的块进行栅格化，而是8x8 = 64和4x4 =16。这几乎使帖子的结论无效。稍后，我将使用更多最新信息来更新此帖子。

我认为没有人真的很在乎此答案中所写的“加速矢量图形”，这并不是真的。

英伟达似乎很在乎。除了Kilgard谁是技术牵头人NV_path_rendering，Khronos的总裁尼尔·特雷维特，谁也是在Nvidia的一个VP，促进NVpr尽可能多的，因为他可以在过去的几年中（以下NVpr救我的手指）; 看看他的talk1，talk2或talk3。这似乎已经有所回报。根据Kilgard在GTC14上的幻灯片，在撰写本文时，Nvpr现在已在Google的Skia（反过来又在Google Chrome中使用）中使用，并且在Skia的Beta版Adobe Illustrator CC（测试版）中独立使用；还有一些演讲的视频：基尔加德（Kilgard）和Adobe的。一位Cairo开发人员（为Intel工作）似乎也对 NVpr 感兴趣。Mozilla / Firefox开发人员还试用了NVpr，实际上，正如FOSDEM14谈话所显示的那样，他们实际上确实在乎GPU加速的矢量图形。

微软也很在意，因为他们创建了Direct2D，它被相当广泛地使用（如果您相信上述讨论中的Mozilla开发人员）。

现在要解决原始问题：确实有一些技术原因导致使用GPU进行路径渲染并不简单。如果您想了解路径渲染与沼泽标准3D顶点几何有何不同，以及如何使GPU加速路径渲染变得不那么琐碎，那么Kilgard会提供一个很好的类似FAQ的帖子，不幸的是它被埋在OpenGL论坛的某个地方。

有关Direct2D，NVpr和此类工作方式的更多详细信息，您可以阅读Kilgard的Siggraph 2012论文，该论文当然侧重于NVpr，但也可以很好地调查现有方法。可以肯定地说，快速hack的效果不太好...（如PSE问题的文字所述。）如该论文所讨论的，以及Kilgard的一些早期演示中所展示的，例如，这部影片。我还要注意，官方NVpr扩展文档详细介绍了这些年来的一些性能调整。

正如Qt的Zack Rusin 在2011年的博客文章中所言，2011年NVpr在Linux上并不是那么出色（在其首次发布的实现中），这并不意味着Goldberg先生的答案就意味着向量/路径的GPU加速毫无希望。似乎是从中推断出来的。Kilgard实际上已经回复了该博客文章的结尾，并更新了驱动程序，显示出比Qt更快的代码提高了2到4倍，而Rusin在那之后什么也没说。

Valve Corp.也关心GPU加速的矢量渲染，但以更有限的方式涉及字体/字形渲染。他们使用Siggraph 2007上展示的 GPU加速的有符号距离字段（SDF）很好，快速地实现了大字体平滑，并在他们的游戏中使用了TF等；在YouTube上发布了有关该技术的视频演示（但我不确定是谁制作的）。

SDF方法已经由开罗和pango开发人员之一以GLyphy的形式进行了一些改进；其作者在linux.conf.au 2014上发表了演讲。监视表太长了，他对Bezier曲线进行了弧形样条逼近，以使SDF计算在矢量（而不是栅格）空间中更易于处理（Valve做了后者）。但是，即使采用了弧形样条近似，计算仍然很慢。他说他的第一个版本以3 fps的速度运行。因此，他现在对“距离太远”的东西进行基于网格的剔除，这看起来像是LOD（详细程度）的形式，但在SDF空间中。通过这种优化，他的演示以60 fps的速度运行（可能受Vsync限制）。但是，他的着色器非常复杂，并推动了硬件和驱动程序的极限。他说了类似的话：“对于每个驱动程序/ OS组合，我们都必须进行更改”。他还发现了着色器编译器中的重大错误，然后其中的一些由各自的开发人员修复。因此，听起来很像AAA游戏名称的开发...

另一方面，微软似乎已经委托/指定了一些新的GPU硬件，以改进Windows 8使用的硬件（如果有）的Direct2D实现。这称为独立于目标的栅格化（TIR），这个名称对于实际操作似乎有点误导，这在Microsoft的专利申请中已阐明。AMD声称TIR将2D矢量图形的性能提高了约500％。他们和Nvidia之间存在一些“口水战”，因为开普勒GPU没有，而AMD基于GCN的GPU却有。Nvidia已确认这确实是一点新硬件，而不仅仅是驱动程序更新可以提供的东西。Sinofsky的博客文章提供了更多详细信息，包括TIR的一些实际基准。我只引用一般的想法：

为了在渲染不规则几何图形（例如地图上的地理边界）时提高性能，我们使用了一种称为目标独立栅格化（TIR）的新图形硬件功能。

TIR使Direct2D可以在镶嵌上花费更少的CPU周期，因此可以在不牺牲视觉质量的情况下更快，更有效地向GPU提供绘图指令。在支持DirectX 11.1的Windows 8新GPU硬件中提供了TIR。

下面的图表显示了在支持TIR的DirectX 11.1 GPU上从各种SVG文件渲染抗锯齿几何的性能改进：[图表已摘录]

我们与图形硬件合作伙伴紧密合作，共同设计TIR。由于有了这种伙伴关系，才有了巨大的进步。DirectX 11.1硬件已经在当今市场上上市，我们正在与合作伙伴合作，以确保更多具有TIR功能的产品将广泛可用。

我想这是Win 8新增的一件好事，但在Metro UI惨败中，这些东西大部分都输给了世界...

可能是因为其收益不超过成本。