Перевод документации драйвера NVIDIA для Linux, часть 13

Приложение С. Система наименования дисплеев

Понятие «Дисплей» относится к разновидности оборудования, способной отображать изображения. Дисплеи делятся на три категории: аналоговые электронно-лучевые (CRT), цифровые плоские панели (DFP), и телевизоры. Учтите, что аналоговые плоские панели драйвером принимаются за аналоговые электронно-лучевые мониторы.

Наименование дисплея – это строка, однозначно идентифицирующая дисплей в формате «<тип>-<номер>», например: "CRT-0", "CRT-1", "DFP-0", или "TV-0". Обратите внимание, что номер показывает, к какому выходу видеокарты подключен дисплей, и не имеет отношения к имеющемуся числу дисплеев этого типа. Это означает, что, например, может быть дисплей "CRT-1", даже если нет дисплея "CRT-0". Чтобы определить, какие дисплеи подключены, вы можете поискать в файле журнала Х-интерфейса строку вида:

(II) NVIDIA(0): Connected display device(s): CRT-0, DFP-0

Наименование дисплея может использоваться в опциях MetaMode, HorizSync, и VertRefresh конфигурации X-интерфейса для указания устройства, к которому должны применяться заданные настройки. Например:

Option "MetaModes" "CRT-0: 1600x1200, DFP-0: 1024x768"
Option "HorizSync" "CRT-0: 50-110; DFP-0: 40-70"
Option "VertRefresh" "CRT-0: 60-120; DFP-0: 60"

Указание наименования дисплея в этих опциях не является обязательным, если дисплеи не указаны, драйвер попытается сам определить, к какому дисплею относятся установки. В случае метарежимов, первый перечисленный видеорежим может быть истолкован как относящийся к основному дисплею, а второй – к дополнительному. К сожалению, не всегда очевидно, какой дисплей является основным или дополнительным. Вот почему указание наименований дисплеев предпочтительно.

При задании наименований дисплеев, вы можете также опустить номер из имени устройства, хотя это подходит только для случаев, когда имеется только по одному дисплею каждого типа. Например, если имеются один электронно-лучевой монитор и один цифровой плоский, вы можете указать их в метарежиме как показано ниже:

Option "MetaModes" "CRT: 1600x1200, DFP: 1024x768"

Если для какого-то дисплея возможно несколько совпадений, драйвер сначала пытается найти точное обозначение дисплея, затем тип дисплея, затем любое подходящее значение. Например, в:

Option "HorizSync" "CRT-0: 60-120, CRT: 60"

для дисплея CRT-0 будет выбрана первая запись, а для CRT-1 — вторая.

В режиме SLI Mosaic возможно использование одного и того же наименования для нескольких дисплеев, подключенных к разным графическим процессорам. Чтобы различать их, вы можете предварять наименование дисплея префиксом графического процессора. Например:

Option "MetaModes" "GPU-0.CRT-0: 1600x1200, GPU-1.CRT-0: 1024x768"

Если графическим процессор не указан для определенного наименования дисплея, настройки будут применены ко всем дисплеям с данным наименованием на всех графических процессорах.

Приложение D. Поддержка GLX

Эта версия поддерживает GLX 1.4. Дополнительно, на совместимых графических процессорах доступны следующие расширения:

GLX_EXT_visual_info
GLX_EXT_visual_rating
GLX_SGIX_fbconfig
GLX_SGIX_pbuffer
GLX_ARB_get_proc_address
GLX_SGI_video_sync
GLX_SGI_swap_control
GLX_ARB_multisample
GLX_NV_float_buffer
GLX_ARB_fbconfig_float
GLX_NV_swap_group
GLX_NV_video_out
GLX_EXT_texture_from_pixmap
GLX_NV_copy_image
GLX_ARB_create_context
GLX_EXT_import_context
GLX_EXT_fbconfig_packed_float
GLX_EXT_framebuffer_sRGB
GLX_NV_present_video
GLX_NV_multisample_coverage
GLX_EXT_swap_control
GLX_NV_video_capture
GLX_ARB_create_context_profile

За описанием этих расширений обратитесь к базе данных OpenGL.

Некоторые из вышеперечисленных расширений присутствуют как часть основной функциональности GLX 1.4, однако, они также могут быть экспортированы как расширения для обратной совместимости.

Также, в клиенте и сервере GLX от NVIDIA реализована поддержка следующих неофициальных расширений протокола GLX:

