Положение дел в мире графики для Линукса

>Шит. "19. Эффективность кооперации." -- я помню русское такое слово "кооператив". Но "Эффективность взаимодействия" куда как более понятна и по-русски.

а может вообще лучше "эфективность сотрудничества"?

DRI и OpenGL

DRI, (Инфраструктура Прямого Рендеринга [знаю, что криво ;)] ) Direct Rendering Infrastructure, реализует OpenGL и взаимодействие с X сервером. DRI включает четыре основных компонента: Во-первых - libGl, предоставляющую OpenGL API и действующую как переключатель между драйверами. Во-вторых, аппаратно-зависимая библиотека DRI для взаимодействия с графическим процессором. Для возможностей OpenGL, не реализованных драйвером DRI требуется программная реализация - для этого используется Mesa. Замечу, что Mesa - это полная программная реализация OpenGL. Видеокарты, не поддерживающие ускорение могут реализовывать OpenGL с помощью Mesa. И, наконец, DRM - менеджер рендеринга. DRM драйвера выполняются в контексте ядра, управляют видеоподсистемой компьютера и обеспечивают необходимую защиту от несанкционированного доступа '''FIXME'''.

Каждое приложение, используя DRI напрямую управляет видеоподситемой. В этом отличие от X, где вы посылаете команды отрисовки серверу и уже сервер обращается к железу. Драйвера DRM обрабатывают множественные запросы для исключения интерференции. Преимущества такой модели в том, что OpenGL может отрисовыватся без накладных расходов на обмен и передачу данных серверу. Недостатки - во множественных переключениях контекста видеокарты. Некоторые видеокарты умеют быстро переключать графический контекст, но некоторые - нет. Microsoft уже столкнулась с этой проблемой, и поддержка аппаратного переключения контекста - одно из требований для получения лейбла "DirectX 10-совместимое железо"

DRM также реализует концепцию "ведущего пользователя", обладающего большими правами, чем обычные. Эти дополнительные права позволяют инициализировать видеокарту и управлять предоставлением ресурсов графического процессора. Текущая реализация X сервера, запускаемого от суперпользователя, функционирует как "ведущий пользователь". Это не значит, что ведущий пользователь DRM обязательно должен иметь права суперпользователя системы, и существует патч, удаляющий это требование.

Когда видеокарта не поддерживает какую-либо операцию - Mesa реализует её программно. Это называется "возврат ошибочного вызова". Некоторых такое название смущает. Они говорят, что OpenGL не полностью поддерживается X сервером. Подумайте об этом. Аппаратный OpenGL поддерживается не полностью из-за большого количества возможностей функций, в то время как X поддерживает только несколько. Если
вы нашли функцию, присутствующую в обоих драйверах - то она будет обработана аппаратно. Если нет - доработайте соответствующий драйвер

OpenGL|ES

Группа Khronos (далее - Хронос) - это стандартизирующая организация, объединяющая свыше сотни участников. Самый удачный стандарт Хроноса - OpenGL ES. OpenGL ES - достаточно удобное подмножество OpenGL, предназначенное для систем с небольшим объемом памяти. Ещё одно определение EGL - платформо-независимый эквивалент программных интерфейсов OpenGL GLX/agl/wgl. "EGL предоставляет механизмы для создания областей рендеринга (surfaces), которые могут использоваться из приложений OpenGL ES и OpenVG. Отрисовка, создание графического контекста для клиентских API и синхронизация отрисовки клиентскими API практически неотличима от родного API рендеринга платформы. Это позволяет безболезненно использовать OpenGL ES и OpenVG для высокопроизводительного, акселерированного, смешанного 2D и 3D - рендеринга.

EGL использует функциональность подситемы управления окнами, предоставляемую другими частями операционной системы. Тем не менее, EGL является платформонезависимой и ничто в EGL API не привязано к системе управления окнами в отличие от GLX/agl/wgl. Все ссылки к локальной системе управления окнами обрабатываются с помощью прозрачных указателей.

