Почему аппаратно-ускоренная векторная графика не снимается?

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

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

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

Есть ли что-то, чего мне не хватает в OpenVG, что делает его непригодным для реального использования? Или просто стандарт не завоевал популярность вовремя, и теперь он предназначен для безвестности? Как вы думаете, в будущем найдется место для стандартизированного API-интерфейса с векторной графикой с аппаратным ускорением или просто будет проще использовать традиционные растровые методы? Или векторы просто уходят, прежде чем они когда-либо были?

обновление: см внизу ответа

Этот ответ приходит слишком поздно, но я надеюсь пролить свет на других (особенно сейчас, когда комитет по стандартизации C ++ хочет включить Cairo в std):

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

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

Итак, когда мы оглянемся назад на векторную растеризацию, вы заметите, что при рисовании линий, даже если они толстые, существует огромное пустое пространство. Потеряно много вычислительной мощности и, что более важно, пропускной способности (которая является основной причиной энергопотребления и часто является узким местом). Итак, если вы не рисуете горизонтальную или вертикальную линию с толщиной, кратной 8, и она идеально совпадает с 8 пикселей границы, много вычислительной мощности и пропускной способности будут потрачены впустую.

Количество «отходов» можно уменьшить, рассчитав оболочку для рендеринга (как это делает NV_path_rendering), но графический процессор все еще ограничен блоками 8x8 / 4x4 (также, вероятно, эталонные тесты графического процессора NVIDIA лучше масштабируются при более высоких разрешениях, соотношении пикселов_покрытых /пикселей_поста намного ниже).

Вот почему многие люди даже не заботятся о «ускорении вектора». GPU просто не очень хорошо подходят для этой задачи.

NV_path_rendering - скорее исключение, чем норма, и они ввели новый прием использования буфера трафарета; который поддерживает сжатие и может значительно уменьшить использование полосы пропускания.

Тем не менее, я по-прежнему скептически отношусь к NV_path_rendering, и с небольшим поиском в Google показывает, что Qt при использовании OpenGL (иначе рекомендуемый способ) значительно быстрее, чем NV_Path_rendering от NVIDIA: рендеринг пути NV Другими словами, слайды NVIDIA «случайно» сравнивали версию XRender Qt. По электронной почте Ой.

Вместо того чтобы утверждать, что «все рисование векторов с ускорением hw происходит быстрее», разработчики Qt более честно признают, что ускоренное рисование векторов HW не всегда лучше (см. Объяснение их рендеринга: Qt Graphics and Performance - OpenGL )

И мы не затронули ту часть «живого редактирования» векторной графики, которая требует генерации треугольной полосы на лету. При редактировании сложных svgs это может добавить серьезные накладные расходы.

Лучше это или нет, это сильно зависит от приложений; Что касается вашего первоначального вопроса «почему он не взлетел», я надеюсь, что теперь на него дан ответ: есть много недостатков и ограничений, которые необходимо принять во внимание, что часто заставляет многих людей скептически относиться и может даже склонить их к неисполнению. ,

Обновление: я указал, что числа полностью не соответствуют базовым, поскольку упомянутые графические процессоры не растеризуются в блоках 64x64 и 32x32, а скорее 8x8 = 64 и 4x4 = 16. Это в значительной степени сводит на нет выводы поста. Я скоро обновлю этот пост позже с более актуальной информацией.

Я не думаю, что это действительно правда, что никому нет дела до «ускоренной векторной графики», как написано в этом ответе .

Nvidia, кажется, немного заботится. Помимо Килгарда, который является ведущим техническим специалистом по NV_path_rendering (отныне NVpr, чтобы спасти мои пальцы), президент Khronos Нил Треветт, который также является вице-президентом Nvidia, продвигал NVpr как можно больше в последние пару лет; увидеть его talk1 , talk2 или talk3 . И это, кажется, немного окупилось. На момент написания этой статьи NVpr теперь используется в Google Skia (который, в свою очередь, используется в Google Chrome) и независимо [от Skia] в бета-версии Adobe Illustrator CC (бета), согласно слайдам Килгарда на GTC14 ; там также есть несколько видео выступлений: Килгарда и Adobe, Разработчик из Каира (который работает в Intel) также заинтересован в NVpr. Разработчики Mozilla / Firefox также экспериментировали с NVpr, и они действительно заботятся о векторной графике с GPU-ускорением в целом, как показывает этот ток-шоу FOSDEM14 .

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

Теперь перейдем к исходному вопросу: действительно, есть некоторые технические причины, по которым использование графических процессоров для рендеринга путей не является простым. Если вы хотите прочитать о том, как рендеринг путей отличается от стандартной трехмерной геометрии вершин и что делает GPU-ускорение рендеринга путей нетривиальным, то у Kilgard есть очень хороший пост , похожий на FAQ , который, к сожалению, спрятан где-то на форуме OpenGL.

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

То, что NVpr не был настолько хорош в Linux в 2011 году (в своей первой выпущенной реализации), как говорилось в блоге Qt's Zack Rusin в 2011 году, не означает, что ускорение векторов / путей в GPU безнадежно, как ответ г-на Голдберга по-видимому, из этого вытекает. Килгард фактически ответил на конец этого сообщения в блоге обновленными драйверами, показывающими улучшение в 2–4 раза по сравнению с более быстрым кодом Qt, а Русин ничего не сказал после этого.

Valve Corp. также заботится о графическом рендеринге с ускорением на графическом процессоре, но более ограниченным образом, связанном с рендерингом шрифтов и глифов. У них была хорошая, быстрая реализация сглаживания больших шрифтов с использованием ускоренных графическим процессором полей со знаком (SDF), представленных на Siggraph 2007 , который используется в их играх, таких как TF; на YouTube есть видео демонстрация техники (но я не уверен, кто это сделал).

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

С другой стороны, похоже, что Microsoft заказала / определила немного нового оборудования для графических процессоров, чтобы улучшить реализацию Direct2D на оборудовании, используемом Windows 8, если оно доступно . Это называется целевой независимой растеризацией ( TIR ), имя, которое немного вводит в заблуждение относительно того, что на самом деле, по-видимому, делается, что изложено в заявке на патент Microsoft . AMD утверждает, что TIR улучшил производительность в 2D векторной графике примерно на 500% . И между ними и Nvidia произошла небольшая «война слов», потому что у Kepler GPU ее нет, а у AMD на основе GCN. Нвидия подтвердилачто это действительно немного нового оборудования, а не просто то, что может обеспечить обновление драйвера. В блоге Синофски есть еще несколько деталей, в том числе некоторые фактические критерии МДП. Я цитирую только общие идеи:

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

TIR позволяет Direct2D тратить меньше циклов ЦП на тесселяцию, поэтому он может быстрее и эффективнее отдавать инструкции рисования графическому процессору, не жертвуя качеством изображения. TIR доступен в новом оборудовании для графических процессоров, разработанном для Windows 8, который поддерживает DirectX 11.1.

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

Мы тесно сотрудничали с нашими партнерами по графическому оборудованию [читай AMD] для разработки TIR. Благодаря этому партнерству стали возможны значительные улучшения. Аппаратное обеспечение DirectX 11.1 уже доступно на рынке сегодня, и мы работаем с нашими партнерами, чтобы обеспечить широкую доступность большего числа продуктов с поддержкой TIR.

Я думаю, это была одна из приятных вещей, которую добавила Win 8, которая была в основном потеряна для мира в фиаско UI Metro ...

Вероятно, потому что его преимущества не перевешивают затраты.