Чому векторну графіку з прискореним обладнанням не зняли?

Я працюю над додатком, який передбачає в режимі реального часу маніпулювання векторними контурами зі швидкістю 60 кадрів в секунду, і я дуже здивований тим, наскільки мало інформації щодо цього питання. Спочатку я спробував реалізувати свою ідею за допомогою CoreGraphics, але вона не працювала адекватно для моїх цілей . Потім я виявив, що існує стандарт Khronos для апаратної прискореної векторної графіки під назвою OpenVG , і на щастя, добра душа написала напівреалізацію OpenGL ES під назвою MonkVG .

Але незважаючи на те, що OpenVG є дуже практично корисним API, Khronos здається більш-менш занедбаним. За даними Вікіпедії, з 2011 року робоча група "вирішила ... не проводити жодного регулярного засідання [sic] для подальшої стандартизації". Документація, яку я найкраще знайшов, складається лише з однієї довідкової картки. Більше того, в Інтернеті практично немає прикладів OpenVG. Я можу знайти сотні навчальних посібників OpenGL за мить, але OpenVG, здається, помітно відсутній.

Ви можете подумати, що апаратні прискорені вектори будуть важливішими в сучасному світі швидкозростаючих резолюцій, і, здається, багато компаній реалізують власні способи цього зробити. Наприклад, у Qt та Flash є схеми для апаратних прискорених векторів, і багато інструментів Adobe є опцією прискорення обладнання. Але здається, що колесо відновлюється, коли вже існує стандарт!

Щось мені не вистачає у OpenVG, що робить його непридатним для використання в реальному світі? Або це просто те, що стандарт не встиг вчасно, і тепер він призначений для незрозумілості? Чи вважаєте ви, що в майбутньому є можливість для стандартизованого API для прискореної апаратним забезпеченням векторної графіки, чи просто буде простіше використовувати традиційні методи на основі растру? Або вектори просто виходять, перш ніж вони коли-небудь були?

оновлення: Див. нижню частину відповіді

Ця відповідь приходить трохи пізно, але я сподіваюся просвітити іншим (особливо зараз, коли стандартний комітет C ++ хоче включити Каїр до std):

Причина, що нікого насправді не цікавить "прискорена векторна графіка", полягає в тому, як працюють графічні процесори. Графічні процесори працюють за допомогою масивної паралелізації та можливостей SIMD для фарбування кожного пікселя. AMD, як правило, працює в блоках розміром 64x64 8x8 пікселів, тоді як NVIDIA карти зазвичай працюють у 32x32 4x4 пікселів [Дивіться оновлення внизу]

Навіть якщо вони рендерують трикутник, GPU працює на цілих квадратиках, які покриває цей трикутник. Отже, якщо трикутник не охоплює всіх 8x8 пікселів у блоці (або 4x4 у разі nvidia), графічний процесор буде обчислювати колір непокритих пікселів, а потім відкидає результат. Іншими словами, витрачається потужність обробки непокритих пікселів. Хоча це здається марнотратним, воно працює надзвичайно добре для надання великих трикутників у поєднанні з величезною кількістю ядер GPU (більш детальна інформація тут: Оптимізація базового растризатора ).

Отже, коли ми оглянемося на векторну растеризацію, ви помітите, що під час малювання ліній, навіть якщо вони товсті, є масивний порожній простір. Багато витрачається на оброблювану потужність і ще важливіше пропускну здатність (що є основною причиною споживання електроенергії, а найчастіше вузьке місце). Отже, якщо ви не малюєте горизонтальну або вертикальну лінію товщиною, кратною 8, і вона ідеально підходить до 8 піксельних меж, багато процесорної потужності та пропускної здатності буде витрачено даремно.

Кількість "відходів" можна зменшити, обчисливши корпус для рендерінгу (як це робить NV_path_rendering), але GPU все ще обмежений до 8x8 / 4x4 блоків (також, ймовірно, орієнтири GPU NVIDIA масштабуються краще з більш високою роздільною здатністю, співвідношення pixels_covered / pixels_wasted значно нижчий).

Ось чому багатьох людей навіть не хвилює "прискорення векторного hw". GPU просто не дуже підходять для виконання завдання.