Разработчики Mesa предложили расширение для EGL, позволяюещее реализовать подсистему управления окнами поверх EGL. Ядро этого расширения предоставляет API для перечисления доступных экранов, установки режимов и настройки фреймбуффера экрана, pan the screen [не понял] и запроса аттрибутов. Две области всё ещё требующие адресации в EGL-расширении - это аппаратный курсор и отображение цветов [наверное, имеется ввиду работа с палитрами]. Добавление этой функциональности в EGL предоставляет достаточный контроль над аппартной частью для реализации сервера оконной системы аналогичного Xegl. OpenGL плюс EGL и расширения Mesa предоставляют действительно переносимый API для доступа к графическим подсистемам любого класса - от мобильных телефонов до Playstation 3, персональных компьютеров и графических суперкомпьютеров.

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

АХТУНГ!!! НЕПЕРЕВЕДЁННЫЙ ХВОСТ:

I believe that Khronos Group represents a major untapped opportunity for the X.org and Linux graphics communities. Most of the the Khronos standards are lacking open source reference implementations, development system support, and conformance tests. Many of the Khronos Group backers sell production systems based on Linux. If X.org were to expand its charter, it could approach Khronos Group about being a neutral non-profit vehicle for building open source reference implementations and development systems based on Linux and the Khronos standards. The partnership would allow Khronos Group members to make charitable contributions to X.org similar to IBM and the Eclipse Foundation.

> "Permission is granted to freely translate and republish." ?

Не, небыло этого, у меня есть сохраненный вариант. Видно кто-то письмо уже написал автору.

Покорнейше прошу всех авторов разместить свои переводы также и на http://translation.wikicities.com/wiki/The_State_of_Linux_Graphics если не влом :-)

fixed

DRI и OpenGL

DRI, Direct Rendering Infrastructure, инфрастуктура прямого рендеринга, воплощает OpenGL во взаимодействии с X сервером. DRI содержит четыре основных компонента. Во-первых, это libGL которая обеспечивает API OpenGL и действует как переключатель между разными драйверами. Затем, это специфичная для данного оборудования библиотека DRI, которая программирует графический чип. Для тех возможностей OpenGL, которые не поддерживаются драйвером DRI требуется запасной вариант с софтовой реализацией. Этот запасной вариант обеспечивает Mesa. Заметьте, что Mesa --- это полноценная програмная реализация OpenGL. Карта, которая не поддерживает аппаратное ускорение, может поддерживать OpenGL откатываясь к Mesa для каждой функции. Ну и наконец, это DRM, менеджер прямого рендеринга (the direct rendering manager). Драйвера DRM работают в ядре, управляя железом и обеспечивая необходимую защиту.

Интересная сторона DRI --- слово direct (прямой) в названии. Любое приложение, использующее DRI напрямую программирует видеожелезо. Это отличается от X, где Вы посылаете команды рисования на сервер, а он программирует железо для Вас. Ядерный драйвер DRM координирует работу многих пользователей чтобы исключить взаимные помехи. Преимущество этой модели в том, что рисование OpenGL может происходить без дополнительных затрат на переключение процессов и передачу данных на контролирующий сервер. Но недостаток здесь в том, что графической карте может понадобиться иметь дело с частыми переключениями графического контекста. Карты в рабочих станциях обычно справляются с этим, а вот потребительские карты нет. Microsoft уже столкнулась с данной проблемой и требует поддержку продвинутого аппаратного переключения контекста для оборудования, совместимого с DirectX 10.

DRM также воплощает концепцию главного пользователя имеющего расширенные возможности по сравнению с обочными. Эти дополнительные возможности позволяют инициализировать графическое устройство и контролировать потребление ресурсов GPU. Текущий X-сервер, который запускается от root'а, функционирует как DRM-мастер. В действительности, насущной потребности в запуске DRM-мастера от root'а нет и уже есть предварительный патч, который убирает это требование.

Когда оборудование не поддерживает какую-либо возможность, Mesa воплощает эту возможность програмно. Это называется запасной програмный вариант. Людей вводит в замешательство данное обстоятельство. Они говорят, что их OpenGL ускорен не полностью, а X-сервер полностью. Подумайте об этом. Оба драйвера работают на одном и том же железе. OpenGL ускоряется не полностью поскольку он предлагает много вещей приспособленных к ускорению, в то время как X только несколько. Если Вы выберете возможности, присутствующие в API обоих драйверов, обе они скорее всего будут ускорены. Если нет --- флаг Вам в руки, начинайте писать исправление к текущему драйверу.

фиксил бы в вики уж. чё дублировать

Да пока я писал перевод ты сюда кинул свой.

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

>АХТУНГ!!! НЕПЕРЕВЕДЁННЫЙ ХВОСТ:

Вот перевод a la надмозг:

Я верю, что группа Хронос представляет основную неиспользованную возможность для сообществ X.org и других заинтересованных в графике под linux. Для большинства стандартов Хроноса отсутствуют базовое воплощение с открытыми исходниками, поддержка систем разработки и тесты на соответствие. Большинство поддерживающих данную группу продают промышленные системы, основанные на linux. Если X.org соберется расширить состав участников, это может приблизить группу Хронос к тому, чтобы быть независимым некоммерческим средством создания базовых воплощений с открытыми исходниками и систем разработки, основанных на linux и стандартах Хронос. Это партнерство позволит участникам группы Хронос внести солидный вклад в X.org подобно IBM и сообществу Eclipse.

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

С добрым утром. Или у кого там что :).

http://translation.wikicities.com/wiki/The_State_of_Linux_Graphics

уже точно здесь основная ветка, да ?

> http://translation.wikicities.com/wiki/The_State_of_Linux_Graphics

> уже точно здесь основная ветка, да ?

НЕТ :-) Просто я прошу всех кто работает над переводом в http://www.teleology.ru/1/fparticle.php?cat=7&sort=0&id=7 синхронизировать их и в это вики

:) Не знаю, не знаяю,... я основную ветку для себя не менял.

А так да, вот здесь сейчас дублируется всё, насколько я понимаю
http://translation.wikicities.com/wiki/The_State_of_Linux_Graphics

Дурное наследство VGA (VGA Legacy)

Оригинальный дизайн компьютеров IMB PC имел в некоторой степени ограниченный набор периферийных устройств, расположенных по фиксированным, хорошо известным адресам, например COM1 на 0x3F8. К сожалению, поддержка VGA на большинстве графических карт выполнена согласно этим традициям - с фиксированным адресом. До тех пор, пока вы имеет только одну видеокарту на вашей системе, VGA - не проблема. Подключите вторую карту и теперь вы будете иметь два устройства, пытающихся занять один адрес на шине.

Современный X-сервер включает в себя код для работы с многими VGA-адаптерами одновременно. Но этот код в X-сервере не "осознает" присутствия многих пользователей и может "наплевать" на них. Такое наплевательство на другие программы - плохая практика, таким образом, нам нужен способ для коррдинации многих пользователей VGA-устройства. В случае Линукс, лучшим решением является добавление в ядро механизмов арбитража VGA. BenH работал над одним из них, это обсуждалось на OLS.

--- немного начал, надеюсь сегодня закончить часть про "наследие вга"

>А так да, вот здесь сейчас дублируется всё, насколько я понимаю
http://translation.wikicities.com/wiki/The_State_of_Linux_Graphics

Что, кстати, очень ценно, так, как у нас всегда есть, по крайней мере, резервная копия. Спасибо Nelud/у.

Socrat ты случайно не двойную работу делаешь? Этот первый абзац я еще вчера добавил.

Уточняйте часть, что вы переводите.

Давай тогда уже всё на вики делать, а ты потом на свою страницу скопируешь результат.

Итак, осталось перевести:

14. частично и 22. частично.

Давайте поднажмём, так как у меня сегодня много другой работы.
Вобще, надо признать, что в сутки мы не уложились, но, в любом случае, результат почти :) есть.

Согласен. Разделяя консоль. Заголовок переводил в конце, уже утомленный нарзаном:)

Итак, кто добьет 3 поколения и несчастное многострадальное наследние ВГА?

Во перевёл обзац из three generations of windows:
В текущей версии Х сервера и многоих других оконных системах, окна рисуются на экран в выделенных участках использую малярный(?) алгоритм. Малярный алгоритм работает примерно как настоящий маляр ? каждый последующий слой наносится на предыдущий. Вы рисуете сначала фон и затем рисуете каждое окно в обратном порядке упорядоченно по Z координате(?). Если прозрачность не нужна и вы знаете где будут нарисованны все окна, то можно оптимизировать алгоритм (как это делает X сервер) с прямоугольниками отсечения таким образом что бы каждый пиксель наносился на экран только один раз. Производительность может быть улучшена путём отслеживания участков окон нуждающихся в перерисовке. То есть в перерисовке нуждаются только те окна которые получили дефекты отображения. Благодаря этому методу улучшается комфортность восприятия. Ещё одно улучшение это метод "сохранение фона"(save unders). Оконная система знает что такие объекты как "попап" меню перерисовывают изображение предварявшее при сворачивании. Метод "сохранение фона" сохраняет изображение под этими объектами и восстанавливает его при их сворачивании.

