Software Journal:
Theory and Applications

Подать статью

Вход Регистрация

Результаты для запроса: linux

  1. Технология разработки драйвера контроллера сопряжения с устройством отображения информации для системы Linux

    К.В. Пугин Центр визуализации и спутниковых информационных технологий НИИСИ РАН, Москва, Россия;
    К.А. Мамросенко Центр визуализации и спутниковых информационных технологий НИИСИ РАН, Москва, Россия, технических наук;
    В.Н. Решетников Центр визуализации и спутниковых информационных технологий НИИСИ РАН, Москва, Россия, физико-математических наук;

    Статья была опубликована в выпуске №4

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

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

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


  2. Анализ методов взаимодействия графической системы X Windows System с аппаратным обеспечением

    А.В. Родителев Центр визуализации и спутниковых информационных технологий НИИСИ РАН, Москва, Россия;
    К.А. Мамросенко Центр визуализации и спутниковых информационных технологий НИИСИ РАН, Москва, Россия, технических наук;
    А.М. Гиацинтов Центр визуализации и спутниковых информационных технологий ФНЦ НИИ, Москва, Россия, технических наук;
    В.Н. Решетников Центр визуализации и спутниковых информационных технологий НИИСИ РАН, Москва, Россия, физико-математических наук;

    Статья была опубликована в выпуске №3

    В статье описаны некоторые методы взаимодействия графической системы X Windows System с аппаратным обеспечением. На примере архитектуры EXA рассмотрены основные операции аппаратного 2D-ускорения.

    Для исследования производительности было проведено тестирование Xorg с помощью утилиты x11perf версии 1.5. Тестирование проводилось в 5 режимах с использованием аппаратного 2D-ускорения и без. На основании результатов тестирования можно сделать вывод, что использование аппаратного 2D-ускорения с EXA оправдано в случаях, когда планируется использование изображений с высоким разрешением или есть необходимость снизить загрузку центрального процессора.

    Тестирование производительности с отключенным взаимодействием с аппаратной частью (2D GPU + dummy EXA) показало, что использование EXA существенно влияет на скорость выполнения тестов, поскольку только на определенном наборе тестов драйвер 2D GPU + dummy EXA показывает лучший результат относительно драйвера modesetting.

    Следует отметить, что использование EXA c DRM-стеком требует дополнительного исследования, так как при использовании DRM-стека с опцией EXA_MIXED_PIXMAPS в большинстве случаев операции масштабирования, копирования pixmap, заливки сплошным цветом и т.д. осуществляются на CPU. В определенных ситуациях отсутствие этой опции может привести к ряду графических артефактов в виде неперерисовывающихся областей изображения при обновлении кадрового буфера.