NV_path_rendering - це скоріше виняток, ніж норма, і вони ввели нову хитрість використання буфера трафарету; що підтримує стиснення і може значно зменшити використання пропускної здатності.

Тим не менш, я залишаюсь скептичним щодо NV_path_rendering, і дещо гуглінг показує, що Qt при використанні OpenGL (він же рекомендований спосіб) значно швидший, ніж NV_path_rendering NVIDIA: Відображення NV Path, іншими словами, слайди NVIDIA "випадково" порівнювали версію XRender з Qt. Ооопс.

Замість того, щоб стверджувати, що «все векторне малювання з прискоренням hw швидше», розробники Qt чесніше визнають, що прискорене векторне малювання HW не завжди краще (дивіться, як пояснюється їх функція візуалізації: Qt Graphics and Performance - OpenGL )

І ми не торкалися тієї частини векторної графіки "редагування в прямому ефірі", яка вимагає генерації трикутників на ходу. Редагуючи складні svgs, це фактично може призвести до серйозних накладних витрат.

Краще це чи ні, це дуже залежить від застосувань; що стосується Вашого первинного запитання "чому він не знявся", я сподіваюся, що на нього зараз відповіли: є багато недоліків і обмежень, які потрібно враховувати, часто багато людей ставляться скептично і, можливо, навіть упереджують їх не застосовувати .

оновлення: Мені вказали, що цифри абсолютно не мають основної бази, оскільки згадані графічні процесори не растровані в блоках 64x64 та 32x32, а швидше 8x8 = 64 та 4x4 = 16. Це в значній мірі зводить нанівець висновки поста. Я незабаром оновлю цю публікацію пізніше, щоб отримати більш актуальну інформацію.

Я не думаю, що це дійсно вірно, що ніхто не переймається "прискореною векторною графікою", як написано у цій відповіді .

Начебто Нвідію непокоїть трохи. Окрім Кілгард, який є провідним технічним хлопцем на NV_path_rendering (відтепер NVpr, щоб врятувати мені пальці), президент Хроноса Ніл Треветт, який також є віце-прем'єром Nvidia, просунув NVpr стільки, скільки міг за останні пару років; побачити його talk1 , talk2 або talk3 . І це, здається, трохи окупилося. На момент написання цього запису NVpr зараз використовується в Skia Google (який, в свою чергу, використовується в Google Chrome) і незалежно [від Skia] в бета-версії Adobe Illustrator CC (beta), згідно слайдів Kilgard на GTC14 ; Є також відео з переговорів, що проводяться там: Kilgard's та Adobe. Каїрський розробник (який працює в Intel) також здається зацікавлений у NVpr. Mozilla / Firefox розробники також експериментували з NVpr, і вони насправді дбають про прискорену графічну графічну графіку в цілому, як показує це ток-шоу FOSDEM14 .

Microsoft також піклується про те, що вони створили Direct2D , який використовується досить широко [якщо вірити розробнику Mozilla з вищезгаданої розмови].

Тепер, щоб перейти до питання первинного питання: дійсно є деякі технічні причини, чому використання графічних процесорів для візуалізації шляху не є простим. Якщо ви хочете почитати про те, як відображення траєкторій відрізняється від стандартної геометричної вершини 3D і що робить прискорення GPU-рендерінгу шляху нетривіальним, то в Kilgard є дуже хороший запит, що нагадує FAQ , який, на жаль, похований десь на форумі OpenGL.

Для отримання більш детальної інформації про те, як Direct2D, NVpr та подібні роботи, ви можете прочитати папір « Кілгард Siggraph 2012» , яка, звичайно, орієнтована на NVpr, але також добре розглядає попередні підходи. Досить сказати, що швидкі хаки працюють не надто добре ... (як зазначається в тексті запитання PSE.) Існують значні відмінності між цими підходами, як обговорювалося в цьому документі та показано в деяких ранніх демонстраціях Kilgard, наприклад у це відео . Слід також зазначити, що офіційний документ про розширення NVpr детально описує декілька налаштувань продуктивності протягом багатьох років.