GL_ARB_draw_buffers_blend
GL_ARB_geometry_shader4
GL_ARB_sample_shading
GL_ARB_shader_objects
GL_ARB_texture_buffer_object
GL_ARB_vertex_buffer_object
GL_ARB_vertex_shader
GL_EXT_bindable_uniform
GL_EXT_compiled_vertex_array
GL_EXT_draw_buffers2
GL_EXT_geometry_shader4
GL_EXT_gpu_shader4
GL_EXT_separate_shader_objects
GL_EXT_texture_buffer_object
GL_EXT_texture_integer
GL_EXT_transform_feedback2
GL_NV_conditional_render
GL_NV_explicit_multisample
GL_NV_geometry_program4
GL_NV_transform_feedback
GL_NV_transform_feedback2
GL_NV_vertex_program
GL_NV_parameter_buffer_object
GL_NV_vertex_program4

Поддержка неофициального протокола GLX присутствует в GLX клиенте и сервере NVIDIA для следующих основных версий OpenGL:

OpenGL 2.0
OpenGL 2.1

Пока протокол GLX для данных расширений не будет завершен, использование их в непрямом рендеринге через GLX требует использования опции конфигурации Х-интерфейса «AllowUnofficialGLXProtocol» и задания переменной среды __GL_ALLOW_UNOFFICIAL_PROTOCOL для среды клиентского приложения. Неофициальный протокол требует использования библиотек NVIDIA GLX как на стороне сервера, так и на стороне клиента. Обратите внимание: протокол GLX используется при непрямом рендеринге приложения OpenGL (т.е. приложение исполняется на одном компьютере, но запрашивает протокол осуществить рендеринг изображения на другом компьютере). Вышеприведенные расширения полностью поддерживаются при прямом рендеринге.

GLX_visual и FBConfig поддерживаются только для экранов Х-интерфейса с глубиной цвета 16, 24 или 30-бит.

Приложение Е. Понятие DPI

Понятие DPI (точек на дюйм), также известное как PPI (пикселей на дюйм), является параметром экрана Х-интерфейса, описывающим физический размер пикселей. Некоторые приложения Х-интерфейса, такие как «xterm», могут использовать значение DPI экрана Х-интерфейса для определения размера (в пикселях) объектов для отображения объектов на дисплее с конкретным физическим размером экрана.

Разрешение DPI экрана X-интерфейса вычисляется путем деления размера экрана Х-интерфейса в пикселях на значение в дюймах:

DPI = Размер в пикселях / Размер в дюймах

Поскольку физический размер экрана X-интерфейса хранится в миллиметрах, а не в дюймах (1 дюйм = 25.4 миллиметра):

DPI = (Размер в пикселях * 25.4) / Размер в дюймах

Драйвер Х-интерфейса NVIDIA сообщает размер экрана Х-интерфейса в пикселях и миллиметрах. В серверах Х-интерфейса X.Org версии 6.9 и более новых при изменении размера экрана Х-интерфейса в пикселях через расширение XRandR, драйвер NVIDIA вычисляет новый размер в миллиметрах для экрана, сохраняя DPI постоянным (смотрите столбец "Physical Size" информации, выводимой по команде xrandr -q как пример). Это делается во избежание возможных проблем взаимодействия с некоторыми приложениями при изменении DPI. Для отключения этого поведения и сохранения того же значения размера экрана Х-интерфейса в миллиметрах (и возможности изменения DPI) присвойте опции ConstantDPI значение FALSE (обратитесь к приложению B за дополнительной информацией).

Вы можете узнать DPI вашего экрана Х-интерфейса, выполнив команду:

% xdpyinfo | grep -B1 dot

выдающую информацию вида:

dimensions: 1280x1024 pixels (382x302 millimeters) resolution: 85x86 dots per inch

Драйвер Х-интерфейса NVIDIA выполняет несколько действий в ходе инициализации экрана Х-интерфейса для определения разрешение DPI для каждого:

Если дисплей предоставляет информацию по протоколу EDID, и информация EDID включает сведения о физическом размере дисплея, то она используется для расчета значения DPI вместе с разрешением в пикселях первого видеорежима, устанавливаемого для дисплея. Если несколько дисплеев используются экраном Х-интерфейса, то драйвер NVIDIA сам выбирает, информацию какого дисплея использовать. Это поведение может быть изменено с помощью опции "UseEdidDpi" конфигурации X-интерфейса: вы можете указать конкретный дисплей для использования в расчетах; например:

Option "UseEdidDpi" "DFP-1"

или отключить вычисление DPI на основе информации EDID установкой значения опции false:

Option "UseEdidDpi" "FALSE"

Расчет DPI на основе сведений EDID используется по-умолчанию, если доступна информация EDID.
Если задан ключ запуска сервера Х-интерфейса -dpi, то его значение используется для установки DPI (смотрите команду X -h для получения дополнительной информации). Этот ключ имеет приоритет над опцией "UseEdidDpi".
Если задана опция "DPI" конфигурации X-интерфейса (обратитесь к приложению B за дополнительной информацией), то ее значение будет использовано для установки DPI. Эта опция имеет приоритет над опцией "UseEdidDpi".
Если ничего из вышеперечисленного не задано, используется опция "DisplaySize" файла конфигурации X-интерфейса секции Monitor для определения DPI, если задана; обратитесь к страницам руководства по xorg.conf или XF86Config за дополнительной информацией.
Если ничего из вышеперечисленного не указано, значение DPI принимается равным 75x75.

Вы можете посмотреть способ, которым драйвер Х-интерфейса NVIDIA определил значение DPI, обратившись к файлу журнала Х-интерфейса. В нем должна быть строка вида:

(--) NVIDIA(0): DPI set to (101, 101); computed from "UseEdidDpi" X config option

Обратите внимание, что физический размер экрана Х-интерфейса из отчета «xdpyinfo» вычисляется на основе значения DPI и размера экрана в пикселях.

Значение DPI экрана Х-интерфейса может быть выбрано неправильно при использовании TwinView: в режиме TwinView различные дисплеи (возможно с различным разрешением DPI) отображают часть общего экрана Х-интерфейса, вследствие чего значение DPI может сообщаться сервером Х-интерфейса приложению с точностью экрана Х-интерфейса. Возможные решения:

используйте отдельные экраны Х-интерфейса вместо TwinView; обратитесь к Главе 15 за дополнительной информацией;
пробуйте различные значения DPI для нахождения наиболее подходящего для обоих дисплеев.

Приложение F. Поддержка шины i2c

Модуль уровня ядра драйвера NVIDIA для Linux теперь поддерживает работу с шиной i2c (также называемой Inter-IC Communications, или IIC), позволяя модулю предоставлять доступ к найденным портам i2c на видеокарте на базе NVIDIA, также как и к дисплеям, подключенным к VGA и/или DVI разъемам, из модулей ядра или программ пользовательского пространства тем же способом, что и к другим портам шины i2c, экспортируемым ядром Linux через i2c framework.

Поддержка i2c должна быть скомпилирована в составе ядра или как модуль, и Х-интерфейс должен быть запущен. i2c framework доступен и в ядре версий 2.4, и в ядре версий 2.6. Документация по ядру Linux раскрывает /dev интерфейсы программирования ядра и пользовательского пространства, которые надо использовать для доступа к портам i2c NVIDIA.

Известно, что в некоторых дистрибутивах поддержка i2c включена, но модули ядра Linux i2c-core.o (2.4) или i2c-core.ko (2.6), осуществляющие экспортные функции, отсутствуют. В этих случаях требуется собрать модуль поддержки i2c самостоятельно. За инструкциями о том, как собрать и установить поддержку i2c на уровне ядра, обратитесь к документации дистрибутива.

За дополнительной информацией о Linux i2c framework обратитесь к документации ядра, расположенной в .../Documentation/i2c/ в дереве исходных текстов ядра.

Следующие функции поддерживаются в настоящее время:

I2C_FUNC_I2C
I2C_FUNC_SMBUS_QUICK
I2C_FUNC_SMBUS_BYTE
I2C_FUNC_SMBUS_BYTE_DATA
I2C_FUNC_SMBUS_WORD_DATA

Приложение G. Поддержка XvMC

Эта версия поддерживает API компенсации движения XVideo Motion Compensation (XvMC) версии 1.0 на графических процессорах GeForce 6 и GeForce 7 серий, а также на интегрированных в чипсет материнской платы графических процессорах, поддерживающих PureVideo. Доступны статическая библиотека libXvMCNVIDIA.a и динамическая libXvMCNVIDIA_dynamic.so, подходящая для вызовов dlopen. Поддерживаются уровни ускорения XvMC "IDCT", "motion-compensation", блоки изображения AI44 и IA44, а также поверхности с соотношением 4:2:0 вплоть до разрешения 2032x2032.

