ハードウェアアクセラレーション付きのベクターグラフィックスが削除されないのはなぜですか？

私は、60fpsでベクターパスをリアルタイムで操作するアプリを開発していますが、このテーマに関する情報が非常に少ないことに非常に驚いています。最初は、CoreGraphicsを使用してアイデアを実装しようとしましたが、目的に対して十分に機能しませんでした。それから、OpenVGと呼ばれるハードウェアアクセラレーションベクターグラフィックス用のKhronos標準があり、ありがたいことに、親切な魂がMonkVGと呼ばれるOpenGL ES準実装を書いていたことを発見しました。

しかし、OpenVGは非常に実用的なAPIであるという事実にもかかわらず、多かれ少なかれKhronosによって放棄されているようです。ウィキペディアによると、2011年以降、ワーキンググループは「さらなる標準化のために定期的な会議を開催しないことを決定しました」。私が見つけられる最高のドキュメントは、たった1枚のリファレンスカードで構成されています。さらに、インターネット上のどこにもOpenVGの例はほとんどありません。瞬く間に何百ものOpenGLチュートリアルを見つけることができますが、OpenVGは著しく欠落しているようです。

ハードウェアアクセラレータを使用したベクトルは、解像度が急速に向上する今日の世界でより重要になると思われます。多くの企業が独自の方法でこれを実装しているようです。たとえば、QtとFlashにはハードウェアアクセラレーションベクターのスキームがあり、アドビのツールの多くにはオプションとしてハードウェアアクセラレーションがあります。しかし、標準がすでに存在する場合、ホイールは再発明されつつあるようです！

OpenVGが実世界での使用に適していないことについて、私が不足しているものはありますか？それとも、標準が間に合わなかっただけで、今ではあいまいになっているのでしょうか？将来、ハードウェアアクセラレーションベクターグラフィックス用の標準化されたAPIの余地があると思いますか、それとも従来のラスターベースの技術を使用する方が簡単でしょうか？それとも、ベクターは、出入りする前に単に出て行くところにありますか？

更新：返信の下部を参照

この答えは少し遅すぎますが、他の人に光を当てたいと思います（特にC ++標準委員会がカイロを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ベンチマークは、高解像度、pixels_covered / pixel_wasted比率でより良くスケーリングします）ずっと低いです）。

これが、多くの人々が「ベクトルhwアクセラレーション」を気にかけない理由です。GPUはタスクにあまり適していません。

NV_path_renderingは標準よりも例外であり、ステンシルバッファを使用するという新しいトリックを導入しています。圧縮をサポートし、帯域幅の使用量を大幅に削減できます。

それにもかかわらず、私はNV_path_renderingに懐疑的であり、OpenGLを使用した場合のQt（別名推奨方法）は、NVIDIAのNV_path_renderingよりもはるかに高速であることを示しています：NVパスのレンダリング つまり、NVIDIAのスライドはQt。おっと。

「ハードウェアアクセラレーションを使用したすべてのベクター描画が高速である」と主張する代わりに、Qt開発者は、ハードウェアアクセラレーションによるベクトル描画の方が必ずしも優れているとは思っていません（レンダリングの仕組みの説明：Qtグラフィックスとパフォーマンス-OpenGLを参照）

そして、「ライブ編集」ベクターグラフィックスの部分には触れていません。そのため、三角形ストリップをその場で生成する必要があります。複雑なsvgを編集する場合、これは実際に深刻なオーバーヘッドを追加する可能性があります。

優れているかどうかは、アプリケーションに大きく依存します。あなたの元の質問「なぜそれがうまく行かなかったのか」に関して、私はそれが今答えられることを望みます：考慮に入れる多くの不利な点と制約があり、しばしば多くの人々を懐疑的にさせ、それらを実装しないように偏らせることさえあります。

更新：言及されたGPUは64x64および32x32ブロックでラスタライズされず、8x8 = 64および4x4 = 16であるため、数値は完全にずれています。これは投稿の結論をほとんど無効にします。近日中にこの記事を更新し、最新情報を掲載します。

この回答に書かれているように、「加速されたベクターグラフィックス」を誰も本当に気にかけないというのは本当ではないと思います。

Nvidiaはかなり気にしているようです。NV_path_renderingのリードテクニカルガイであるKilgard（以下、指を節約するためにNVprという）に加えて、NvidiaのVPでもあるKhronosの社長であるNeil Trevettは、過去数年でできる限りNVprを昇進させました。彼のtalk1、talk2またはtalk3を参照してください。そして、それは少し報われたようです。この記事の執筆時点として、NVprは今でKilgardのスライドによると、（今度はGoogle Chromeで使用されている）、GoogleのSkiaに独立し、[Skiaの]アドビイラストレーターCC（ベータ版）のベータ版で使用されているGTC14。講演のビデオもいくつかあります。キルガードとアドビの。Cairo 開発者（Intelで働いている）もNVprに興味があるようです。Mozilla / Firefoxの開発者もNVprを実験し、実際にこのFOSDEM14のトークショーが示すように、GPUで高速化されたベクトルグラフィックス全般に注意を払っています。

マイクロソフトはまた、かなり広く使用されているDirect2Dを作成したため、かなり気にしています（前述の話からMozilla開発者を信じている場合）。