Тільки тому, що NVpr не був настільки чудовим для Linux у 2011 році (в його першій випущеній версії), як заявив Зак Русін у блозі 2011 року , це не означає, що прискорення векторів / шляхів GPU прискорене, як відповідь пана Голдберга. Здається, з цього випливає. Фактично Kilgard відповів на кінець цього блогу з оновленими драйверами, які демонструють покращення 2x-4x в порівнянні з швидшим кодом Qt, і Rusin нічого не сказав після цього.

Valve Corp. також піклується про прискорене графічним відображенням GPU, але більш обмеженим чином, що стосується візуалізації шрифту / гліфів. Вони мали гарну, швидку реалізацію згладжування великих шрифтів, використовуючи прискорені GPU поля підписаних відстаней (SDF), представлені в Siggraph 2007 , яке використовується в їхніх іграх, таких як TF; є відеодемонстрація техніки, розміщеної на YouTube (але я не впевнений, хто це зробив).

Підхід SDF побачив деякі вдосконалення однієї з каїрських та панго дев у формі GLyphy ; її автор виступив з доповіддю на linux.conf.au 2014. Занадто давна не дивилася версія полягає в тому, що він робить наближення дугоподібної кривої Безьє, щоб зробити обчислення SDF більш простежуваними у векторному (а не в растровому) просторі (Valve зробив останнє). Але навіть з наближенням дуги-сплайна, обчислення все ще були повільними; він сказав, що його перша версія працює на 3 кадрів в секунду. Тож він зараз виконує викреслення на основі сітки для речей, які "занадто далеко", що виглядає як форма LOD (рівень деталізації), але в просторі SDF. З цією оптимізацією його демонстрація працювала зі швидкістю 60 кадрів в секунду (і, мабуть, Vsync обмежена). Однак його шейдери надзвичайно складні і розсувають межі апаратних засобів та драйверів. Він сказав щось за принципом: "для кожної комбінації драйвера / ОС ми повинні змінити речі". Він також виявив значні помилки у компіляторах шейдерів, деякі з них потім були зафіксовані відповідними розробниками. Тож це дуже схоже на розробку ігор ігор AAA ...

З іншого боку, виявляється, що Microsoft замовила / вказала трохи нового обладнання для графічного процесора для вдосконалення їх реалізації Direct2D, апаратного забезпечення, яке використовується Windows 8, якщо воно є в наявності . Це називається незалежною від растерізації ( TIR ) незалежною від цілі , назва якої дещо вводить в оману щодо того, чим насправді здається, що написано в заявці на патент Microsoft . AMD стверджує, що TIR покращив продуктивність у двовимірній векторній графіці приблизно на 500% . І між ними та Nvidia була трохи "війна слів", оскільки у GPU Kepler цього немає, тоді як у процесорів AMD, що базуються на GCN. Нвідія підтвердилащо це дійсно трохи нового обладнання, а не просто те, що оновлення драйвера може надати. У публікації блогу Sinofsky є ще кілька деталей, включаючи деякі фактичні орієнтири TIR. Я цитую лише загальні біти ідеї:

для поліпшення продуктивності при зображенні неправильної геометрії (наприклад, географічні межі на карті) ми використовуємо нову графічну технічну функцію під назвою Target Independent Rasterization або TIR.

TIR дозволяє Direct2D витрачати менше циклів процесора на тесселяцію, тому він може давати інструкції малювання графічному процесору швидше та ефективніше, не пошкоджуючи візуальну якість. TIR доступний у новому апаратному забезпеченні GPU, розробленому для Windows 8, який підтримує DirectX 11.1.

Нижче наводиться діаграма, що показує поліпшення продуктивності для візуалізації антисексуальної геометрії з різних файлів SVG на графічному процесорі DirectX 11.1, що підтримує TIR: [діаграма відрізана]

Ми тісно співпрацювали з нашими партнерами з графічного обладнання [читайте AMD], щоб розробити TIR. Драматичні покращення стали можливими завдяки цьому партнерству. Обладнання DirectX 11.1 вже є на ринку сьогодні, і ми працюємо з нашими партнерами, щоб переконатися, що більше TIR-сумісних продуктів буде широко доступним.

Я думаю, це було однією з приємних речей, які додав Win 8, який здебільшого втратив світ у фіаско Metro UI ...

Можливо, тому, що його переваги не перевищують витрат.