Библиотека «libXvMCNVIDIA» проверяет значение переменной среды XVMC_DEBUG и поддерживает вывод некоторой отладочной информации в «stderr» при определенных значениях переменной. Значение 0 отключает вывод отладочной информации, 1 включает вывод в случае ошибок, а 2 и выше выводят предупреждающие сообщения.

Приложение H. Поддержка VDPAU

Данный выпуск драйвера поддерживает API декодирования и воспроизведения видео для Unix-систем (VDPAU) для большинства графических процессоров семейства GeForce 8 и более новых, а также для интегрированных в чипсет материнской платы графических процессоров, поддерживающих технологию PureVideo.

VDPAU доступен лишь для экранов Х-интерфейса с глубиной цвета 16, 24 или 30-бит.

VDPAU поддерживает Xinerama при соблюдении следующих условий:

физический экран Х-интерфейса с номером 0 должен управляться драйвером NVIDIA;
VDPAU будет выводить изображение только на экранах Х-интерфейса, управляемых драйвером NVIDIA, подключенным к графическим процессорам, совместимым как с VDPAU, так и с графическим процессором, управляющим физическим экраном Х-интерфейса номер 0.

При активном расширении Xinerama VDPAU осуществляет все операции кроме вывода изображения лишь на одном графическом процессоре. По-умолчанию это процессор, управляющий физическим экраном Х-интерфейса 0. Переменная среды VDPAU_NVIDIA_XINERAMA_PHYSICAL_SCREEN может быть использована для указания номера экрана, тогда VDPAU будет исполняться на графическом процессоре, управляющем данным экраном. Значение переменной должно быть целым числом, соответствующем номеру экрана, как он задан в файле конфигурации Х-интерфейса. Выбранный экран должен обслуживаться драйвером NVIDIA.

H1. Ограничения реализации

VDPAU создан как общеполагающий интерфейс программирования (API) – выбор реализуемых функций и уровня производительности этих функций оставлен на усмотрение конкретных реализаторов. Особенности реализации NVIDIA приведены ниже.

VDPVIDEOSURFACE

Максимальное поддерживаемое разрешение составляет 4096x4096.

Следующие форматы поверхностей и форматы get-/put-bits поддерживаются:

VDP_CHROMA_TYPE_420 (поддерживаемые форматы get-/put-bits: VDP_YCBCR_FORMAT_NV12, VDP_YCBCR_FORMAT_YV12);
VDP_CHROMA_TYPE_422 (поддерживаемые форматы get-/put-bits: VDP_YCBCR_FORMAT_UYVY, VDP_YCBCR_FORMAT_YUYV).

VDPBITMAPSURFACE

Максимальное поддерживаемое разрешение составляет 16384x16384 пикселов для GeForce GTX 400 и более новых графических процессоров, 8192x8192 для прежних моделей.

Следующие форматы поверхностей поддерживаются:

VDP_RGBA_FORMAT_B8G8R8A8
VDP_RGBA_FORMAT_R8G8B8A8
VDP_RGBA_FORMAT_B10G10R10A2
VDP_RGBA_FORMAT_R10G10B10A2
VDP_RGBA_FORMAT_A8

Обратите внимание, что часто проверяемый параметр вызова VdpBitmapSurfaceCreate напрямую задает, будут ли данные изображения помещены в видеопамять (VDP_TRUE) или в системную память (VDP_FALSE). Учтите также, что если данные изображения не могут быть помещены в видеопамять из-за нехватки ресурсов, в текущей реализации автоматически произойдет переключение на хранение данных в системной памяти.

VDPOUTPUTSURFACE

Следующие форматы поверхностей поддерживаются:

VDP_RGBA_FORMAT_B8G8R8A8
VDP_RGBA_FORMAT_R10G10B10A2

Для всех форматов поверхностей поддерживаются следующие форматы get-/put-bits с индексированной цветовой палитрой:

VDP_INDEXED_FORMAT_A4I4
VDP_INDEXED_FORMAT_I4A4
VDP_INDEXED_FORMAT_A8I8
VDP_INDEXED_FORMAT_I8A8

Для всех форматов поверхностей поддерживаются следующие YCbCr форматы get-/put-bits:

VDP_YCBCR_FORMAT_Y8U8V8A8
VDP_YCBCR_FORMAT_V8U8Y8A8

VDPDECODER

Во всех случаях, объекты VdpDecoder поддерживают исключительно 8-битные 4:2:0 потоки, и запись только в поверхности VDP_CHROMA_TYPE_420.