元の質問のポイントに到達するために：パスレンダリングにGPUを使用するのが簡単でない理由は確かに技術的な理由がいくつかあります。パスレンダリングが沼地の標準3D頂点ジオメトリとどのように異なり、GPUによるパスレンダリングの高速化が非自明である理由について読みたい場合、Kilgardには非常に優れたFAQのような投稿がありますが、残念ながらOpenGLフォーラムのどこかに埋まっています。

Direct2D、NVprなどの動作の詳細については、KilgardのSiggraph 2012の論文を読むことができます。これは、もちろんNVprに焦点を当てていますが、以前のアプローチを調査するのにも役立ちます。クイックハックはあまりうまく機能しないと言えば十分です...（PSEの質問のテキストで述べたように）。これらのアプローチには、その論文で議論され、Kilgardの初期デモのいくつかで示されているように、このビデオ。また、公式のNVpr拡張ドキュメントには、長年にわたるいくつかのパフォーマンスチューニングの詳細が記載されています。

2011年のQtのZack Rusinのブログ投稿が言ったように、2011年の NVprがLinuxでそれほど優れていなかったからです（最初にリリースされた実装）。それから推測したようです。実際、Kilgardはブログ投稿の最後に、 Qtのより高速なコードに対して2倍から4倍の改善を示す更新されたドライバーで返信し、 Rusinはその後何も述べていません。

Valve Corp.は、GPUアクセラレーションによるベクターレンダリングにも関心がありますが、より限定的な方法で、フォント/グリフレンダリングに関連しています。Siggraph 2007で発表された GPU加速符号付き距離フィールド（SDF）を使用して、TFなどのゲームで使用される大きなフォントスムージングの素晴らしく高速な実装がありました。あります技術のデモビデオ YouTubeに投稿は、（私はそれを作った人はわかりません）。

SDFアプローチでは、カイロとパンゴの開発者の 1人がGLyphyの形でいくつかの改良を行っています。著者がlinux.conf.au 2014で講演しました。あまりにも長い間見ていなかったバージョンは、ベジェ曲線のアークスプライン近似を行って、SDF計算をベクトル（ラスターではなく）空間で扱いやすくすることです（Valveは後者を行いました）。ただし、アークスプライン近似を使用しても、計算は依然として低速でした。彼は彼の最初のバージョンが3 fpsで動いたと言った。そこで彼は、LOD（詳細レベル）の形のように見えますが、SDF空間では「遠すぎる」ものに対して、グリッドベースのカリングを行います。この最適化により、彼のデモは60 fpsで実行されました（おそらくVsyncに制限がありました）。しかし、彼のシェーダーは非常に複雑であり、ハードウェアとドライバーの限界を押し広げています。彼は、「ドライバーとOSの組み合わせごとに、変更しなければならなかった」と言っている。また、シェーダーコンパイラに重大なバグを発見しました。そのうちのいくつかは、それぞれの開発者によって修正されました。AAAゲームタイトルの開発によく似ています...

別の方法として、Microsoftは、Windows 8で使用されるハードウェア（使用可能な場合）で Direct2Dの実装を改善するために、少しの新しいGPUハードウェアを委託/指定したようです。これは、ターゲット独立ラスター化（TIR）と呼ばれます。これは、Microsoftの特許出願で詳述されているように、実際に何が行われているのかを少し誤解させる名前です。AMDは、TIRが2Dベクトルグラフィックスのパフォーマンスを約500％向上させたと主張しています。そして、Kepler GPUにはないのにAMDとGCNベースのGPUにはあるので、彼らとNvidiaの間には「言葉の戦争」が少しありました。NVIDIAは確認しましたこれは実際には、ドライバーの更新で提供できるものではなく、ほんの少しの新しいハードウェアであるということです。Sinofskyのブログ投稿には、TIRの実際のベンチマークを含むいくつかの詳細があります。私は一般的なアイデアのビットのみを引用しています：

不規則なジオメトリ（マップ上の地理的境界など）をレンダリングする際のパフォーマンスを向上させるために、Target Independent Rasterization（TIR）と呼ばれる新しいグラフィックハードウェア機能を使用します。

TIRを使用すると、Direct2Dはテッセレーションにより少ないCPUサイクルを費やすことができるため、視覚的な品質を犠牲にすることなく、GPUへの描画命令をより迅速かつ効率的に行うことができます。TIRは、DirectX 11.1をサポートするWindows 8用に設計された新しいGPUハードウェアで利用できます。

以下は、TIRをサポートするDirectX 11.1 GPUでさまざまなSVGファイルからアンチエイリアスされたジオメトリをレンダリングするためのパフォーマンスの向上を示すグラフです。

グラフィックハードウェアパートナー[AMDを読む]と密接に協力してTIRを設計しました。そのパートナーシップにより、劇的な改善が可能になりました。DirectX 11.1ハードウェアはすでに今日市場に出回っており、パートナーと協力して、より多くのTIR対応製品が広く利用できるようにしています。

これはWin 8が追加した素晴らしい機能の1つで、Metro UIの大失敗で世界にほとんど失われたと思います...

おそらく、その利点がコストを上回らないためです。