- Чуть-чуть истории Lucid и теории Virtu
- Обновленный GMA HD и технология Intel QuickSync
- Lucid Virtu на практике
- Выводы
В обзоре чипсета Intel Z68 мы разобрали не только его аппаратные возможности, но и одну фирменную технологию, которая, будучи чисто программной, может быть реализована, однако, только в платах, основанных на этом топовом чипсете Intel — Smart Response. Сегодня у нас на очереди отдельный обзор второй технологии, привязанной равно к H67 (и H61) и к Z68 — Lucid Virtu. Виртуализация вывода видеокарт («в честь которой», собственно, технология и получила свое название) интересна тем, что это не просто программное решение, а программное решение сторонней компании, причем не имеющей, так сказать, прямого отношения к обслуживаемому железу (в отличие, скажем, от технологий SLI/CrossFire). Кому может быть интересно это дополнение компании LucidLogix, и способно ли оно стать плюсом новых интегрированных чипсетов, побуждая к покупке платы именно на них (а не на P67)? Давайте разбираться.
Чуть-чуть истории Lucid и теории Virtu
Решения LucidLogix уже не первый раз привлекают внимание обозревателей материнских плат. Некоторое время назад компания представила технологию Hydra, позволявшую объединять вычислительные способности не просто двух видеокарт (как NVIDIA SLI или ATI/AMD CrossFire), а двух видеокарт разных производителей. То самое SLI+CrossFire, которого мы, по очевидным причинам, никогда не дождались бы ни от одного из упомянутых производителей по отдельности. К судьбе Lucid Hydra мы еще вернемся, а пока заметим, что представленная в этом году технология Virtu является ее продолжателем — во всяком случае, по принципу функционирования.
Но если Hydra предлагала связывать вместе отдельные видеокарты идеологических противников, то Virtu предназначена для объединения, скорее, союзников, ибо встроенная графика (ранее чипсетов, а теперь — процессоров) Intel пока не является и в обозримом будущем не будет являться конкурентом графике внешней. Никакой разгон, никакое обновленное ядро не делают интегрированный видеоускоритель сопоставимым по производительности с отдельными видеокартами хотя бы среднего уровня, да и самые младшие дискретные решения в таком сравнении доминируют. Другое дело, что сравнение с младшими видеокартами для встроенной графики может быть вполне лестным: скорость в 3D ниже не принципиально (грубо говоря, одни и те же игры «пойдут» или «не пойдут» и там, и там); возможности по выводу картинки (и звука!) — как бы не шире; по прочим характеристикам тоже примерный паритет, но: минус цена, минус громоздкость. Итак, напрашивается вывод, что для всего, кроме «серьезных» 3D-игр, вам может хватить платы/процессора с интегрированным видео, ну а ради топовых игр (или каких-то фирменных технологий AMD/NVIDIA) стоит купить видеокарту по средствам.
Зачем же нужна технология, объединяющая встроенное и внешнее видео? Это хороший вопрос: отсутствие ответа на аналогичный вопрос привело к тому, что сколько-нибудь серьезного распространения на рынке технология Lucid Hydra не получила. В самом деле: сначала мысль о том, что при помощи простого драйвера можно «обмануть» ведущих производителей видеокарт и заставить работать их продукцию в тандеме — греет душу. Но по здравому размышлению, даже идеальная работа такого драйвера (до чего в реальности, конечно, было далеко) не дает никаких реальных преимуществ. Ну если очень хочется купить вторую карту в пару к предыдущей (а не ускоритель нового поколения, более мощный, чем старая пара за те же деньги) — так почему не купить «родной» и не собрать «родной» SLI или CrossFire?
Что же такого предлагает Lucid Virtu, и почему количество плат (или, по крайней мере, моделей плат) с поддержкой этой технологии обещает быть существенно бо́льшим? Во-первых, чего не предлагает: объединения производительности. Не предлагает как раз по упомянутым выше причинам: даже для средней видеокарты (не говоря уж о топовой) возможная прибавка в скорости от интегрированного GMA HD 2000/3000 настолько ничтожна, что, скорее всего, даже не окупит затрат на работу «лишнего» драйвера (и это мы опустили замечания про сопутствующие проблемы и глюки). Ну а покупать сознательно младшую карту и пытаться выжать еще какие-то копейки производительности для нее любой ценой — это уже разновидность мазохизма/«энтузиазма».
Вместо попытки распределить рендеринг кадров между двумя видеокартами, Virtu занимается довольно простым делом: копирует/перемещает кадровый буфер от одной видеокарты к другой. Никаких дополнительных вычислений, балансировки нагрузки и т. д. Видеокарта честно выполняет свою работу, будь то рендеринг игровой сцены, отрисовка окон приложения или формирование кадров фильма. Подготовленный ею очередной кадр складируется в экранном буфере, но не выводится оттуда на устройство отображения (как наивно полагает бедная карточка), а перехватывается драйвером Virtu, копируется в экранный буфер второй видеокарты и выводится на монитор/телевизор уже ею. И так 60 раз в секунду (или какая там у вас установлена частота обновления экрана?).
Что дает такая схема? Ну, очевидно, вывод на монитор из одного места: благодаря работе драйвера, «актуальный» экранный буфер всегда находится при желаемом видеовыходе. Опять же, с технологической точки зрения, решение красивое и… «свежее», если хотите. Но с практической стороны, не надо быть семи пядей во лбу, чтобы догадаться, что картинку игры лучше строить с помощью дискретной видеокарты (а откуда ее выводить — вопрос куда менее принципиальный). Какие же причины могут побудить задействовать еще и Intel GMA (и, шире, Lucid Virtu)? Нам видится два с половиной варианта ответа.
Тепловыделение. На общем уровне идея такова, что «настоящую» видеокарту мы используем только под «настоящей» 3D-нагрузкой, а в остальное время она отдыхает, позволяя работать за себя куда более экономичной встроенной графике. Всё бы неплохо, да только современные видеокарты и без того имеют режим работы «2D», когда для отрисовки рабочего стола Windows они функционируют на существенно пониженной частоте блоков (а часть блоков и вовсе отключается). В то же время, внешний видеоускоритель в системе с Lucid Virtu не выключается и не погружается в глубокий сон, когда он не задействован. Это легко понять по тому, что вентиляторы такой карты не останавливаются и тепловой режим не улучшается. Впрочем, о данных мониторинга мы еще поговорим подробнее в разделе практического тестирования.
Видеовыходы. За пол-аргумента посчитаем потенциальное богатство видеовыходов встроенного видео на материнской плате: на моделях, основанных на H67 и Z68, стабильно можно увидеть аналоговый выход (d-Sub), DVI-D и HDMI, а зачастую еще и DisplayPort. Конечно, никто не мешает сделать аналогичный набор и у видеокарт, но как показывает практика, их производители вечно гонятся за какими-то химерами, в результате чего на топовом ускорителе может быть аж 6 выходов DisplayPort, а картинку на стандартный телевизор придется выводить через переходник на HDMI. Переходники громоздки (например, системный блок может стоять вплотную к стенке или в нише стола), они уменьшают механическую надежность сборки… В общем, маловероятно, конечно, но будем объективны и не станем лишать Virtu немногих шансов.
Кодирование видео на Intel GMA. А вот это оно самое. Собственно, даже маркетологи всех заинтересованных компаний практически единогласно говорят о Lucid Virtu, как о возможности использовать внешнюю видеокарту, не теряя режима сверхскоростного перекодирования видео с помощью встроенной графики процессоров Sandy Bridge. (Более того, такое перекодирование на Intel GMA может выполняться параллельно с игрой на внешней видеокарте — без потери производительности в обоих режимах.) И чтобы были понятны наши дальнейшие рассуждения и тесты, мы вынуждены здесь рассказать подробнее об этой технологии, имеющей фирменное название QuickSync.
Обновленный GMA HD и технология Intel QuickSync
После того, как в прошлом году мы уделили достаточно внимания интегрированной графике новых (на тот момент) процессоров Intel Clarkdale, очередное поколение встроенного видео (в процессорах на ядре Sandy Bridge) столь подробного разбора не удостоилось. Причины очевидны: это далеко не самый интересный и перспективный объект для изучения. В области вывода видео (и звука) ускорители GMA HD уже достигли чуть ли не совершенства, а в области игр ловить им, понятно, было нечего. Правда, новый встроенный видеоускоритель получил заметно более быстрые унифицированные шейдерные процессоры (разрядность ФУ увеличена с 64 до 128 бит) — в идеальном варианте их производительность должна увеличиться вдвое по сравнению со «старым» GMA HD (теперь, задним числом, названным GMA HD 1000). Однако для «компенсации» этого факта прежнее количество шейдерных вычислительных блоков сохранил лишь старший вариант (GMA HD 3000), встречаемый в основном только в более дорогих процессорах K-серии, а распространенный младший (GMA HD 2000) — вдвое уменьшенное количество, то есть по производительности он должен примерно соответствовать старым решениям (на одинаковой частоте).
Некоторое исследование производительности новых «интеграшек» мы выполнили — его можно найти во второй и четвертой частях нашего соответствующего цикла. В принципе, поскольку со сравнением GMA HD 3000 и GMA HD 1000/2000 всё ясно, мы позволим себе лишь краткую оценку возможностей обновленного интегрированного GPU в современных играх.
Другое дело — аппаратное кодирование видео. Для декодирования видео, которое стало актуальным с приходом HD-разрешения (современные процессоры среднего уровня с трудом могли справляться с этой задачей программно), довольно быстро были созданы и внедрены аппаратные декодеры. Внедрены они были в видеокарты, поскольку вывод картинки традиционно возлагается именно на эти продукты. Однако по сути это независимый аппаратный модуль, и он мог бы устанавливаться, например, в чипсет или процессор — правда, при этом неизбежно возникли бы некоторые сложности с передачей декодированной картинки для вывода на монитор. Собственно, примерно тогда же в видеокартах появились и аппаратные блоки для кодирования видео, а также появилась программная поддержка этой технологии во всевозможных т. н. «конвертерах». Этот класс программ предназначался для быстрого перекодирования видео из одного формата в другой и был представлен, например, Elemental Badaboom, Movavi Video Converter, CyberLink MediaEspresso и т. д.
Обращаем ваше внимание на то, что данное аппаратное кодирование не является так называемой технологией «вычислений общего назначения на графическом процессоре» — GPGPU. (Подробнее о GPGPU на примере видеокарт AMD/ATI можно почитать в теоретической и практической статьях на нашем сайте.) Здесь, в отличие от той же CUDA (где вся работа осуществляется исполнительными модулями GPU — шейдерными процессорами), применяются специализированные аппаратные модули, предельно упрощенные и способные на выполнение только одной задачи (например, дискретного косинусного преобразования) — зато быстро и с расходом минимума ресурсов. Более «интеллектуальные» задачи (например, разбиение картинки на макроблоки и вычленение движущихся объектов) возложены на исполнительные модули GPU, но у тех тоже есть свои ограничения по вычислениям со сложным «ветвящимся» алгоритмом. Естественным следствием общей упрощенности является крайне негибкий алгоритм работы блока кодирования. Это, а также сложность включения подобного блока в конвейер вычислений при обработке видео является основной причиной того, почему аппаратное кодирование видео на видеокартах практически не применяется в «реальной жизни».
Графический ускоритель, интегрированный в процессоры Sandy Bridge, был улучшен в области декодирования видео. Как мы помним, функциональность его была фактически исчерпывающей еще в прошлом поколении, но теперь выполнена оптимизация этого блока: в частности, декодирование стало целиком выполняться за счет аппаратных модулей. Раньше последние стадии декодирования, Motion Compensation и Loop Filtering, выполнялись шейдерными процессорами графического ядра, так что выигрыш на практике заключается в чуть меньшем тепловыделении (и пропорционально увеличенном запасе TDP для Turbo Boost). Также реализована поддержка независимого декодирования нескольких «серьезных» потоков HD-видео, и хотя на практике даже 2 бывает нужно очень редко (для Blu-ray 3D), теоретической производительности новых GMA HD должно хватать минимум на 3-4.
«Победив» таким образом конкурентов (производители видеокарт и не знали, что с ними кто-то будет тягаться в такой дисциплине, как одновременное декодирование наибольшего числа HD-потоков), Intel нанесла неожиданный удар и на другом фронте. Пока AMD и NVIDIA вяло предлагали быстрое транскодирование видео за счет аппаратных кодеров в своих видеокартах (и интегрированных чипсетах), Intel предложила очень быстрое — назвав его технологией QuickSync. Правда, пока индустрия несколько задерживается с программами, которые умели бы использовать соответствующий модуль в процессорах на ядре Sandy Bridge, но как минимум два приличных продукта ArcSoft и CyberLink были готовы к моменту анонса новых процессоров.
Уточним: пока технология QuickSync реально применима на практике только в нескольких программных продуктах для транскодирования видео. Транскодирование — это специфическая задача, заключающаяся преимущественно в смене кодера или параметров кодирования исходного видеофайла, с возможными попутными правками вроде изменения размера кадра. Обычно это нужно только в одном случае: для проигрывания имеющегося видеофайла на устройстве, которое не поддерживает данный контейнер (но этот частный случай имеет более простое решение), формат, параметры кодирования видео и звука и т. п. Грубо говоря — для проигрывания на коммуникаторе/плеере/планшете, слишком маломощных, чтобы просто играть откуда-то взятый готовый файл. Альтернативным применением является перекодирование видео для демонстрации в онлайновых сервисах (будь то на Ютубе или Вконтакте), но там, в подавляющем числе случаев, транскодирование используется (причем принудительно) на стороне сервера (зачастую превращая ваш вылизанный клип в «квадратящий» кошмар родом из 90-х). Обычному пользователю в этот процесс никак не вмешаться, а потому нет и смысла делать транскодирование на домашнем компьютере — разве что у вас очень медленный интернет-канал, а исходное видео слишком уж большое.
Сформулируем иначе: для каких случаев транскодирование непригодно? Непригодно для создания серьезного рипа, при котором надо иметь полный контроль над параметрами кодирования. Непригодно для перекодирования при серьезной работе с исходником, к которому применяется куча фильтров с коррекцией цветов, сложный деинтерлейсинг, увеличение/снижение контурной резкости и пр. Непригодно для работы в серьезных монтажках, с наложением эффектов, переходов и пр. Справедливости ради, два последних применения могли бы быть закрыты. Тут вопрос не к Intel и не к идеологии QuickSync, а к наличию (точнее, отсутствию) подходящего ПО. Intel, со своей стороны, предлагает специальный интерфейс и регламентирующий его Media SDK — используя их, можно написать модуль, кодирующий видео за счет встроенной графики Intel, для какой-нибудь функциональной оболочки для кодирования видео с AviSynth-фильтрами, вроде XviD4PSP. Или написать плагин для Adobe Premiere, который бы сжимал видео при финальном рендеринге. Последний даже написан софтовой группой Intel, но находится в глубокой пре-альфа-стадии.
Однако ограничение на сложность и варьирование параметров кодирования пока остается в силе, так что QuickSync-кодирование будет применимо лишь в ограниченном количестве случаев. В частности, создатели x264 (несомненно лучшего и единственного достойного внимания отдельного кодера для H.264) объяснили, что для их продукта никакого выигрыша от использования Media SDK не будет, потому что основная ресурсоемкая часть при нормальном кодировании — сложная и очень сложная оценка движущихся объектов/частей кадра, Motion Estimation, а она на аппаратном уровне не выполняется.
Здесь надо сразу оговориться, что сравнивать кодировщики видео в терминах «лучший»/«худший» можно по разным критериям. Традиционно, новые форматы и кодеры изобретаются для того, чтобы в наименьший размер файла уложить видео наилучшего качества. Именно в этом смысле H.264 (MPEG-4 AVC) является лучшим современным форматом сжатия видео (превосходящим и всех предшественников, вроде MPEG-2 и MPEG-4 ASP, и конкурентов, вроде WebM и VC-1). Однако если не пытаться найти баланс между размером и качеством, можно легко прийти к выводам вроде «с достаточным битрейтом форматы друг от друга почти не отличаются — следовательно, H.264 ничем не лучше прочих». Более того, если принимать во внимание не только итоговый результат, но и процесс создания видео, начинают становиться значимыми самые разные факторы, вроде скорости кодирования и объема потребляемой в процессе памяти.
Именно на этом поле (для транскодирования в привычном смысле этого слова) QuickSync может выглядеть едва ли не лучшим. «Аппаратные» конкуренты (видеокарты NVIDIA и AMD) проигрывают ему в скорости (как уже говорилось, никто из них всерьез это соревнование не принимал), а «программные» — очень сильно проигрывают ему в скорости. А скорость — практически единственный важный параметр для транскодирования. Если вы перед выходом из дома сообразили, что неплохо бы взять с собой в дорогу киношку, но любимый фильм/свежая серия на компьютере только в HD-формате, который ваше мобильное устройство «не потянет», то разница между 5 минутами и часом — определяющая. Правда…
Правда, тут надо задаться вопросом, откуда вы берете это самое видео. Если речь идет о какой-то записи с семейной видеокамеры или о необходимости сделать рип любимого фильма с BD-диска (для личного использования, разумеется), то тут особых вариантов нет — перекодировать/транскодировать. А вот если вы кино берете «из торрентов», то почему не взять сразу версию, подходящую для мобильного устройства? Как показывает практика, все сколько-нибудь громкие фильмы и актуальные сериалы в «мобильной» версии выкладываются с той же оперативностью, что и «нормальные» («Игра престолов» с русским переводом порой появлялась даже быстрее в версии для смартфонов и КПК). Конечно, зоопарк устройств и разрешений… Но для стандартных разрешений (320×240 и 640×360, например), подходящих для множества устройств Apple и иже с ними, найдется всё. Что, соответственно, резко снижает привлекательность транскодирования в этой стране.
Конечно, приведенные теоретические выкладки требуют подтверждения на практике, к которой уже явно пора переходить.
Lucid Virtu на практике
Во-первых, как «возникает» у плат поддержка этой технологии, и как определить наличие или отсутствие таковой? Здесь применяется та же схема, что и со SLI на современных чипсетах: производитель платы покупает у LucidLogix (в случае SLI — у NVIDIA) лицензию, получает ключ, который прошивается в BIOS и проверяется драйвером при включении. Соответственно, платы с поддержкой Virtu должны быть дороже, и изначально предполагалось даже, что среди таковых будут числиться только [и без того более дорогие] решения на чипсете Z68. На практике, однако, можно сказать, что все ведущие производители (ASUS, Gigabyte, MSI, Intel…) внедрили поддержку этой технологии во все старшие модели, включая основанные на чипсете H67 (но вот на H61 мы таких наверняка не увидим). Узнать данный факт можно на сайте производителя платы — возможно, что поддержка Virtu появится в одной из новых прошивок, так что проверяйте периодически.
Хорошо: выбрали «правильную» плату, собрали на ней систему с дополнительной видеокартой, включили. Куда подключать монитор и что делать дальше? Для начала монитор можно подключать куда угодно (вывод загрузки Windows будет вестись на первичное устройство, выбранное в BIOS Setup). После загрузки ОС вам потребуется установить драйвер Virtu, качаемый с сайта LucidLogix (там наиболее свежая версия) — обратите внимание: драйверная поддержка есть только под Windows 7 (32- и 64-разрядную версии)! После установки драйвера один раз требуется перегрузиться — все дальнейшие смены режимов выполняются драйвером на лету.
О режиме функционирования Virtu свидетельствует панель управления. Там можно включать и отключать работу технологии в один щелчок мыши, при этом ничего не «падает» и не «глючит». При отключенной Virtu операционная система штатно работает с выводом обоих видеоускорителей — можно, например, подключить два монитора и расширить рабочий стол на монитор, подключенный к «неосновному» адаптеру. После включения Virtu активными становятся выходы только одного видеоускорителя: по умолчанию это «первичный» адаптер, но если к его выходам монитор не подключен, то драйвер Lucid автоматически меняет режим работы и считает основным второй адаптер и его монитор.
Технология Virtu отключена, работает внешняя видеокарта
Собственно режимов работы у Virtu два. Любопытно, что изначально предполагался только один — тот, который ныне носит название i-Mode. В этом режиме основным является интегрированной ускоритель, и картинка на монитор выводится с его выходов (распаянных на задней панели материнской платы). При этом по умолчанию все приложения запускаются на встроенной графике, и вывод картинки осуществляется естественным образом. Исключение делается только для приложений из специального списка — они запускаются на дискретной видеокарте, а драйвер осуществляет «подмену» буфера кадров. Разумеется, в случае i-Mode необходимость в исключениях есть только для игр, поэтому соответствующая закладка со списком приложений называется «Games». Новые («неизвестные драйверу») программы добавляются в этот список штатным образом, имеющиеся пункты списка можно отредактировать или отменить их применение (снять галочку).
Оригинальный список приложений, которые будут запущены на «неродном» ускорителе для d-Mode и i-Mode соответственно
Редактирование и добавление приложений в список исключений
Преимущества i-Mode, однако, были не слишком очевидны, а потерю производительности в играх признавал сам разработчик, так что под давлением прогрессивной общественности и здравого смысла в начале марта, примерно через две недели после официального анонса технологии, вышло обновление драйвера, добавляющее режим d-Mode. В этом режиме, очевидно, основным является внешний ускоритель, на котором и запускаются все приложения — кроме перечисленных в списке исключений. Пользователь может добавить туда любую программу (хоть любимую игрушку), но по умолчанию в этом списке значатся только две программы для транскодирования видео. Открытым, кстати, остается вопрос о том, как использовать, например, плагины для видеоредакторов, которые бы ускоряли вычисления за счет QuickSync. Видимо, в списке исключений для d-Mode придется указать основной файл редактора — но тут тоже возможны нежелательные последствия. Впрочем, до появления официальных версий таких плагинов вопрос остается теоретическим.
Технология Virtu включена
Никакого переключения между d-Mode и i-Mode в интерфейсе панели управления нет, оно полностью автоматическое: до тех пор, пока к «первичному» видеоадаптеру подключен монитор, будет работать режим, в котором вывод идет именно на это устройство отображения. При отсоединении монитора от первичного адаптера и подсоединении его к дополнительному мгновенно происходит переключение драйвера — вплоть до того, что если отключать монитор с панелью управления, открытой на закладке Games, то появившееся на «втором» мониторе через долю секунды изображение будет содержать уже закладку со списком исключений для нового режима. Единственная же интересная настройка в панели управления — возможность вывести на экран (на 3 секунды или на всё время работы) логотип Virtu в окне «виртуализуемого» приложения. (Это помогает при первом знакомстве убедиться, что технология работает.)
Кстати, при попытке проверить работу игр на GMA HD в режиме d-Mode (то есть выводя картинку через внешний ускоритель. Зачем это нужно? Ну, мы пока еще живем в свободной стране!) проявилось то ли ограничение, то ли ошибка драйвера. Игр как таковых в этом режиме в списке исключений не значится, и нет возможности «объяснить» драйверу, что мы не хотим играть на внешней карте. Попытка же добавить интересующую нас игру в список исключений вызывала аварийное сообщение о недопустимости подобного действия («приложение значится в списке для i-Mode!»), после чего драйвер сбрасывал настройки на умолчательные. Снятие галочки и даже удаление соответствующего пункта из списка после переключения в i-Mode ситуацию никак не меняло — видимо, драйвер в первую очередь сверяется с «зашитым» перечнем «игр». Конечно, это справедливо только для игр, внесенных в список по умолчанию, однако тот охватывает абсолютное большинство громких современных проектов и расширяется с каждым обновлением драйвера.
Отметим, что, по словам Lucid, никакой «оптимизации» под приложения списка не делается. Включение в него той или иной программы призвано облегчить участь пользователя (не надо заносить любимые приложения вручную) и служит неким актом сертификации: раз программа в списке — значит, разработчики хоть раз ее запустили и убедились, что все работает. О конкретных обнаруженных нами «глюках» поговорим ниже, но в целом, повторимся, драйвер производит приятное впечатление, и работа с ним (по крайней мере, с версией 1.2.103 в нашем случае) ни разу не выглядит открытым бета-тестированием.
Наконец, для самых пытливых приведем информацию о случае использования в системе нескольких внешних видеокарт. На текущий момент (при существующей версии драйвера) внешние видеокарты должны быть объединены с помощью SLI или CrossFire — иначе технология Virtu не сможет задействовать QuickSync встроенной графики.
Транскодирование видео с Virtu
Практика подтвердила, что задействовать QuickSync при выводе видео через внешнюю карту можно. Поскольку это, наверное, самый интересный вариант использования Lucid Virtu, начнем именно с него.
Для транскодирования мы использовали программу CyberLink MediaEspresso — один из двух «наиболее сертифицированных» проектов с поддержкой QuickSync и Virtu. MediaEspresso интересна тем, что поддерживает не только QuickSync, но и CUDA, а поскольку тесты мы проводили с внешней картой NVIDIA GeForce GTX 580, появилась возможность сравнить разные реализации прямо на одном стенде. В качестве исходного материала нами был выбран полноценный фильм, взятый в виде ремукса BD-диска на системном винчестере. На тестирование при этом ушло больше времени, но зато наши читатели получают возможность не только понять, кто кого быстрее, но и сразу увидеть актуальные цифры для транскодирования 2-часового фильма.
Собственно параметров кодирования MediaEspresso никаких выставить и не дает, что полностью соответствует общему положению дел у программ-конвертеров. В этом классе приложений, как правило, не пользуются такими выражениями, как профиль кодирования, битрейт, режим и пр. — вместо этого пользователю предлагается выбрать (из действительно огромного списка) свое мобильное устройство, для которого предназначается результирующий видеофайл. После выбора одного из таких вариантов MediaEspresso, в соответствии со своими предустановками, создала нам рип 640×360 с видео в формате H.264 (средний битрейт около 1500 Кбит/с) и стереозвуком в AAC (битрейт 128 Кбит/с). От перекодирования звука мы решили не отказываться (это соответствует реальному сценарию использования), хотя оно аппаратно не ускоряется в любом случае, несколько «смазывая», таким образом, чистые результаты кодирования видео.
Обратите внимание на логотип Virtu в левом верхнем углу окна. Монитор подключен к видеокарте NVIDIA.
После добавления основного файла с фильмом в программу остается только указать, использовать ли аппаратное ускорение, и какое именно. Правда, названы соответствующие настройки у MediaEspresso весьма своеобразно: для того, чтобы задействовать аппаратную поддержку CUDA, надо включить «Hardware acceleration encoding», а для задействования QuickSync — «Hardware acceleration decoding». Данная терминология полностью противоречит не только здравому смыслу, но и практике (о чем далее): декодирование (действительно необходимое в процессе транскодирования) — процесс, требующий минимума ресурсов, и даже ускорение его до бесконечности не способно сократить общее время транскодирования хотя бы вдвое. Очевидно, названия настроек остались от старых времен (графическое ядро Intel в процессах Clarkdale умело только декодировать видео). Однако функционирование настроек в итоге понятно, и, преодолев страх перед использованными терминами, мы получили 2 альтернативных (комбинируемых) варианта ускорения. Отметим, что QuickSync действительно может быть задействован только при использовании Virtu или при подключении монитора (на котором запускается MediaEspresso) к видеовыходам на материнской плате. А вот ускорение за счет CUDA можно было получить, просто установив видеокарту NVIDIA в систему.
Итак, не затягивая, приведем наиболее интересные результаты тестирования: время транскодирования 2-часового фильма в случае использования CUDA, QuickSync, обеих этих технологий и ни одной из них. Для сравнения возьмем результаты аналогичного перекодирования с помощью чисто программного x264 (тесты выполнялись на весьма серьезном процессоре Core i5-2400). Правда, параметры кодирования при этом нами подбирались исключительно из соображений скорости и похожести итоговых рипов: x264 запускался с пресетом ultrafast (самый быстрый из имеющихся), а видео кодировалось под профиль AVC Baseline@L3.0, без CABAC и с ReFrames=1. Повторимся: это не осмысленный выбор удачных параметров для кодирования, а выкручивание настроек на минимум, чтобы посоперничать по скорости.
И как видим, соперничать по скорости с QuickSync никто не может. Вообще. Даже близко. Не очень понятно, правда, где эффект от использования CUDA: включение этого режима не дает ничего (де-факто результат получается даже чуть хуже, чем без аппаратного ускорения вовсе), и совсем чуть-чуть помогает в случае, когда CUDA ассистирует герою дня — QuickSync. К нашему сожалению (или, наоборот, к гордости инженеров Intel), чисто программный x264 с аппаратным кодированием соперничать не смог даже несмотря на неимоверно упрощенные настройки. Более того, программное транскодирование MediaEspresso тоже осуществляет быстрее, хотя там уже разница незначительна (для целей практического применения).
Представленные выше результаты были получены в наиболее интересном режиме: монитор подключен к видеокарте NVIDIA, а QuickSync задействуется через Virtu. Получили бы мы какой-нибудь выигрыш, если бы QuickSync работал в «родном» режиме, без виртуализации вывода — когда монитор напрямую подключен к видеовыходам на материнской плате?
Нет. Потери на виртуализацию с лихвой укладываются в разброс результатов между прогонами. Кстати, мы попробовали, просто ради интереса, не отключить Virtu, а снять галочку в панели управления драйвера, которая говорила о том, что приложение MediaEspresso входит в список исключенных, и его надо запускать не на «родном» GeForce GTX 580, а на встроенной графике Intel. Результат оказался абсолютно предсказуемым: MediaEspresso при старте «не удалось» обнаружить в системе GMA HD, так что в перечне настроек возможность использовать QuickSync не значилась, а скорость кодирования оказалась почти такой же, как и при ручном выборе только CUDA или отказе от аппаратного ускорения вовсе в случае «полноценного» функционирования Lucid Virtu.
Кроме того, в ходе тестирования обнаружилась не самая очевидная возможность: если отказаться от задействования CUDA, интерфейс MediaEspresso предлагал какое-никакое, но управление процессом кодирования. Управление это сводится к выбору одного из двух значений: «Faster encoding» (быстрое кодирование) или «Better quality» (повышенное качество). Включение и выключение т. н. «Hardware acceleration decoding» (то есть задействование QuickSync) выбору не мешало, так что мы решили посмотреть, чем эти два режима отличаются.
По скорости, во всяком случае, они отличаются довольно заметно: почти в полтора раза (в пользу, разумеется, «Faster encoding»). Возможно, при использовании CUDA кодирование происходит в каком-то третьем режиме качества, и именно этим объясняется проигрыш по скорости кодирования при использовании только CUDA варианту без аппаратного ускорения вовсе.
Кстати, о качестве. Напомним, что повлиять на параметры кодирования в MediaEspresso мы не можем (кроме переключения Faster encoding/Better quality). В случае x264 мы выставили самый быстрый пресет кодирования и установили неоптимальный режим кодирования в целевой битрейт в один проход: в случае двух проходов разница по времени становилась уже катастрофической, а битрейт был выбран для того, чтобы получить сравнимые хоть по какому-то критерию файлы. (Благо MediaEspresso подозрительно точно попадает во всех режимах в один и тот же размер, так что, скорее всего, тоже кодирует в целевой битрейт, выбираемый из каких-то известных лишь программистам CyberLink соображений.)
Давайте взглянем на качество получаемой картинки: во всех случаях фрагменты (1:1) скриншотов увеличиваются до полного кадра на месте по щелчку мыши — если вертикальный размер окна в вашем браузере позволяет, можно быстро перещелкивать все доступные варианты.
| QuickSync (Faster encoding) | QuickSync (Better quality) |
 |  |
 |  |