Вобще текст похоже слишком сложен для меня, вот например в следующем параграфе под composite что имеется в виду, разъём?

>Давай тогда уже всё на вики делать, а ты потом на свою страницу скопируешь результат.

Уже практически корректировка по структуре не требуется. Осталось несколько абзацев в двух частях.

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

Если за ближайшие пару часов никто не сделает 3 поколения - я возьмусь.

> А так да, вот здесь сейчас дублируется всё, насколько я понимаю

Честно говоря, меня ломает дублировать всё самому. Поэтому и прошу вас всех самим продублировать свою часть.

Я же займусь оформлением: ссылки поставлю где надо, картинки...

> Давай тогда уже всё на вики делать

Нет, я считаю надо и там и здесь делать одновременно

Серёж, обрати внимание, там первый абзац переведён.

закончил на вики про VGA Legacy

Напишите, кто что переводит из оставшихся частей.

Пока ждём перевод, можно продолжить качество улучшать.
Благодаря Casus/у, можно принять, что Предисловие, 1. История и 2. Производители графических микросхем. переведены уже вполне литературно.

Переходим к 3. Альтернативы рабочего стола.
Раз везде по тексту - рабочий стол, то и здесь пусть так будет.
Сейчас подкорректирую 3., так что после, предлагайте, что в 3. необходимо поменять.

> Раздваивая консоль

Разделение функций консоли

> два паттерна

в данном контексте "паттерна" --- "способа"

> два паттерна ее использования

два [основных] ее [пред]назначения

--

SVK

> Но по мере роста библиотек патентов

ИМХО, в данном случае будет точнее "патентных портфолио" :-)

Слово библиотека несет в себе оттенок публичной доступности, что в случае с патентами как раз не так.

--

SVK

takes advantage of performance enhancements in recent hardware. With composite, windows are drawn into off screen, non-visible video memory. The window manager then composites the windows together to form the visible screen. Compositing still uses the painter▓s algorithm, but since the window manager always has all of the window contents, it is possible to implement translucent windows. Translucency is created by blending the contents of the screen under the window with the previous window contents as it is copied to the scanout buffer. This is calledalpha blending. Most modern hardware supports it. Drawing flicker is also eliminated by double buffering. In this model everything is still 2D and has a simple Z order.

пЮЯЬХПЕМХЕ Composite ХЯОНКЭГСЕР МНБХМЙХ, ОНЪБХБЬХЕЯЪ Б ЯНБПЕЛЕММНЛ НАНПСДНБЮМХХ ДКЪ СКСВЬЕМХЪ ОПНХГБНДХРЕКЭМНЯРХ. оПХ ЩРНЛ НРПХЯНБЙЮ НЙНМ ДЕКЮЕРЯЪ БН БМЕЩЙПЮММСЧ, МЕБХДХЛСЧ НАКЮЯРЭ БХДЕНОЮЛЪРХ. гЮРЕЛ НЙНММШИ ЛЕМЕДФЕП ЯНЯРЮБКЪЕР ХГ ЩРХУ НЙНМ ХГНАПЮФЕМХЕ ДКЪ БХДХЛНИ ВЮЯРХ. Composite ОН-ОПЕФМЕЛС ХЯОНКЭГСЕР "ЮКЦНПХРЛ УСДНФМХЙЮ", МН, ОНЯЙНКЭЙС НЙНММШИ ЛЕМЕДФЕП ХЛЕЕР Б ЯБНЕЛ ПЮЯОНПЪФЕМХХ ЯНДЕПФХЛНЕ БЯЕУ НЙНМ, ЯРЮМНБХРЯЪ БНГЛНФМШЛ НПЦЮМХГНБЮРЭ ВЮЯРХВМСЧ ОПНГПЮВМНЯРЭ. нМЮ ЯНГДЮЕРЯЪ ЯЛЕЬЕМХЕЛ ЯНДЕПФХЛНЦН ВЮЯРХ ЩЙПЮМЮ ОНД НЙМНЛ Я ХГНАПЮФЕМХЕЛ Б БЕПУМЕЛ НЙМЕ, Б РНР ЛНЛЕМР, ЙНЦДЮ НМН ЙНОХПСЕРЯЪ Б АСТЕП. щРН МЮГШБЮЕРЯЪ ЮКЭТЮ-ЯЛЕЬЕМХЕЛ (alpha blending). аНКЭЬХМЯРБН ЯНБПЕЛЕММНЦН НАНСДНБЮМХЪ ОНДДЕПФХБЮЕР РЮЙНИ ЮКЦНПХРЛ. лХЦЮМХЕ (ДПНФЮМХЕ) ХГНАПЮФЕМХЪ МЕ ОПНХЯУНДХР ХГ-ГЮ ДБНИМНИ АСТЕПХГЮЖХХ (double buffering). б ЩРНЛ ЯКСВЮЕ БЯЕ ЕЫЕ ДЕКЮЕРЯЪ Б ДБСУ ХГЛЕПЕМХЪУ Х ХЛЕЕР НАШВМШИ (РПЮДХЖХНММШИ?) ОНПЪДНЙ ОН Z-НЯХ.

