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

#1 楼

更新：请参阅答复底部。

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

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

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

因此，当我们回顾一下基于矢量的栅格化，您会注意到在绘制线条时，即使它们很粗，也存在巨大的空白空间。浪费了很多处理能力，更重要的是带宽（这是造成功耗的主要原因，并且通常是瓶颈）
，除非您绘制的粗细为8的水平或垂直线，否则，它完美地与8个像素边界对齐，会浪费大量处理能力和带宽。

可以通过计算要渲染的船体来减少“浪费”的数量（就像NV_path_rendering一样），但是GPU仍然限制为8x8 / 4x4块（也可能是NVIDIA的GPU基准测试具有更高的分辨率，可以更好地缩放，pixels_covered / pixels_wasted的比例要低得多）。这就是为什么很多人甚至不在乎关于“矢量硬件加速度”。 GPU根本不适合该任务。

NV_path_rendering比标准更多的是例外，他们引入了使用模板缓冲区的新颖技巧；它支持压缩并可以显着减少带宽使用。 ：NV路径渲染
换句话说，NVIDIA的幻灯片“偶然地”比较了XRender的Qt版本。哎呀。

Qt开发人员更诚实地承认，使用硬件加速的矢量绘图并不总是更好（请参阅其渲染方式的解释：Qt Graphics和性能-OpenGL）

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

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

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

#2 楼

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

Nvidia似乎很在乎。除了Kilgard是NV_path_rendering的首席技术人员（此后为节省我的NVpr）之外，Khronos总裁Neil Trevett（也是Nvidia的副总裁）在过去两年中竭尽全力推动NVpr。查看他的talk1，talk2或talk3。这似乎已经有所回报。根据Kilgard在GTC14上的幻灯片，在撰写本文时，Nvpr现在已用于Google的Skia（反过来又用于Google Chrome），并在Adobe Illustrator CC（测试版）的Beta版中独立使用[Skia]。还有一些演讲的视频：基尔加德（Kilgard）和Adobe的。一位Cairo开发人员（为Intel工作）似乎也对NVpr感兴趣。 Mozilla / Firefox开发人员还试验了NVpr，实际上，正如FOSDEM14谈话所显示的那样，实际上他们实际上关心的是GPU加速的矢量图形。 [如果您相信上述讨论中的Mozilla开发人员]。

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

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

因为2011年NVpr在Linux（在其首次发布的实现中）方面不那么出色，就像2011年的博客文章一样Qt的Zack Rusin表示，这并不意味着GPU对向量/路径的加速是没有希望的，因为Goldberg先生的答案似乎是从中推断出来的。 Kilgard实际上已经回复了该博客文章的末尾，并更新了驱动程序，显示出比Qt更快的代码提高了2到4倍，而Rusin在那之后什么也没说。加速的矢量渲染，但以更有限的方式涉及字体/字形渲染。他们使用Siggraph 2007上展示的GPU加速的有符号距离字段（SDF）很好，快速地实现了大字体平滑，该字体在TF等游戏中使用；在YouTube上发布了有关该技术的视频演示（但我不确定是谁制作的）。

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

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


为了提高在渲染不规则几何图形（例如地图上的地理边界）时的性能，我们使用了一种称为目标独立栅格化（TIR）的新图形硬件功能。因此可以在不牺牲视觉质量的情况下，更快，更有效地向GPU提供绘图指令。 TIR在为Windows 8设计的，支持DirectX 11.1的新GPU硬件中可用。 TIR：[图表已摘录]

我们与图形硬件合作伙伴紧密合作[阅读AMD]设计TIR。由于有了这种伙伴关系，才有了巨大的进步。 DirectX 11.1硬件已经在市场上上市，我们正在与合作伙伴合作，以确保更多具有TIR功能的产品广泛可用。 Win 8添加的东西大部分在Metro UI惨败中丢失了给世界...

#3 楼

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