Конкретный набор поддерживаемых значений VdpDecoderProfile зависит от используемого оборудования. Приложение A содержит информацию о наборе функций видеоускорения, поддерживаемом тем либо иным графическим процессором. Детали о наборах функций приведены ниже. Профили VC1_SIMPLE и VC1_MAIN могут относиться к WMV, WMV3 или WMV9 в различных случаях. Частичное ускорение означает, что VLD декодирование (декодирование потока) осуществляется центральным процессором, а графический процессор осуществляет преобразование IDCT и компенсацию движения. Полное ускорение означает, что и декодирование потока, и преобразование IDCT, и компенсация движения осуществляются графическим процессором.

Набор функций A:

Графические процессоры с набором функций VDPAU A поддерживают следующие значения и ограничения VdpDecoderProfile:

VDP_DECODER_PROFILE_MPEG1, VDP_DECODER_PROFILE_MPEG2_SIMPLE, VDP_DECODER_PROFILE_MPEG2_MAIN:
частичное ускорение;
минимальные ширина или высота: 3 макроблока (48 пикселей);
максимальные ширина или высота: 128 макроблоков (2048 пикселей);
максимально макроблоков: 8192
VDP_DECODER_PROFILE_H264_MAIN, VDP_DECODER_PROFILE_H264_HIGH:
полное ускорение;
минимальные ширина или высота: 3 макроблока (48 пикселей);
максимальные ширина или высота: 128 макроблоков (2048 пикселей);
максимально макроблоков: 8192
VDP_DECODER_PROFILE_VC1_SIMPLE, VDP_DECODER_PROFILE_VC1_MAIN, VDP_DECODER_PROFILE_VC1_ADVANCED:
частичное ускорение;
минимальные ширина или высота: 3 макроблока (48 пикселей);
максимальные ширина или высота: 128 макроблоков (2048 пикселей);
максимально макроблоков: 8190

Набор функций B:

Графические процессоры с набором функций VDPAU B поддерживают следующие значения и ограничения VdpDecoderProfile:

VDP_DECODER_PROFILE_MPEG1, VDP_DECODER_PROFILE_MPEG2_SIMPLE, VDP_DECODER_PROFILE_MPEG2_MAIN:
полное ускорение;
минимальные ширина или высота: 3 макроблока (48 пикселей);
максимальные ширина или высота: 128 макроблоков (2048 пикселей);
максимально макроблоков: 8192
VDP_DECODER_PROFILE_H264_MAIN, VDP_DECODER_PROFILE_H264_HIGH:
полное ускорение;
минимальные ширина или высота: 3 макроблока (48 пикселей);
максимальная ширина: 127 макроблоков (2032 пикселей);
максимальная высота: 128 макроблоков (2048 пикселей);
максимально макроблоков: 8190
VDP_DECODER_PROFILE_VC1_SIMPLE, VDP_DECODER_PROFILE_VC1_MAIN, VDP_DECODER_PROFILE_VC1_ADVANCED:
полное ускорение;
минимальные ширина или высота: 3 макроблока (48 пикселей);
максимальные ширина или высота: 128 макроблоков (2048 пикселей);
максимально макроблоков: 8190

Набор функций C:

Графические процессоры с набором функций VDPAU C поддерживают следующие значения и ограничения VdpDecoderProfile:

VDP_DECODER_PROFILE_MPEG1, VDP_DECODER_PROFILE_MPEG2_SIMPLE, VDP_DECODER_PROFILE_MPEG2_MAIN:
полное ускорение;
минимальные ширина или высота: 3 макроблока (48 пикселей);
максимальные ширина или высота: 128 макроблоков (2048 пикселей);
максимально макроблоков: 8192
VDP_DECODER_PROFILE_H264_MAIN, VDP_DECODER_PROFILE_H264_HIGH:
полное ускорение;
минимальные ширина или высота: 3 макроблока (48 пикселей);
максимальная ширина: 127 макроблоков (2032 пикселей);
максимальная высота: 128 макроблоков (2048 пикселей);
максимально макроблоков: 8190
VDP_DECODER_PROFILE_VC1_SIMPLE, VDP_DECODER_PROFILE_VC1_MAIN, VDP_DECODER_PROFILE_VC1_ADVANCED:
полное ускорение;
минимальные ширина или высота: 3 макроблока (48 пикселей);
максимальная ширина: 127 макроблоков (2032 пикселей);
максимальная высота: 128 макроблоков (2048 пикселей);
максимально макроблоков: 8190
VDP_DECODER_PROFILE_MPEG4_PART2_SP, VDP_DECODER_PROFILE_MPEG4_PART2_ASP, VDP_DECODER_PROFILE_DIVX4_QMOBILE, VDP_DECODER_PROFILE_DIVX4_MOBILE, VDP_DECODER_PROFILE_DIVX4_HOME_THEATER, VDP_DECODER_PROFILE_DIVX4_HD_1080P, VDP_DECODER_PROFILE_DIVX5_QMOBILE, VDP_DECODER_PROFILE_DIVX5_MOBILE, VDP_DECODER_PROFILE_DIVX5_HOME_THEATER, VDP_DECODER_PROFILE_DIVX5_HD_1080P
полное ускорение;
минимальные ширина или высота: 3 макроблока (48 пикселей);
максимальные ширина или высота: 128 макроблоков (2048 пикселей);
максимально макроблоков: 8192