болтовня => разговоры.

В самой последней фразе: первое слово "описаны" заменить на "приведены", а то что-то у меня там все подряд описано :)

Осталась только часть от 22. Three Generations of Windows.
Если кто-то переводит - размещайте переведённые абзацы здесь сразу - мне будет удобнее добавлять - ссылки мешаются особенно, когда текста много.

По литературному переводу 3., есть пожелания?

Уточни в какой части.

Так в 3.

Добавлено.

>Так в 3.

Я неправильно выразился - в смысле не в части, а где конкретно в тексте? Не могу найти "болтовня" даже поиском :) .

Отбой. Нашлось.

Переходим к 5. X как операционная система.

После Х поставить запятую?

Последний крик души перед отъездом на работу:

есть ли кто-нибудь, кто может напомнить -- drawing the line значит подводить черту (итог) или у меня уже все перемешалось в голове? Если я все же прав, кто возьмется перевести заголовок, сохранив игру слов? :)

Не надо там запятой.

Мне кажется, перемешалось. Там просто про "проводя линию".

"рисуем линию" в смысле - берем карандаш (дисплей) и рисуем линию им (на нём). там про окончательную отрисовку примитивов на 2д дисплей

вчера внимательно прочитал на Xorg'овском мэйлинг листе переписку этого Джона Смирла (который свалил их Иксов + автора статьи) с друдими ведущими разработчиками. Выяснилось, что половина статья _ПОЛНАЯ_ лажа, т.к. смирл слабо себе представляет, что такое EXA и как оно работает. Вобщем чувак гонит волну и набивает цену своей бесполезной работе. Круто его Кейт Паккар на место поставил :)

--седайко стюмчик

Я пока вдумчиво статью не читал, но что просмотрел поверхностно выглядит довольно непротиворечиво.

>(который свалил их Иксов + автора статьи) с друдими ведущими разработчиками.

Можешь пояснить эту фразу?



И ещё, можешь привести несколько ссылок, где, на твой взгляд, Смирл некомпетентен?

не вступай в спор с провокатором.

Да я и не спорю :) . Надо же разобраться. Ошибочно отвергать альтернативные мнения не ознакомившись :) .

> Надо же разобраться. Ошибочно отвергать альтернативные мнения не ознакомившись :)

возникло у меня нехорошее ощущение когда я переводил фразу

"Некоторое соответствующее субсидирование должно должно пройти длинные пути для гарантии что правильные фичи имплементированы."

в разделе "Будущее направление" (кстати название лучше перевести как "Смотря вперёд" ?)

Очень похоже на политиканство, в основе которого лежит "денюжек давай, ХОЧУ ДЕНЮЖЕК!!!" :)

Кстати по-поводу исправлений, поправьте там плиз:

имплементация -> реализация

имплементировать -> реализовывать

дизайн -> проект

дизайнировать -> проектировать

фича -> свойство

горячая замена -> замена на лету (как тут перевели в других частях)

безрутовый -> некорневой

зачистка -> чистка

Учту. Пока по коррекции добрался до ПИР и ОткрытаяГБ.

туда же:

"Текущий X сервер известен тем что недостаточно безопасен для использования с важными документами" -> "для" надо заменить на "при"

"Если бы нужно была сделать основная работа по проектированию то это надо было бы сделать с нуля с безопасностью в уме." -> "Если бы нужно было сделать основную работу по проектированию, то делать это надо сверху донизу с учётом безопасности"