По информации, полученной с Game Developers Conference, внутри компании AMD сейчас рассматривается вопрос о кардинальных изменениях в модели выпуска драйверов для Linux.
Вкратце, AMD планирует кардинально переработать структуру драйвера Catalyst таким образом, чтобы тот больше не требовал установки проприетарного модуля ядра. Эта работа будет возложена на открытый DRM-драйвера (Direct Rendering Manager) Radeon, а остатки проприетарного кода станут выполняться в пространстве пользователя.
Текущая ситуация с установкой проприетарных драйверов (как AMD, так и Nvidia) чересчур сложна. В системе должен быть установлен полный набор компиляторов, чтобы при установке драйвера собрать проприетарный модуль ядра. Компиляция «на местах» необходима в силу наличия разнообразных версий ядра Linux, которое не имеет стабильных API/ABI. Наличествуют и правовые ограничения, запрещающие свободно распространять закрытые модули, слинкованные с ядром. Перемещение проприетарных компонентов из пространства ядра в пространство пользователя позволяет элегантно решить проблему фрагментации платформы Linux, избавляя от необходимости таскать с собой набор компиляторов. Заодно, решается и проблема несовместимости прежних версий драйвера с новыми выпусками ядра.
Наличие единого свободного драйвера для Mesa/Gallium3D и Catalyst привело бы к более эффективному сотрудничеству и меньшему распылению сил на поддержку дублирующегося кода. Вдобавок, открытый драйвер станет быстрее получать новые возможности и оптимизации. Такой подход привел бы даже к поддержке Wayland / Mir драйвером Catalyst (через Radeon KMS), при условии, что инженеры AMD добавили бы поддержку необходимых расширений EGL в ту часть драйвера, которую планируют вынести в пространство пользователя.
Основные проблемы, вставшие перед разработчиками:
- Необходимость существенной переработки компонентов Catalyst OpenGL и Catalyst DDX для работы с драйвером Radeon DRM. В настоящий момент, Catalyst использует совершенно иную модели драйвера, по сравнению с открытым драйвером. Обнадеживает тот факт, что AMD уже смогла наладить взаимодействие проприетарного драйвера с открытым драйвером, без внесения изменений в ядро, хотя данный прототип драйвера пока еще далек от полноценного;
- Линус Торвальдс крайне негативно относится к изменениям, ломающим обратную совместимость. Таким образом, если адаптация Radeon DRM (для работы с Catalyst) cломает уже существующей в ядре драйверы R300/R600/RadeonSI, то такой код просто не будет принят в ядро. Отсюда следует, что все изменения должны быть максимально сосредоточены на стороне проприетарного драйвера, а изменения в открытой части должны быть минимальными и хорошо документированными;
- Пока не ясно, годится ли вообще для задуманного драйвер ядра Radeon DRM в своём нынешнем состоянии. Код управления памятью Radeon DRM менее оптимизирован по сравнению с Catalyst, что влечет необходимость его оптимизации, иначе пользователи ощутят снижение производительности;
- Кроме проблем с производительностью, в открытом драйвере полностью отсутствуют некоторые важные возможности. На ум сразу же приходят CrossFire / Dual Graphics , поддержка стереорежима, дополнительные режимы сглаживания AA / AF , OverDrive / разгон, и многие другие, которые сейчас доступны лишь через Catalyst Control Center. Открытый драйвер не полностью поддерживает OpenCL, и лишь OpenGL 3.3, в то время, как проприетарный Catalyst уже умеет OpenGL 4.4. С другой стороны, закрытый драйвер не обладает, например, поддержкой доступа к интерфейсу VCE (Video Coding Engine), так что более плотное взаимодействие разработчиков позволит объединить «под одной крышей» плюсы открытой и проприетарной части;
- Пока не ясно, как AMD будет решать проблемы с запатентованным кодом или кодом, подверженным юридическим ограничениям. Остается спорным вопрос о способе реализации DRM (средства защиты авторских прав) в открытом драйвере. Очевидное решение - использовать отдельный проприетарный модуль ядра, контролирующий контент, воспроизводимый пользователем (например, для защиты от перехвата видеопотока, поступающего от видеокарты на монитор), но этот подход ставит под сомнение весь проект - в самом деле, какой смысл стараться уйти от закрытого модуля ядра, чтобы в итоге придти к другому закрытому модулю ровно с теми же недостатками? Размещение же средств защиты авторских прав в открытом драйвере затруднительно, поскольку облегчает их реверс-инжиниринг и создание инструментов для нарушения авторских прав.
- Новые интерфейсы открытого ядерного драйвера, предназначенные лишь для взаимодействия с закрытыми компонентами пользовательского режима, могут быть отвергнуты Линусом Торвальдсом и не включены в ядро. Так, к примеру, он отказал компании VIA, которая хотела видеть в ядре драйвер Chrome 9 DRM, предназначенный для воспроизведения трёхмерного видео, но лишь через проприетарный бинарный компонент, работающий в пространстве пользователя. Свободный код, которым могут пользоваться лишь проприетарные компоненты пространства пользователя, в ядро не допускается.
- Идея вынести часть кода из ядра уже обсуждалась в 2007 году, и была отвергнута из-за крайне затруднительной реализации. Однако, по словам инженеров AMD, с тех пор драйвер Catalyst существенно изменился;
- Для AMD весьма важен корпоративный рынок. Сейчас драйвер Catalyst может быть легко установлен на старых ядрах Enterprise Linux, которые имеют долгосрочную поддержку. Придется портировать много кода в старые ядра, а корпоративным пользователям обновлять ядро, вместо того, чтобы просто скомпилировать новый модуль fglrx для обновления, как сейчас;
- Опасения вызывает и тот факт, что при существенном дополнении функциональности драйвера пользователям придется обновлять ядро (в котором находится открытая часть драйвера). Но не многие из основных дистрибутивов могут позволить себе легко и просто сменить мажорную версию ядра. Сейчас же, пользователь легко может пойти и скачать с amd.com драйвер под необходимую версию ядра;
- AMD придется сделать так, чтобы «код» обгонял «железо». Это необходимо, чтобы поддержка нового оборудования успела попасть в стабильную версию ядра. До сих пор, поддержка оборудования в драйверах появлялась уже после выхода этого самого оборудования на рынок. Но у ядра Linux свой цикл разработки, новый код с крупными изменениями принимается только в течение определенного периода времени, после которого кодовая база «замораживается» и начинается выпуск релиз-кандидатов. К тому же, существенную часть времени в подготовке драйверов занимает не труд программистов, а различные юридические согласования
>>> Подробности
