CC BY
59
Программный модуль может найти применение для широкого круга задач, где требуется синтез высококачественного видеоматериала, в том числе при построении имитационно-тренажерных комплексов, обучающих систем и игровых приложений. В дальнейших исследованиях предполагается рассмотреть вопрос более эффективного сжатия файлов записей, а также поддержку дополнительных контейнеров хранения видеоданных (т^, тр4, ts).
Литература
1. Михайлюк М.В. Компьютерная графика в системах визуализации имитационно-тренажерных комплексов // Программные продукты и системы. 2003. № 3. С. 7-15.
2. Михайлюк М.В., Торгашев М.А. Система «GLVIEW» визуализации для моделирующих комплексов и систем виртуальной реальности // Вестн. РАЕН. 2011. № 2. С 20-28.
3. Хураськин И.А. Создание виртуального окружения в тренажерных комплексах: сб. докл. междунар. науч. конф., посвященной 80-летию со дня рожд. акад. В.А. Мельникова, 2009. С. 122-125.
4. Торгашев М.А. Реализация стереорежима в реальном
масштабе времени для различных устройств отображения // Программные продукты и системы. 2010. № 2. C. 23-29.
5. Торгашев М.А. Реализация режимов записи и воспроизведения тренировок в имитационно-тренажерных комплексах моделирования сложных динамических систем: сб. тр. НИИСИ РАН, 2011. Т. 1. № 2. C. 59-61.
6. Боресков А.В. Разработка и отладка шейдеров. СПб, 2006. 496 с.
References
1. Mikhailyuk M.A., Programmnye Produkty i Sistemy, 2003, no. 3, pp. 7-15.
2. Mikhailyuk M.V., Torgashev M.A., Vestnik RAEN, 2011, no. 2, pp. 20-28.
3. Khuraskin I.A., Sbornik Dokladov Mezhdunar. Nauch. Konf., posvjashhennoy 80-letiju so dnja rozhd. akad. V.A. Melniko-va, (Proc. International researchers conference dedicated to the 80th anniversary of the Acad. V.A. Melnikov), 2009, pp. 122-125.
4. Torgashev M.A., Programmnye Produkty i Sistemy, 2010, no. 2, pp. 23-29.
5. Torgashev M.A., Collworks NIISI RAN, 2011, Vol. 1, no. 2, pp. 59-61.
6. Boreskov A.V., Razrabotka i otladka sheiderov (Shaders' Develoment and Debugging), St. Petersburg: BHV-Peterburg, 2006, 496 p.
УДК 004.921
ОТОБРАЖЕНИЕ РАЗНОРОДНЫХ ВИДЕОМАТЕРИАЛОВ НА ГРАНЯХ ТРЕХМЕРНЫХ ОБЪЕКТОВ В ПОДСИСТЕМЕ ВИЗУАЛИЗАЦИИ ТРЕНАЖЕРНЫХ ОБУЧАЮЩИХ СИСТЕМ
(Работа выполняется при поддержке РФФИ, грант № 11-07-00158-а) А.М. Гиацинтов
(Центр визуализации и спутниковъх информационнъж технологий НИИСИ РАН, [email protected])
Описаны новый метод воспроизведения разнородных видеоматериалов на гранях объектов виртуальной трехмерной сцены и архитектура декодера видеофайлов. Рассмотрены алгоритм синхронизации видео- и аудиоданных и методы загрузки декодированных видеокадров в память видеоадаптера. Определены ограничения, накладываемые на процесс воспроизведения видеофайлов в трехмерной виртуальной среде.
Тренажерно-обучающие системы (ТОС) должны отвечать требованиям методик подготовки персонала и, как правило, содержат значительное количество информационных ресурсов. Одним из видов ресурсов, используемых при обучении, являются видеоматериалы. Главные преимущества их использования в ТОС - возможность визуализации процессов и внедрение изображения инструктора в виртуальное окружение.
Воспроизведение видеоматериалов внутри виртуальной трехмерной сцены является сложной задачей, так как необходимо учитывать факторы, не актуальные при воспроизведении в медиаплеерах. Графическая подсистема должна визуализировать трехмерную сцену с приемлемой частотой кадров (не менее 25 кадров в секунду) и при этом быть способной реагировать на внешние воздействия, в том числе на изменения параметров трехмерной сцены или загрузку дополнительных объектов.
Разработанная архитектура подсистемы воспроизведения видеоматериалов позволяет декодировать и отображать одновременно несколько видео высокой четкости в трехмерной сцене. В состав архитектуры входят: декодер видео, в котором происходит декодирование видео- и аудиопакетов; подсистема воспроизведения декодированного звука; управляющая структура, необходимая для запуска видео, паузы воспроизведения, выставления громкости воспроизводимого видео и т.д.; интерфейс взаимодействия с подсистемой визуализации, необходимый для обновления видеокадров.
Ключевые слова: рендеринг, система визуализации, тренажерно-обучающая система, ТОС, видеоматериалы, декодер видео, FFmpeg.
PLAYBACK OF HETEROGENEOUS VIDEOS ON 3D OBJECT'S EDGES IN VISUALIZATION SUBSYSTEM OF TRAINING SIMULATION SYSTEM Giatsintov A.M. (Center of Visualization and Satellite Information Technologies SRISA RAS, [email protected] Abstract. This article describes a new method of playing heterogeneous videos on edges of objects in virtual 3d scene. Architecture of video files decoder is presented, algorithms for syncing audio and video data are depicted, as well as methods
of uploading decoded video frames to the videocard memory. Limitations and issues of video playback in virtual scene are analyzed.
Training Simulation Systems (TSS) should conform to the requirements of personnel training methods and usually contain a large number of informational resources. One type of resources that is used in training is video. Main advantages of using videos in TSS are: ability to visualize different processes and integration of instructor image into the virtual 3d scene.
Video playback in virtual 3d scene is a complex task because there are factors to consider that are not relevant when playing video in media player. Visualization subsystem must be able to achieve acceptable framerate (not lesser than 25 frames per second) and react to external actions, such as scene parameters change and loading of additional objects.
Developed architecture of video playback subsystem makes it possible to decode and visualize several high definition videos in 3d scene. The developed architecture consists of following components: video decoder that decodes video and audio packets; sound subsystem that plays the decoded sound; control module that is used to play specific video, pause it, set its volume and so on; interface that glues the video playback subsystem with visualization subsystem.
Keywords: rendering, visualization system, training simulation system, TSS, video, video decoder, FFmpeg.
По определению, тренажерно-обучающие системы (ТОС) - разновидность технических систем, позволяющих решать задачи подготовки персонала с целью обучения управлению сложными техническими системами, в том числе в условиях, создающих угрозу жизни (агрессивные среды) или принудительно не реализуемых в реальной среде. Кроме формирования индивидуальных профессиональных навыков и умений, ТОС могут применяться для отработки групповых операций.
Подсистема визуализации обеспечивает отображение результатов моделирования внешней среды и объекта управления с помощью устройств отображения информации. Отображение разнородных видеоматериалов в виртуальной трехмерной сцене является одним из требований к ТОС.
Для отображения видеоматериалов в подсистеме визуализации была выбрана кросс-платформенная система декодирования видеофайлов FFmpeg, распространяемая по лицензии LGPL. Пакет FFmpeg не предоставляет возможностей для визуализации декодированных видеоизображений и воспроизведения звуковых данных. Для воспроизведения звуковых данных из декодируемого видеофайла был использован пакет SFML, распространяемый по лицензии zlib/png. В качестве основы подсистемы визуализации ТОС использован графический движок Horde3D, распространяемый по лицензии EPL.
Воспроизведение видеоматериалов внутри виртуальной трехмерной сцены является сложной задачей, поскольку необходимо учитывать факторы, не актуальные при воспроизведении в медиа-плеерах. Графическая подсистема должна визуализировать трехмерную сцену с приемлемой частотой кадров (не менее 25 кадров в секунду) и при этом быть способной реагировать на внешние воздействия, в том числе на изменения параметров трехмерной сцены или загрузку дополнительных объектов.
Разработанная архитектура подсистемы воспроизведения видеоматериалов позволяет декодировать и отображать одновременно несколько видео высокой четкости в трехмерной сцене. В ее архитектуру входят: декодер видео, в котором происходит декодирование видео- и аудиопакетов; подсистема воспроизведения декодированного
звука; управляющая структура, необходимая для запуска видео, паузы воспроизведения, выставления громкости воспроизводимого видео и т.д.; интерфейс взаимодействия с подсистемой визуализации, необходимый для обновления видеокадров.
Общая схема работы декодера показана на рисунке 1.
Рис. 1. Схема работы декодера видеофайла
Во время инициализации декодера считывают-ся все необходимые параметры о видеофайле: кодеки, используемые для сжатия видео- и аудиоинформации, количество звуковых и видеопотоков в файле, ширина и высота (разрешение) видео, количество каналов звука и т.д.
Размещение пакетов в файле зависит от формата видеофайла, поэтому сложно предсказать, в каком порядке будут следовать видео- и аудиопа-кеты. Это может привести к ситуации, когда очередь видеопакетов заполнена, а очередь аудио-пакетов пуста. Узнать тип следующего пакета невозможно до его чтения. Если следующий видеопакет окажется закодированным видеокадром, то его необходимо либо поместить в очередь видеопакетов, то есть превысить заданные рамки очереди, либо удалить, что приводит к артефактам на конечном изображении или пропущенным кадрам и рывкам воспроизводимого видео. Для решения этой проблемы было принято решение создать
третью очередь пакетов, в которую помещаются пакеты различного типа из видеофайла, а затем сортируются по типу (аудио или видео) в одну из очередей. Сортировка осуществляется по методу FIFO («первый вошел, первый вышел»).
Видеодекодер проверяет, есть ли пакеты в очереди видеопакетов, и при их наличии забирает пакет из начала очереди. Процесс декодирования видеопакета происходит в два этапа: декодирование пакета и преобразование декодированного кадра в необходимую цветовую модель. После декодирования и преобразования в другую цветовую модель кадр помещается в очередь декодированных кадров. Аналогично аудиодекодер проверяет наличие пакетов в очереди и при наличии пакетов декодирует первый пакет из очереди. После декодирования звуковые данные в формате PCM помещаются в очередь декодированных звуковых данных.
Процесс декодирования ресурсоемкий. Так, декодирование одного видеопакета с разрешением 1280 на 720 (720p) на процессоре Intel Core 2 Quad 2,66 ГГц занимает от 5 до 10 мс, для видео размером 1920 на 1080 (1080p) - от 10 до 20 мс. Декодирование пакета звуковых данных занимает значительно меньше времени (0,5-2 мс), но если одновременно декодируется звук для нескольких воспроизводимых видео, это может серьезно снизить производительность. Скорость получения пакетов из видеофайла ограничивается производительностью системы хранения данных (СХД), что, в свою очередь, влияет на производительность подсистемы визуализации. Задержки образуются, если в момент считывания пакетов из видеофайла СХД обрабатывала другие команды либо файл являлся фрагментированным, что заставило бы СХД искать фрагменты данного файла. Для преодоления проблем с производительностью была использована многопоточность.
Многопоточность - свойство платформы (например операционной системы) или приложения, состоящее в том, что процесс, запущенный на платформе, может состоять из нескольких потоков, выполняющихся параллельно, то есть без предписанного порядка во времени. При выполнении некоторых задач такое разделение позволяет достичь более эффективного использования ресурсов вычислительной машины.
Для оптимизации процесса декодирования видео используются отдельные потоки для сбора пакетов, декодирования видео- и аудиопакетов. Процесс воспроизведения звука также происходит в дополнительном потоке. Для реализации много-поточности было принято решение интегрировать библиотеку управления потоками thread системы boost.
Система boost - это набор кросс-платформенных библиотек, расширяющих стандартные инструменты языка C++ и распространяемых по
лицензии Boost Software License. Некоторые библиотеки являются кандидатами на включение в следующий стандарт языка C++.
Обновление видеотекстуры в подсистеме визуализации осуществляется в основном потоке программы (потоке рендеринга). Каждый кадр подсистемы визуализации проходит проверку -следует ли обновлять видеотекстуру в трехмерной сцене или нет. Если обновление требуется, видеокадр берется из очереди декодированных кадров и помещается в память видеокарты в качестве текстуры, которая может быть наложена на поверхность любого трехмерного объекта.
При запуске видео создается пустая текстура с размерами видеокадра, которая затем применяется к материалу трехмерного объекта (материал объекта определяет, какие текстуры и шейдеры использует данный трехмерный объект). Перед применением новой текстуры к материалу выполняется резервное копирование старого материала для возможности возвращения к исходным текстурам объекта после окончания воспроизведения видео. Для повышения производительности используются два так называемых пиксельных буфера, которые применяются для хранения пиксельных данных (текстуры) в видеопамяти и позволяют значительно снизить временные затраты на обновление видеотекстуры в подсистеме визуализации. При использовании стандартной функциональности движка для обновления текстур в видеопамяти данные сначала копируются из видеокадра в промежуточный массив, затем из массива помещаются в текстуру. При обновлении текстуры в видеопамяти сначала происходит выделение нового места под данные и только затем копирование данных из промежуточного массива в видеопамять. Все описанные действия выполняются центральным процессором, что значительно снижает производительность подсистемы визуализации. Например, при воспроизведении FullHD видео (1920 на 1080) время копирования данных из видеокадра в промежуточный массив составляет приблизительно 3-4 мс, а время обновления текстуры из промежуточного массива в видеопамяти составляет от 5 до 8 мс. Преимущество пиксельных буферов в том, что затраты процессорного времени необходимы только на помещение информации в буфер, а обновление текстуры из буфера происходит практически мгновенно (около 0,1 мс) за счет того, что обработка перемещения данных из пиксельного буфера в текстуру возлагается на видеокарту.
Проверка необходимости обновления видеотекстуры в подсистеме визуализации осуществляется поэтапно (рис. 2). Сначала определяется состояние видео: проигрывается, приостановлено, остановлено. Если видео остановлено или приостановлено, дальнейшие проверки не выполняются. Приостановленное видео отличается от останов-
Рис. 2. Алгоритм обновления видеотекстуры в подсистеме визуализации
ленного тем, что все потоки декодирования созданы, но остановлены, а очереди пакетов и декодированных кадров заполнены; если видео остановлено, то оно загружено (декодер инициализирован, информация о видеофайле получена), но его потоки декодирования не созданы и очереди пакетов пусты.
Составной частью первой проверки является проверка на кэширование (выполняется или нет). В начале воспроизведения видео запускается процесс кэширования, который заполняет очереди пакетов декодера, декодированных звуковых данных
и декодированных кадров. Кэширование пакетов и управление этим процессом происходят в потоке декодера, чтобы избежать проблем с производительностью (падением количества отображаемых подсистемой визуализации кадров в секунду), а декодирование аудио- и видеопакетов происходит в соответствующих потоках декодера. Во время кэширования данных основной поток приложения раз в итерацию цикла генерации кадров (далее ИЦ) подсистемы визуализации проверяет состояние кэшируемого видео. Если хотя бы один видеокадр уже был декодирован, то он помещается в пиксельный буфер, а затем удаляется из очереди декодированных кадров. После заполнения всех пиксельных буферов данного видео основной поток продолжает раз в кадр проверять состояние видео, пока процесс кэширования не будет завершен. После завершения этого процесса происходит запуск аудиопотока и состояние видео меняется на «проигрывается». Так же запускается таймер, по которому отсчитывается время для проигрываемого видео.
После первой проверки выполняется вторая -на необходимость обновления видеотекстуры в подсистеме визуализации. В ходе данной проверки время, прошедшее с начала воспроизведения видео, сравнивается со временем, когда необходимо отобразить следующую видеотекстуру. Для правильного отображения видеотекстур в подсистеме визуализации был разработан следующий алгоритм:
ЕСЛИ: |Т1-Т4|<|Т2-Т4|
ТО: {необходимо обновить видеотекстуру в подсистеме визуализации;
Т4=Т4+Т5}
ИНАЧЕ: обновление видеотекстуры в подсистеме визуализации не требуется, где Т1 - время с начала воспроизведения видео (мс); Т2 - предполагаемое время генерации следующего кадра подсистемы визуализации (с начала воспроизведения видео) (мс); Т3 - время генерации текущего кадра подсистемы визуализации (мс) (для первого кадра после начала воспроизведения видео предполагаемое время следующего кадра равно времени генерации текущего кадра (Т3); для расчета последующих значений применяются значения Т3, которые сохраняются в массиве из 10 элементов; для расчета Т2 применяется среднее арифметическое значений из массива; при заполнении массива, хранящего значения Т3, первое значение удаляется); Т4 - время отображения следующей видеотекстуры (для первой отображаемой видеотекстуры оно равно Т5 (мс)); Т5 -1/частоту кадров воспроизводимого видео (мс).
Независимо от результата описанной выше проверки после нее выполняется проверка на наполненность пиксельных буферов. Если хотя бы один пиксельный буфер не заполнен, в него добавляется новый видеокадр.
Если после второй проверки необходимо обновить видеотекстуру в подсистеме визуализации, это обновление происходит из соответствующего пиксельного буфера. Индекс используемого буфера определяется каждый раз при необходимости обновления текстуры. Так как для каждого видео предусмотрено 2 пиксельных буфера, то индекс следующего используемого буфера определяется по формуле: индекс следующего буфера = остаток от деления по модулю 2 суммы индекса предыдущего буфера и единицы.
При внедрении функциональности воспроизведения видео в подсистему визуализации возникли некоторые проблемы, основные из которых -рассинхронизация звука и видео во время воспроизведения и значительное снижение производительности при воспроизведении видео высокой четкости.
Алгоритм воспроизведения видео и синхронизации видео и звука в приложениях-медиаплеерах зачастую проще разработанного алгоритма, так как в этих приложениях фактор производительности менее значим. Наиболее часто применяемым методом синхронизации является синхронизация видео по звуку, то есть скорость воспроизведения звука считается постоянной величиной (определяется на основании указанной в видеофайле информации о частоте дискретизации и количестве каналов), а время отображения видеокадра рассчитывается на основании времени, записанного в пакетах, и времени, прошедшего с начала воспроизведения звука.
В разработанном алгоритме скорость воспроизведения звука считается величиной постоянной, а время вывода видеотекстуры на экран рассчитывается с учетом производительности (кадров в секунду) подсистемы визуализации. Для корректной синхронизации видео и звука необходимо, чтобы их воспроизведение началось одновременно. Для обеспечения синхронизации видео и звука после кэширования и запуска аудиопотока вводится задержка исполнения потока декодера (для преодоления задержки генерации звуковых буферов звуковой картой, которая составляет примерно 100250 мс). После указанной задержки запускается процесс воспроизведения видео.
Еще одной серьезной проблемой при воспроизведении видео в подсистеме визуализации стало снижение производительности при воспроизведении видео разрешением 1280 на 720 и более. Причина снижения производительности - время загрузки одной видеотекстуры в память видеокарты, которое составляло от 15 до 20 мс.
Первоначально для загрузки видеотекстуры в подсистему визуализации применялась базовая функциональность обновления текстур. Она включает в себя получение указателя на содержимое существующей текстуры, копирование данных нового видеокадра в текстуру и помещение в
видеопамять. Одним из предположений о причинах длительной загрузки текстуры являлось то, что видеокарте не хватает времени на обработку обновляемой в видеопамяти видеотекстуры, которая будет использована на следующем кадре подсистемы визуализации. С учетом указанного предположения был создан механизм заменяемых текстур.
Принцип данного механизма в том, что при запуске видео создавались две пустые текстуры, которые обновлялись бы заранее (за кадр или несколько кадров подсистемы визуализации до отображения), а при необходимости обновления видеотекстуры в подсистеме визуализации используемая текстура заменялась бы в материале трехмерного объекта. Замена используемой текстуры в материале занимает доли миллисекунды, однако применение данной системы не решило проблему, так как скорость обновления текстур продолжала составлять от 15 до 20 мс.
Следующим вариантом решения проблемы производительности могло стать обновление текстуры в другом потоке. Но использование дополнительного потока могло создать проблему, присущую многопоточности, - синхронизацию потоков. Так, в одном варианте реализации при обновлении текстуры основной поток рендеринга ожидал бы окончания операции обновления, что сводило бы на нет эффективность данной системы. Поэтому механизм применения дополнительного потока был объединен с механизмом заменяемых текстур, когда одна текстура всегда содержит видеокадр, а вторая обновляется в дополнительном потоке. Однако и данный подход себя не оправдал, так как при использовании дополнительного потока текстура просто не отображалась в подсистеме визуализации, несмотря на то, что весь код ее обновления выполнялся правильно и ошибок не выдавал. Дело в том, что графический интерфейс OpenGL, на котором основан компонент подсистемы визуализации Horde3D, как и графический интерфейс DirectX, по своей специфике являются однопоточными, а потому команды, полученные из других потоков, игнорируются. При создании окна, в котором будет генерироваться изображение, создается так называемый контекст, который обеспечивает связь между созданным окном и графическим интерфейсом (DirectX, OpenGL). Контекст привязан к тому потоку, в котором создан, поэтому все команды графического интерфейса выполняются только в этом потоке. Соответственно, все команды подсистемы визуализации, связанные с обновлением или заменой данных в памяти видеокарты, могут выполняться только в том потоке, в котором создан контекст. Зачастую это основной поток программы, или так называемый поток рендеринга.
Существует возможность передачи управления контекстом другому потоку. Благодаря этому
можно сделать этот поток способным управлять ресурсами видеокарты, однако все команды из основного потока будут игнорироваться. Теоретически есть возможность быстро переключить контекст между потоками для обновления текстуры в видеопамяти в дополнительном потоке, однако на практике операция по изменению родительского потока контекста довольно ресурсоемка. В результате проблема повышения производительности с помощью данного метода так и не решена.
Еще одним вариантом применения потоков и контекстов было создание второго контекста для дополнительного потока. В этом случае можно объединить ресурсы для двух контекстов, что позволит управлять ресурсами подсистемы визуализации из двух независимых потоков. Однако в большинстве случаев для использования второго контекста необходимо создание второго окна. Так как оконная подсистема GLFW не позволяет создавать более одного окна, а внедрение данной функциональности сложно и нет возможности проверить эффективность методики до ее внедрения, принято решение не использовать данную функциональность.
После попыток применения дополнительных потоков для обновления текстуры в подсистеме визуализации было решено вернуться к однопо-точному обновлению текстур, но с использованием пиксельных буферов. Пиксельные буферы позволяют сократить время обновления текстур в видеопамяти за счет того, что центральный процессор необходим только для обновления информации в самом пиксельном буфере, а передача информации из пиксельного буфера в текстуру происходит с помощью видеокарты без участия центрального процессора. Однако даже с использованием пиксельных буферов скорость обновления текстур в видеопамяти продолжала колебаться в интервале от 10 до 20 мс.
Во время использования пиксельных буферов сделано одно важное наблюдение, которое впоследствии и позволило решить проблему производительности. Рассмотрим стандартный цикл работы графического приложения (рис. 3).
В большинстве случаев обработка и преобразование трехмерной сцены происходят до генерации кадра для того, чтобы в нем отображались последние состояния всех визуализируемых систем. Только графический интерфейс пользователя обрабатывается и генерируется после создания кадра, так как интерфейс должен накладываться уже на готовый кадр, иначе он будет затерт.
Во всех рассмотренных способах обновления видеотекстур в подсистеме визуализации обновление видео происходило до рендеринга сцены.
Обновление видео после рендеринга кадра позволило снизить время обновления текстуры в видеопамяти с 10-20 мс до 0,1-0,2 мс. Это дало возможность достичь стабильных 60 кадров в се-
кунду, генерируемых подсистемой визуализации, даже при воспроизведении видео с разрешением 1920 на 1080 ^иИНБ).
Причин значительного снижения производительности может быть несколько. Первая: видеокарта не успевает обрабатывать поступающие команды. По сути процесс рендеринга изображения является конвейером. Процессор асинхронно задает команды видеокарте, которая сохраняет команды в очередь и последовательно их выполняет. Существуют определенные команды, которые могут вызвать синхронизацию процессора и видеокарты, то есть создавать ситуацию, когда одно устройство будет ожидать другое. Основными командами, способными вызвать синхронизацию, являются команды получения данных из видеопамяти и загрузки новых данных в видеопамять. Поскольку для получения данных из видеопамяти или загрузки новых данных видеокарте необходимо выполнить все стоящие в очереди задачи, центральный процессор ожидает, пока они будут выполнены. Соответственно, данная задержка ведет к снижению производительности подсистемы визуализации. При обновлении видео конвейер видеокарты мог не успевать выполнять операцию по смене кадров. Так как данная операция является асинхронной, а обработка команд внешних устройств и трансформация сцены могут занимать незначительное время (около одной миллисекунды), перед загрузкой новых данных в видеопамять видеокарте приходилось выполнять операцию по смене кадра. Вместе с тем после рендеринга кадра видеокарта в большинстве случаев оказывается свободной до операции смены кадра.
Второй причиной может быть использование многопоточности - в одном процессе становится больше потоков одного приоритета, следовательно, время, через которое процессу рендеринга бу-
Рис. 3. Стандартный цикл работы графического приложения
дут отданы ресурсы процессора, может быть увеличено, а предоставляемое время, наоборот, уменьшено. Было замечено, что при отсутствии дополнительных потоков и использования стандартной функциональности обновления текстур подсистемы визуализации текстура размером 1920 на 1080 загружается в видеопамять за 5-8 мс, а также то, что задержка происходила не на этапе загрузки текстуры в видеопамять, а на этапе копирования нового видеокадра в пиксельный буфер -данный этап никак не связан с работой видеокарты и выполняется только центральным процессором. Это может означать то, что выполнение потока было приостановлено для выполнения других потоков с более высоким приоритетом. Данную проблему можно решить, если присвоить основному потоку программы (или потоку рендеринга, если поток рендеринга не является основным потоком программы), в котором происходит обновление пиксельных буферов, более высокий приоритет, чем у других потоков приложения.
В заключение можно сделать следующие выводы. Для воспроизведения видеоматериалов в подсистеме визуализации ТОС разработаны методы и алгоритмы воспроизведения видеоинформации в виртуальном трехмерном окружении; произведена оптимизация алгоритмов для достижения требуемого (не более 20 мс) времени генерации кадров в подсистеме визуализации при воспроизведении видеоинформации. Кроме того, разработана подсистема визуализации ТОС, внедрен программный модуль для декодирования видео, позволяющий обрабатывать видеофайлы на различных программно-аппаратных платформах.
Литература
1. Mamrosenko K.A. Training simulation systems for open distance learning // Proceedings Conference Open Distance Learning Towards Building Sustainable Global Learning Communities. Hanoi, Vietnam: The Gioi, 2010.
2. Гиацинтов А.М., Мамросенко К.А. Описание архитектуры подсистемы визуализации тренажерно-обучающих систем // Гагаринские чтения: тр. Междунар. молодеж. науч. конф. М.: ИЦ МАТИ, 2011. С. 85-87.
3. OpenGL 2.1 Reference Pages. URL: http://www.open-gl.org/sdk/docs/man/ (дата обращения: 18.05.2011).
4. Nicolas Schulz. Horde3D Documentation. URL: http://www.horde3d.org/docs/manual.html (дата обращения: 18.05.2011).
5. MPEG-2 video compression. URL: http://www.bbc.co.uk/ rd/pubs/papers/paper_14/paper_14.shtml (дата обращения: 18.05.2011).
6. YUV pixel formats. URL: http://www.fourcc.org/yuv.php (дата обращения: 18.05.2011).
7. NTUIT.ru: Курс: Common Intermediate ..: Лекция №11: Основы многозадачности. URL: http://www.intuit.ru/depart-ment/pl/cil/11/1.html (дата обращения: 18.05.2011).
References
1. Mamrosenko K.A., Conference Open Distance Learning Towards Building Sustainable Global Learning Communities, Hanoi, Vietnam, The Gioi, 2010.
2. Giatsintov A.M., Mamrosenko K.A., Gagarinskie chte-nija: trudy Mezhdunarodnoy molodezhnoy nauchnoy konferentsii (Readings from Gagarin: Proc. of International Yount Researchers Conference), Moscow, Informatsionniy centr MATI, 2011, pp. 85-87.
3. OpenGL 2.1 Reference Pages, available at: www.opengl. org/sdk/docs/man/ (accessed 18.05.2011).
4. Nicolas Schulz, Horde3D Documentation, available at: www.horde3d.org/docs/manual.html (accessed 18.05.2011).
5. MPEG-2 video compression, available at: www.bbc.co.uk/ rd/pubs/papers/paper_14/paper_14.shtml (accessed 18.05.2011).
6. YUV pixel formats, available at: www.fourcc.org/yuv.php (accessed 18.05.2011).
7. NTUIT.ru, Course, Common Intermediate, Lecture № 11, Multitasking Basis, available at: www.intuit.ru/department/pl/cil/ 11/1.html (accessed 18.05.2011).
УДК 519.68
СПОСОБЫ ПОВЫШЕНИЯ ЭФФЕКТИВНОСТИ ОТЛАДКИ И ТЕСТИРОВАНИЯ МНОГОПРОЦЕССОРНЫХ СИСТЕМ
Г.А. Лавринов
(НИИСИРАН, г. Москва, [email protected])
Важнейшей компонентой многопроцессорной вычислительной системы является коммуникационная сеть, или сеть обмена, с помощью которой процессоры соединяются друг с другом или с памятью. Наряду с шинами VME, PCI Express, HyperTransport и другими, для обеспечения межпроцессорного обмена бурно развивается интерфейс RapidlO. При разработке многопроцессорных систем на базе RapidIO отладка и первоначальное тестирование макетных и опытных образцов систем составляют серьезную самостоятельную проблему. Полноразмерное тестирование выполняется под операционными системами (в рассматриваемом случае - Linux и ОС РВ Багет 2.0 и 3.0), однако для успешного запуска операционных систем необходимо обеспечить достаточный уровень работоспособности и коммуникационной сети, и процессорных узлов. В распоряжении разработчика тестов есть только сама аппаратура и программа ПЗУ, автоматически получающая управление при включении питания и поступлении сигнала RESET. В данной статье предложены два способа тестирования и отладки многопроцессорных систем, реализуемых на базе интерфейса RapidIO, позволяющие обходиться минимумом дополнительной аппаратуры. А также приводятся сравнение этих способов с точки зрения эффективности применения и этапы построения тестирования на их основе. С помощью диаграмм последовательности UML представлены протокол для реализации встроенной RapidIO-консоли и протокол обмена данными с оконечными устройствами RapidIO для получения информации о результатах тести-