Cледующие функции в настоящее время не поддерживаются:

GMC (глобальная компенсация движения);
разделение данных (Data partitioning);
обратимый VLC;

Эти графические процессоры также поддерживают VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L1.

Замечание 1 к наборам функций VDPAU

Графические процессоры, отмеченные данным замечанием, могут не поддерживать потоки H.264 со следующими значениями ширины: 49, 54, 59, 64, 113, 118, 123, 128 макроблоков (769-784, 849-864, 929-944, 1009-1024, 1793-1808, 1873-1888, 1953-1968, 2033-2048 пикселов).

VDPVIDEOMIXER

Максимальное поддерживаемое разрешение составляет 4096x4096.

Видеомикшер поддерживает все разрешения и форматы поверхностей, которые поддерживаются в данной реализации. Видеомикшер поддерживает максимум 4 вспомогательных уровня.

Следующие функции поддерживаются:

VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL
VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL_SPATIAL
VDP_VIDEO_MIXER_FEATURE_INVERSE_TELECINE
VDP_VIDEO_MIXER_FEATURE_NOISE_REDUCTION
VDP_VIDEO_MIXER_FEATURE_SHARPNESS
VDP_VIDEO_MIXER_FEATURE_LUMA_KEY

Для корректной работы функций VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL или VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL_SPATIAL, приложение должно поддерживать как минимум два прошлых и одно будущее поле для каждого вызова VdpMixerRender. Если эти поля не предоставлены, VdpMixer переключится обратно на устранение чересстрочности (deinterlacing) по методу bob.

Поддерживается как устранение чересстрочности с частотой кадров на выходе, равной частоте полей в исходном потоке (regular), так и с частотой кадров на выходе, равной половине частоты полей в исходном потоке (half-rate). Оба способа имеют равные требования по числу прошлых/будущих полей для микшера. Оба способа дают одинаковое качество изображения в итоге.

Для получения эффекта от функции VDP_VIDEO_MIXER_FEATURE_INVERSE_TELECINE, одна из функций VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL или VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL_SPATIAL должна быть запрошена и активна. Обратное преобразование (Inverse telecine) имеет аналогичное требование по числу предоставленных прошлых и будущих полей. Обратное преобразование не работает при использовании устранения чересстрочности способом «half-rate».

Хотя возможно применение алгоритмов устранения чересстрочности к видеопотокам с построчной разверткой, эта функция не расписана в документации VDPAU API, NVIDIA не рекомендует подобное их использование. Оно, вероятно, создаст больше искажений при обратном преобразовании, нежели было устранено механизмом определения ошибок в видеопотоке.

VDPPRESENTATIONQUEUE

Точность для VdpTime составляет приблизительно 10 нс. В некоторой точке во время загрузки операционной системы начальное значение часов синхронизируется с показателями системных часов реального времени в формате числа наносекунд, прошедшего с 1 января 1970 г. Однако, никаких попыток поддержания данных временных показателей синхронизированными после этого не предпринимается. Расхождение может возникать и возникает на практике.

В реализации NVIDIA функция VdpPresentationQueue поддерживает два механизма отображения поверхностей: наложение (overlay) и побитовое копирование (blit). По возможности будут использоваться наложения, а побитовое копирование применяется в крайнем случае.

При создании очереди представления, драйвер определяет возможность использования наложений, основываясь на конфигурации системы и использовании или неиспользовании наложения другим приложением. Если наложение возможно использовать, очередь помечается как владелец наложения.

При выводе изображения с поверхности, драйвер определяет, можно ли использовать наложение для данного кадра, основываясь одновременно на наличии признака владельца наложения у очереди представления и ограничениях использования наложений, перечисленных ниже. Драйвер может динамически переключаться между наложением и побитовым копированием от кадра к кадру. Наиболее частая причина для такого поведения — включение/отключение диспетчера composite, когда окно то становится, то перестаёт быть перенаправляемым.