| QuickSync и CUDA | x264 |
| QuickSync (Faster encoding) | QuickSync (Better quality) |
 |  |
 |  |
| QuickSync и CUDA | x264 |
| QuickSync (Faster encoding) | QuickSync (Better quality) |
 |  |
 |  |
| QuickSync и CUDA | x264 |
| QuickSync (Faster encoding) | QuickSync (Better quality) |
 |  |
 |  |
| QuickSync и CUDA | x264 |
| QuickSync (Faster encoding) | QuickSync (Better quality) |
 |  |
 |  |
| QuickSync и CUDA | x264 |
Также рекомендуем оценить разницу картинки в движении (она наиболее показательна) в нашем онлайновом плеере или у себя на компьютере, скачав соответствующие видеофрагменты.
| Кодирование QuickSync (Faster encoding) | файл .MP4, ≈20 МБ |
| Кодирование QuickSync (Better quality) | файл .MP4, ≈20 МБ |
| Кодирование QuickSync и CUDA | файл .MP4, ≈20 МБ |
| Кодирование x264 | файл .MP4, ≈20 МБ |
Итак, что бросается в глаза нам. Единственным заметно (в худшую сторону) выделяющимся вариантом является кодирование с использованием CUDA: даже за короткий представленный фрагмент можно найти несколько случаев, когда при резкой смене изображения в кадре качество картинки драматически ухудшается — впрочем, лишь на долю секунды. Кроме того, во всех «сложных» случаях картинка попросту размывается, поэтому на скриншотах это иногда выглядит более привлекательно, чем «честные квадраты» x264. Мы затрудняемся сказать (и даже предположить), чем это вызвано, потому что не очень представляем себе, за что конкретно в связке QuickSync+CUDA отвечает карта NVIDIA. Кодеру x264, в свою очередь, не хватает битрейта и «времени на раздумья» — вероятно, кодируй мы в два прохода (что вообще-то является штатным вариантом для кодирования в целевой битрейт), он бы более удачно оценил необходимость в битрейте для разных частей кадра. В то же время, если вы посмотрите на живое видео, а не на скриншоты, визуальные отличия от файлов, созданных с помощью QuickSync, практически не заметны. Результаты работы обоих режимов QuickSync довольно близки, и разница между ними действительно чуть-чуть в пользу Better quality. Между тем, битрейта для имеющегося видеоматериала недостаточно при столь ограниченном пространстве для маневра (Baseline@L3.0, без CABAC), так что во всех случаях наблюдаются артефакты изображения, хорошо видимые и невооруженным глазом в динамике (обратите внимание на небо в окончании заставки Paramount и пустыню в первых кадрах фильма).
У файла, созданного в x264, значительно лучше обстоят дела с прорисовкой прямых линий (сравните окончание заставки Marvel), точечных объектов (звезды на заставке Paramount) и т. п. (Но будем честны: подчеркнутые прямые линии и точки в обычном фильме почти не встречаются.) Причина успеха здесь, правда, кроется не в достоинствах x264, а в грамотном фильтре для изменения размера картинки: в нашем случае мы использовали штатный метод Lanczos4Resize (который применяется при создании 90% рипов — в остальных 10% используется что-нибудь более навороченное), а MediaEspresso, судя по результатам, использует совсем простой метод, как бы даже не билинейку. Как-то уж слишком близко к сердцу программисты CyberLink приняли совет по оптимизации от программистов Intel — минимально грузить процессор всякими фильтрами. Конечно, операция ресайза (которая всегда выполняется только процессором, аппаратного ускорения для нее нет) может существенно влиять на общую скорость процесса кодирования. И скорее всего, именно более простым методом ресайза объясняется разница в скорости между MediaEspresso (без аппаратного ускорения) и x264: разницу в 20% ресурсоемкий Lanczos4Resize вполне может обеспечить.
Более тщательное исследование этого вопроса, с различными методами для x264, обеспечило бы больше данных для сопоставления. Но главный результат останется неизменным: кодирование с помощью QuickSync значительно быстрее (даже если бы можно было уменьшить его скорость на 20% «правильным» ресайзом), а x264 значительно гибче в применении. В частности, нет сомнений, что при кодировании в High profile AVC (даже с ограничениями для поддержки DXVA, хотя кому она нужна для SD?) x264 выдал бы почти идеальную картинку при том же размере итогового файла. (Все-таки 1,44 ГБ для двухчасового фильма в разрешении 640×360 — это даже много.) В случае кодирования с QuickSync (при текущем уровне программной поддержки) пользователь не имеет никакой власти над результатом и улучшить ничего не сможет. Зато очень быстро получит результат. Не худший, чем при кодировании в x264, если загнать последний в неразумно жесткие рамки и задать ему ненормальные условия работы. А если не загонять и не задавать — то разница в скорости будет измеряться уже не разами, а порядком. И к тому же, не каждое мобильное устройство воспроизведет файл, полученный с «тяжелыми» настройками кодирования.
Видимо, короткий и достаточно очевидный вывод по этой части будет звучать так: транскодирующим — транскодирование.
Игры
Идея с обязательным применением i-Mode, к счастью, осталась в прошлом — сегодня владелец материнской платы на H67/Z68 с поддержкой Lucid Virtu спокойно может задействовать d-Mode, купив отдельную видеокарту. Но все же любопытно посмотреть, что теряли бы гордые владельцы топовых ускорителей, взбреди им в голову выводить картинку через встроенную графику. Очевидно, единственный интересный режим для проверки — игры. Давайте посмотрим на скоростные показатели в современных играх топового NVIDIA GeForce GTX 580 в, так сказать, «чистом виде» и «стреноженного» драйвером Virtu. Все тесты выполнялись в разрешении 1280×1024 (из-за ограничений монитора на тестовом стенде), но при максимально возможном качестве картинки (лишь в Metro 2033 были отключены Advanced PhysX и технология DOF).
Результаты, в общем, оказались не так уж плохи: потери от «шулерства» с экранным буфером составили порядка 6% в среднем (и лишь в Crysis Warhead достигли 12%). Тут нам стало любопытно проверить, какие факторы могут на эту разницу влиять — вот более подробные результаты в Crysis Warhead:
Выяснилось, что величина потерь растет с усложнением картинки (подъемом разрешения, уровня анизотропной фильтрации и сглаживания и пр.), а в минимальном режиме падения производительности от вывода картинки через Virtu почти нет. По-видимому, объяснение тут простейшее: в младших режимах видеокарта перестает быть ограничивающим фактором, и драйвер Lucid успевает делать свое «черное дело» совсем незаметно. Теоретически казалось возможным, что при этом будут заметнее потери из-за работы драйвера с памятью (раз производительность начинает упираться в процессор, то, скорее всего, и скорость обмена с памятью начинает играть бо́льшую роль), однако практика эту теорию не подтвердила: эффекта или нет вовсе, или он с лихвой перекрывается другими факторами.
Ну и раз мы заговорили об играх, не можем не привести показатели встроенной графики GMA HD 2000 (в процессоре Core i5-2400, с которым мы проводили тесты). Мы следуем принятой в последнее время на сайте концепции тестировать не старые игры в 640×480, а современные — и в сколько-нибудь приемлемом разрешении, пусть и ценой «выкручивания» всех настроек качества графики на минимум.
Особо порадовать вас нечем: за игровым прогрессом GMA HD никак не успевают, и даже в 1024×768 не способны выдать 30 fps в современных высокотехнологичных проектах. Впрочем, Plants vs. Zombies пойдут на таком видеоускорителе прекрасно, да и со стратегиями, не перенасыщенными 3D-наворотами, всё должно быть хорошо. Из проблем с качеством в небольшом количестве проверенных нами игр можем припомнить только Crysis Warhead — его DX10-режим оказался интегрированной графике не по зубам (экран в основном представлял собой богатую палитру «глюков»), в связи с чем игра на диаграмме представлена показателями своего DX9-движка (с ним вроде бы картинка была в порядке).
Отметим интересные проблемы, выявившиеся в работе Lucid Virtu при тестировании в игре Just Cause 2: во-первых, при выключенном V-Sync картинка постоянно мелко подергивалась, что просто ужасно диссонировало с «кинематографичным» стилем игры (c Motion Blur). Во-вторых, выяснилось, что игра, будучи запущенной на GeForce GTX 580 через Virtu, лишена пары графических настроек (Bokeh Filter, GPU water simulation) — при «нормальном» запуске они были на месте. Видимо, при запуске один из компонентов игры сначала проверяет возможности имеющегося ускорителя, а поскольку происходит это еще до инициализации 3D-режима, то информацию он получает от Intel GMA. Хуже всего в данном случае то, что обе настройки оказываются по умолчанию выключенными, и обладатель топового ускорителя просто не получит возможности их включить, даже если скорости хватает с избытком.
В общем, подводя итог этой части, можем сказать одно: спасибо компании Lucid за то, что реализовала d-Mode. С i-Mode не так много проблем, и по большей части они из категорий мелочей и недочетов, однако проблемы есть, как есть и потеря производительности, особенно обидная для владельцев топовых ускорителей. К счастью, повторимся, никакой реальной необходимости использовать i-Mode сегодня нет (из перечисленных выше потенциальных плюсов — в пользу этого режима говорит только широкий набор видеовыходов на материнской плате), и мы с чистым сердцем никому не рекомендуем этот вариант.
Экономия энергопотребления
Не забудем про экономию электроэнергии, которую нам тоже обещали в комплекте с Lucid Virtu. Правда, тогда речь шла о единственно существовавшем i-Mode, и был смысл объяснять пользователю, что это даже хорошо, когда топовая видеокарта используется только для игр, а в остальное время всеми «графическими делами» заведует встроенная графика. Сейчас мы рекомендуем все-таки применять d-Mode, к которому эти рассуждения применимы мало, но проверить их истинность интересно. К сожалению, по техническим причинам мы не можем предложить вам самого очевидного — результатов замеров потребления системы в разных режимах. Давайте воспользуемся косвенными данными.
Напомним, что в качестве дискретной видеокарты мы использовали топовый ускоритель NVIDIA — GeForce GTX 580 в исполнении Gigabyte. В режиме простоя этот ускоритель, как и все современные решения, снижает частоту работы своих блоков до минимального минимума и снижает частоту вращения своих вентиляторов (их у карты три). Однако вентиляторы все-таки не останавливаются, и режим карты не зависит от того, выводится ли картинка рабочего стола Windows через нее, через встроенную графику или через встроенную графику при активном драйвере Lucid Virtu.
Понятно, что при запуске игр вентиляторы на видеокарте «раскочегарятся» вслед за ядром и памятью. А что насчет кодирования видео? Если задействовать CUDA (какой бы там ни был толк от этой операции), шейдерные процессоры карты начинают активно работать, их частота поднимается, раскручиваются вентиляторы, увеличивается нагрев ядра. Любопытно, что при выполнении данной операции загрузка GPU составляет всего порядка 10%.
Чем нам может помочь в данном случае виртуализация графики? Давайте будем выводить картинку через видеовыходы материнской платы при включенном Virtu (хотя тут этому драйверу делать нечего, так как MediaEspresso не входит в число исключений, которые должны запускаться на внешней видеокарте), выполняя то же транскодирование с использованием CUDA.
Программа мониторинга не может отобразить количество занятой ускорителем NVIDIA памяти, когда основным ускорителем является GMA HD.
Видим… ровно то же самое. Как ни выводи картинку, работу с шейдерных процессоров видеокарты это не снимает. А значит, поднимается их частота, нагрев, скорость вращения вентиляторов.
А если не использовать при кодировании CUDA? Вот тут виртуализация вывода может внести свою небольшую лепту. При запуске некоторых приложений GPU начинает «ускоряться» — это происходит, например, при старте пакета PCMark7 и MediaEspresso (и процесса кодирования в последнем), но не происходит при старте, допустим, CPU-Z и Total Commander. Частоты блоков подскакивают, а вслед за ними и нагрев с частотой вращения вентиляторов. Впрочем, «обнаружив», что никакой работы для GPU на самом деле нет (ведь мы не используем при кодировании CUDA!), видеокарта через 15 секунд сбрасывает частоты на промежуточный уровень, а еще через 15 секунд — на прежний минимальный. За ними подтягиваются нагрев и вентиляторы — в Багдаде снова все спокойно. Центральный процессор тем временем вовсю «перемалывает» видео.
Если же в системе работает Lucid Virtu, и драйверу указано, что приложение MediaEspresso должно запускаться на GMA, то никакого всплеска активности карта NVIDIA не демонстрирует, мирно дрейфуя в состоянии простоя, пока не требуется ускорение CUDA.
Итак, практически никакой разницы между выводом картинки рабочего стола через внешнюю карту и через встроенную графику Intel мы не обнаружили. При наличии работы, будь то «нормальное» 3D или GPGPU (как в случае с ускорением кодирования видео с помощью CUDA), тепловыделение внешней карты возрастает. И возрастает оно одинаково в обоих случаях. Если же «настоящей» работы для внешнего видео нет, то энергопотребление карты в обоих случаях находится на одинаковом минимальном уровне. Кроме маленьких скачков потребления при запуске некоторых приложений (каким-то специальным образом инициализирующих графическую подсистему). Устранение вот этих вот 30-секундных всплесков тепловыделения при выводе картинки, кроме случаев со специально обозначенными 3D-исключениями, через встроенное видео — и есть единственный эффект в экономии энергопотребления, который нам удалось обнаружить. Излишне говорить, что эффект этот — копеечный (и в краткосрочной, и в долгосрочной перспективе).
Отметим, что в некоторых случаях (с плохо понятным анамнезом) частоты нашей карты NVIDIA при работе через драйвер Virtu не сбрасывались обратно до минимума после перехода в режим простоя. Никакого разумного объяснения этой ситуации нет: в начале работы частоты были минимальны (см. соответствующие числовые значения на следующем скриншоте), затем произошел их штатный подъем для кодирования с CUDA, затем частоты сбросились на промежуточный уровень, а затем… так и оставались на нем долгое время спустя после завершения всякой активности.
Единственный приходящий на ум вариант — недоработка в драйвере Virtu, NVIDIA или в их сочетании. Проблема вроде бы некритическая (обратите внимание, что нагрев карты лишь немного выше обычного при минимальных оборотах вентиляторов), но это, конечно, проблема. Возможно, новые версии драйверов ее устранят.
Выводы
В статье было очень много слов, абстрактных рассуждений, нужных и не очень нужных картинок, так что в заключении мы попробуем прибегнуть к лаконичному телеграфному стилю. Итак, что мы узнали, в чем убедились на практике, и какие выводы сделали?
- Компания LucidLogix предложила интересную программную технологию Virtu, которая реально работает и не требует для своего функционирования ни малейшей квалификации пользователя.
- Реализация технологии не свободна от проблем, однако критических среди них нет, а с введением в драйвере режима d-Mode устраняется, пожалуй, основная группа претензий к Virtu.
- Практический выигрыш от использования технологии невелик и проявляется лишь в очень специфическом режиме: Virtu позволяет задействовать встроенную графику процессоров Intel на ядре Sandy Bridge для очень быстрого аппаратного транскодирования видео (QuickSync) при штатном подключении монитора к внешнему видеоускорителю. Результат такого транскодирования неконтролируем и неидеален, но зато его скорость несравнима с существующими программными решениями.
- Сколько-нибудь существенной экономии энергии перенаправление вывода картинки на монитор через встроенную графику Intel не дает.
- Потенциально, некоторым пользователям может пригодиться i-Mode, если они не слишком требовательны к скорости в играх, а материнская плата предлагает более удобные варианты вывода картинки, чем внешняя видеокарта.
- Потенциально, Virtu позволяет задействовать параллельно оба видеоадаптера в системе без потери производительности каждым из них, но на практике очень сложно представить себе человека, одновременно транскодирующего видео и «рубящегося» в топовую игрушку.
Так нужна народу Lucid Virtu или не нужна? Гнаться за покупкой материнской платы с поддержкой этой технологии, или не стоит? На наш взгляд, нужна она лишь в очень ограниченном числе случаев, так что в общем — гнаться не стоит. Ситуация изменится, когда/если QuickSync станет можно использовать для более широкого круга задач, а не только для примитивного транскодирования. Когда наступит это светлое будущее и наступит ли оно вообще — зависит от создателей ПО для обработки видео; все вопросы — к ним.
Впрочем, на сладкое приведем еще одно соображение. Потенциальная аудитория QuickSync (и, во многих случаях, Lucid Virtu) стремительно возрастает в эти самые минуты. Не с каждой секундой или каждым часом, а с каждым купленным планшетом на базе NVIDIA Tegra 2. Как мы знаем, мощности этого универсального процессора на текущий момент недостаточно для воспроизведения нормальных HD-рипов, закодированных в MPEG-4 AVC High profile Level 4.1. (Оговорка «на текущий момент» отражает робкую надежду, что специалисты NVIDIA изыщут-таки программно-аппаратные ресурсы для декодирования такого видео, но реальных оснований для введения этой оговорки нет.) Что делать счастливым обладателям новенького планшета с экраном высокого разрешения, на котором нельзя нормально смотреть видео высокого разрешения?
Самостоятельно перекодировать свою коллекцию HD в MPEG-4 AVC Main profile (но это очень затратно по времени и месту для хранения). Искать «на торрентах» раздачи нужного видео в HD, но со слабыми настройками кодирования (вряд ли столь экзотическая потребность получит одобрение модераторов и распространенность). Или — транскодировать свое видео практически на лету! При этом размер итогового файла почти не имеет значения (уж в 16 ГБ встроенной памяти как-нибудь уместится, а хранить его вообще не нужно), а скорость создания очень важна (оперативное и тихое транскодирование перед выходом из дома vs. полноценное кодирование в течение нескольких часов с шумом вентиляторов). Под вопросом качество результата, но, надеемся, выбором одного из самых «насыщенных» пресетов его удастся удержать на приличном уровне. Страждущие, покупайте наши платы на H67 и Z68 с поддержкой технологии Lucid Virtu!
