Компания AMD рассматривает возможность более открытой разработки видеодрайвера Catalyst
По информации, полученной на проходившей недавно конференции Game Developer’s Conference, компания AMD рассматривает достаточно интересную стратегию развития драйвера Catalyst. Общая идея состоит в том чтобы избавиться от собственного модуля для ядра, использовав вместо него DRM-инфраструктуру (Direct Rendering Manager) ядра Linux и модуль открытого драйвера Radeon. При этом функциональность специфичная для проприетарного драйвера останется только в компонентах, выполняемых в пространстве пользователя, так что для драйвера не будет требоваться проприетарный модуль ядра. Ожидается, что подобный подход может устранить множество проблем с поддержкой различных дистрибутивов Linux и разных версий ядер. В том числе реализация драйвера Catalyst целиком в пространстве пользователя снимет ограничения на использование интерфейсов ядра Linux, доступных только для модулей под лицензиями, совместимыми с GPL (группа EXPORT_SYMBOL_GPL), так как они не распространяются на user-mode компоненты, работающие через свободный модуль ядра. Кроме этого, для установки драйвера не будет требоваться работоспособный компилятор, способный собрать модуль ядра.
Тем не менее, отмечается, что данные планы весьма предварительны, так как на пути к реализации данной идеи могут возникнуть многочисленные трудности:
Компоненты Catalyst (реализация OpenGL и DDX драйвер) нуждаются в существенном рефакторинге для того чтобы использовать открытый модуль ядра вместо проприетарного. Линус Торвальдс отрицательно относится к изменениям, которые ломают совместимость интерфейсов с существующим кодом. Поэтому маловеероятно, что в ядро будут приняты изменения, которые нарушают работу драйверов R300/R600/RadeonSI. Это означает, что большинство изменений должно делаться на стороне драйвера Catalyst. В данный момент управление памятью в открытом драйвере работает медленнее, чем хотелось бы, поэтому чтобы избежать потерь производительности при переходе на новую архитектуру придется существенно переработать код управления памятью в ядерных модулях открытого драйвера. В открытом модуле пока не реализованы некоторые возможности, которые нужны Catalyst. Наиболее проблемными считаются CrossFire / Dual Graphics, поддержка OpenGL stereo, реализация улучшенных режимов AA/AF, OverDrive / overclocking и прочие возможности, которые предоставляет Catalyst Control Center. Кроме того, поддержка OpenCL также в данный момент не полная. С другой стороны, Catalyst например не умеет предоставлять интерфейс к блоку аппаратного кодирования видео в новых GPU (VCE — Video Coding Engine). Это является результатом того, что 2 команды работают достаточно независимо и поэтому принимали разные решения о том, какие интерфейсы они предоставляют. Возможны юридические проблемы с некоторым кодом. Например, ставится под вопрос возможность реализации DRM (средства защиты авторских прав) в виде открытого кода. DRM можно реализовать через дополнительный проприетарный модуль ядра, выполняющий дополнительные функции и не являющийся обязательным, однако это все-равно аннулирует ранее упомянутые плюсы, проявляющиеся при избавлении от проприетарного модуля. Если некоторые интерфейсы/ioctl используются только закрытым драйвером, апстрим может отвергнуть такие патчи. Ранее в ядре Linux уже применялась практика при которой патчи в ядро отвергались в случае когда данным кодом пользовались только проприетарные компоненты в пространстве пользователя (наиболее ярким примером является VIA Chrome 9 DRM). Для драйвера Catalyst достаточно приоритетен корпоративный рынок. Это означает, что довольно много изменений придется портировать в старые ядра. Опасения вызывает необходимость требовать обновления ядер при существенном дополнении функциональности драйвера, когда старый открытый модуль не будет предоставлять всех нужных функций. Исторически, открытые драйверы появлялись только после появления оборудования на рынке, что приводило к некоторой задержке в появлении поддержки новых моделей GPU в открытых драйверах, особенно при существенном изменении архитектуры. Упомянутый подход потребует заметно пересмотреть подобную практику, перейдя к добавлению поддержки в открытый модуль до выпуска новых моделей видеокарт на рынок. Дело усложняется тем, что новый код в ядро Linux принимают только во время окна приема изменений. Это означает необходимость учитывать даты, связанные с разработкой ядра Linux, и синхронизировать свои рабочие процессы с этими датами. Ситуация усугубляется еще и тем, что юридический отдел достаточно долго рассматривает выпуск исходных текстов. Также отмечается, что многие пользователи интересуются почему AMD не открывает драйвер целиком. Наиболее вероятной версией называлась собственность третьих фирм. Однако, утверждается, что это не самая значительная проблема. Более того, драйвер был лицензирован неназванным третьим сторонам. Из наиболее проблемных моментов выделяются опасения что конкуренты смогут использовать трюки и оптимизации в реализации OpenGL.
© OpenNet