Следующие обстоятельства или настройки системы могут препятствовать использованию наложения:

аппаратная часть, осуществляющая наложение, уже используется, например другим процессом VDPAU, приложением OpenGL или X11, или для видеовыхода SDI;
для выбранного экрана Х-интерфейса активна функция поворота рабочего стола;
целевое окно становится перенаправляемым вследствие активности диспетчера composite;
переменной среды VDPAU_NVIDIA_NO_OVERLAY установлено значение, отличное от нуля;
драйвер определяет, что требования к производительности использования наложения не могут быть достигнуты при текущей конфигурации оборудования.

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

При использовании TwinView вывод изображения через побитовое копирование может быть синхронизирован лишь с одним из дисплеев; это может приводить к перекосу изображения на дисплее, с которым вывод не синхронизирован. Вы можете воспользоваться переменной среды VDPAU_NVIDIA_SYNC_DISPLAY_DEVICE чтобы задать дисплей, с которым VDPAU должен синхронизироваться. Следует присвоить переменной значением имя дисплея, например: "CRT-1". Посмотрите строку "Connected display device(s):" в файле журнала X-интерфейса для получения списка подключенных дисплеев и их названий. Также полезно ознакомиться c Главой 13 «Настройка TwinView» и разделом «Приведение параметров временной синхронизации видеорежимов к идентичным значениям» в Главе 19.

VdpPresentationQueue допускает максимум 8 поверхностей одновременно в состояниях «QUEUED» или «VISIBLE». Данное ограничение установлено на каждую очередь. Если лимит превышен, в текущей реализации VdpPresentationQueueDisplay блокируется до освобождения места в очереди представления.

H2. Уровни производительности

В данном документе описаны возможности VDPAU в реализации NVIDIA. Производительность аппаратного выполнения может существенно различаться между разными видеокартами. Не предоставляется никаких гарантий, что любая конкретная комбинация настроек системы, графического процессора, набора функций VDPAU, использования VDPAU API, приложения, видеопотока и так далее сможет обеспечить декодирование потока с любой конкретной частотой кадров.

H3. Достижение максимальной производительности при использовании API

Быстродействие системы (общая полоса пропускания, задержка и устойчивость к джиттеру) может зависеть от множества факторов. Одним из них являются особенности использования VDPAU клиентским приложением; то есть число поверхностей, размещенных для буферизации, порядок операций и так далее.

Графические процессоры NVIDIA обычно имеют конечное значение специализированных отдельных блоков, способных осуществлять различные этапы декодирования видео, постобработку и вывод изображения параллельно. Для достижения максимальной производительности клиентское приложение должно стараться обеспечить все эти блоки постоянной загрузкой.

Обратимся к процессу декодирования видео. Как абсолютный минимум, приложение должно разместить одну поверхность для видео на каждый опорный кадр который поток может использовать (2 для MPEG или VC-1, в зависимости от потока для H.264), плюс одну поверхность для изображения, декодируемого в данный момент. Однако, при таком минимуме поверхностей производительность может быть плохой, поскольку для декодирования связанных промежуточных кадров требуется их запись в одну и ту же поверхность. Это означает, что для декодирования следующего кадра приходится ожидать окончания декодирования предыдущего; затор в трубе.

Далее, если поверхности с видео считываются видеомикшером для постобработки и окончательного вывода на экран, это означает блокировку поверхностей на дополнительное время, так как видеомикшеру надо прочитать все данные с поверхности, что мешает следующим операциям декодирования записать данные в поверхность. Вспомним, что для операций устранения чересстрочности видеомикшеру требуется предоставить всю историю видео с поверхностей, что означает необходимость размещения еще большего числа поверхностей для видео.

В силу данных причин, NVIDIA рекомендует размещать следующие количества поверхностей для видео:

(num_ref + 3) для построчного видео, без устранения чересстрочности;
(num_ref + 5) Для чересстрочного видео с устранением черессточности.

Следует учесть наличие зависимостей между выводом изображения и очередью представления. Для данной части процесса требуется минимум две выводных поверхности; одна для вывода текущего изображения из очереди, вторая для следующего. Как и прежде, использование минимального количества поверхностей может быть не оптимальным. Для некоторых видеопотоков оборудование может обеспечить лишь усредненное декодирование в реальном времени, не для каждого индивидуального кадра. Использование composite API для отображения налагаемых экранных меню, графического интерфейса и тому подобного может привнести дополнительные джиттер и задержки в процесс декодирования. Дополнительно, системные особенности вроде алгоритма диспетчеризации и текущей загрузки системы могут на короткое время помешать работе выполняющейся на центральном процессоре части драйвера. Обеих потенциальных проблем можно избежать размещением большего числа выводных поверхностей, и постановки в очередь более чем одной поверхности в очереди представления.

Использование большего, чем минимально необходимого, количества поверхностей для хранения видео позволяет избежать простоя декодирующих и осуществляющих постобработку блоков, сохраняя их загруженными максимально долго. Использование большего, чем минимально необходимого, количества поверхностей для вывода видео позволяет скрыть джиттер и задержки различных операций графического и центрального процессора.

Выбор числа размещаемых поверхностей представляет собой балансирование между улучшением производительности и расходом ресурсов; размещение большего, чем минимальное, числа поверхностей повысит быстродействие, но потребует пропорционального расхода видеопамяти. Это может привести к неработоспособности приложения. Выбор особенно труден в системах с небольшим объемом видеопамяти. Хорошее приложение будет автоматически подстраиваться, изначально размещая абсолютный минимум поверхностей (ошибка может стать фатальной), затем постепенно пытаться разместить больше и больше поверхностей, пока размещения проходят удачно, вплоть до вышеозначенных пределов.

Расход памяти декодером также пропорционален максимальному числу опорных кадров, заданному при создании. Запрос большего числа опорных кадров может значительно повысить расход памяти. Для приложений наилучшим будет указывать актуальное для текущего потока число опорных кадров, нежели жестко заданный предел в 16 или максимальное число поверхностей, предписанное конкретным уровнем H.264 для разрешения потока.

Обратите внимание, что в реализации NVIDIA обеспечиваются все необходимые взаимозависимости между различными аппаратными блоками. В приложении не следует заботиться о правильности декодирования (при условии, что API используется правильно и разумно), заботиться следует лишь о производительности.

H4. Дополнительные замечания

Обратите внимание, что поверхности вывода и битовые карты не заполняются чем-либо после размещения. Приложение ответственно за инициализацию всех поверхностей перед использованием их в качестве источника для какой-либо функции. Видеоповерхности же заполняются черным при размещении.

H5. Отладка

Библиотека враппера VDPAU позволяет отслеживать вызовы функций VDPAU и их параметры. Отслеживание управляется переменной среды:

VDPAU_TRACE

Включает отслеживание. Присвойте значение 1 для отслеживания вызовов функций, 2 для отслеживания всех аргументов функций.

VDPAU_TRACE_FILE

Файл, куда будут записываться результаты слежения. По-умолчанию, результаты выводятся в «stderr». Переменная может принимать значение имени файла или ссылки на имеющийся открытый дескриптор файла в формате "&N", где N – номер дескриптора.

Библиотека враппера VDPAU ответственна за определение загруженного для конкретного экрана/дисплея X11 специального драйвера от производителя. В настоящее время в ней жестко приписано "nvidia" в качестве драйвера. С помощью переменной среды VDPAU_DRIVER можно переназначить данное поведение. Загружаемой библиотекой будет libvdpau_${VDPAU_DRIVER}.so. Присвоение переменной VDPAU_DRIVER значения "trace" не рекомендуется.

Драйвер VDPAU NVIDIA может сообщать некоторую диагностическую информацию в случае ошибки. Для включения этого механизма используйте переменную среды VDPAU_NVIDIA_DEBUG. Значение 1 выдаст небольшой объем диагностической информации, который позволит инженерам NVIDIA определить источник проблемы. При значении 3 будет выведено полное содержание стека, что позволить инженерам NVIDIA получить расширенную информацию, потребную для диагностики некоторых проблем.

H6. Многопоточность

В VDPAU поддерживается исполнение нескольких потоков в рамках процесса драйвера, но имеется ряд ограничений.

В момент создания или удаления любого объекта драйвер VDPAU переходит в режим однопоточности. Это включает в себя удаление объектов во время очистки.

В прочих случаях может существовать до одного потока VdpDecoderRender на каждый объект VdpDecoder, и до одного потока, выполняющего другие API рендеринга на объект VdpDevice или дочерний от него. Драйвер применяет данные ограничения внутри себя, от приложений не требуется следовать вышеуказанным правилам.

Некоторые вызовы API вида «query» или «get» могут выполняться независимо от числа потоков рендеринга, активных в этот момент.