Как ранее сообщалось (https://www.opennet.ru/opennews/art.shtml?num=40696), на проходящей в городе Бордо (Bordeaux, Франция) конференции XDC компания AMD собиралась анонсировать новую стратегию разработки графический драйверов для Linux. Разработчики AMD сдержали (http://www.phoronix.com/scan.php?page=article&item=amd_borde...) свои обещания и представили (http://www.phoronix.com/scan.php?page=news_item&px=MTgwODA) наглядные слайды, описывающие их видение процесса, проблемы встреченные на этом пути и дальнейшие планы.
Основная идея изменений сводится к тому, что выполняемый на уровне ядра модуль и его "обвязка", касающаяся DRM и KMS, будет целиком базироваться на открытом коде. Разработчики называют такой подход "Base Graphics", а драйвер получил название "amdgpu". Эта часть будет основана на уже существующем коде Radeon. Тем не менее, это скорее всего коснется только новых GPU, предположительно начиная с серии Pirate Islands. Отмечается, что обкатка идей на уровне прототипа делается на уже существующих GPU семействах Sea Islands.
Важным изменением станет то, что теперь работающая на уровне ядра открытая часть драйвера станет разрабатываться параллельно с разработкой нового оборудования, с использованием инженерных прототипов и взаимодействием с командой разработчиков оборудования. В "классический" Catalyst поддержка новых GPU скорее всего добавляться не будет - вместо этого будет развиваться драйвер amdgpu, за основу которого будет взят Radeon.
Пользуясь случаем, дополнительно можно отметить планы реорганизации устройства драйвера, работающего на уровне ядра. Теперь вместо множественных ветвей кода (code paths), различных для разных чипов, деление на компоненты драйвера будет выполняться на основе версий IP-блоков (IP, Intellectual Property) оборудования (например, декодера UVD) и для каждой версии будет будет своя реализация работы с этим блоком. При взаимодействии с тем или иным чипом драйвер будет задействовать модули, соответствующие версиям блоков из которых состоит чип.По мнению сотрудников AMD можно выделить 3 варианта графического стека на основе этого подхода:
- Полностью открытый стек ("All Open"): открытый драйвер уровня ядра, библиотека drm и run-time KFD и HSA. С ними взаимодействуют компоненты MESA, DDX драйвер, различные state tracker Gallium-а и так далее, в основном отмечаются VA-API, VDPAU, clover OpenCL, OpenMAX и реализация OpenGL из MESA. В таком виде графический стек достаточно похож на уже существующие R600g/RadeonSI.
- "Non pro". Обычный графический стек для игровых десктопов и тому подобных применений. От предыдущего отличается в основном заменой реализации OpenGL и OpenCL проприетарными компонентами. Проприетарные компоненты взаимодействуют с упомянутой подсистемой "Base Graphics" аналогично открытым компонентам, используя те же интерфейсы. Ожидается, что никаких доработок открытой части графического стека не потребуется - компоненты должны работать поверх основных реализаций и не требовать для себя никаких изменений. DDX-драйвер открытый и является тем же драйвером, что и в варианте "All Open".
- "Pro". Нацелен на сегмент графических станций, использующих профессиональные адаптеры семейства FirePro. По устройству аналогичен предыдущему стеку, однако в открытых компонентах могут быть дополнения, специфичные для FirePro. Они будут с открытым исходным кодом, однако неизвестно насколько это получится интегрировать в mainline-версии компонентов (например, в mainline ядре Linux разработчики отрицательно относятся к коду который нужен только проприетарным компонентам в user space). В крайнем случае такие компоненты будут оформлены отдельными открытыми компонентами.
Сложности с которыми пришлось столкнуться разработчикам:
- Плохая/неполная/неточная документация по работе оборудования, форматам пакетов и прочего.
- Код Catalyst закрытый и открыт не будет.
- На данный момент юридический отдел проводит рецензирование открываемого кода и документации, что тормозит процесс разработки открытых компонентов. Теперь открытые компоненты будут разрабатываться параллельно с разработкой новых чипов. Ожидается, что это приведет к тому, что на момент выпуска чипа он уже будет поддерживаться открытым драйвером.
- Внутренние разработчики AMD не имеют опыта работы "на публику". Предполагается, что будет некий переходный период ("ramp up"), при котором внутренние сотрудники не будут напрямую работать с открытыми репозиториями, а разработчики открытых драйверов постепенно введут их в курс дела.
Почему не все компоненты открыты:
- Некоторым потребителям ряд возможностей нужны уже сегодня, из таких возможностей отмечается полная реализация OpenCL и OpenGL. Открывать эти реализации не планируется из-за опасений, что конкуренты могут использовать ряд трюков в своих продуктах. Тем не менее, отмечается, что в будущем планируется переносить фокус в сторону открытых компонентов.Текущее состояние дел:
- Прототип драйвера amdgpu уже существует и отлаживается на семействе Sea Islands. Более новые семейства GPU, в частности, Pirate Islands, скорее всего не будут добавляться в классический Catalyst и вместо этого для них будет выпущен драйвер amdgpu.
Разработчики отмечают заинтересованность в ответной реакции сообщества. Их интересуют пожелания к возможностям нового драйвера, мнения на чем сфокусироваться, участие в тестировании и в целом улучшение взаимодействия с другими открытыми проектами.URL: http://www.phoronix.com/scan.php?page=news_item&px=MTgwODA
Новость: https://www.opennet.ru/opennews/art.shtml?num=40798
>Разработчики AMD сдержали свои обещания и представили наглядные слайдыСлайды это круто! Вот что бы мы без слайдов делали? Слайды -- двигатель прогресса!
Вот только стрёмно они написали про "3 варианта". Думаю следует подождать комментарий от разработчиков текущего открытого драйвера.
> Слайды это круто! Вот что бы мы без слайдов делали? Слайды --
> двигатель прогресса!Это наглядная иллюстрация того как в дальнейшем это будет выглядеть с логической точки зрения.
> Вот только стрёмно они написали про "3 варианта". Думаю следует подождать комментарий
> от разработчиков текущего открытого драйвера.Имено они и презентовали все это. И именно эти перцы и будут играть теперь первую скрипку, обучая тех кто работал над линуксным каталистом открытым процессам. Поскольку без ядерного модуля далеко не уедешь, а то что за основу взято - программили именно они.
В целом же налицо тенденция: линух достаточно окреп чтобы сам задавать направление развития графики вокруг него. А всякие там проприетарщики, бсдшники и прочие - как видим попросту строятся под эти интерфейсы. Уже не рискуя даже пытаться что-то там вякать.
>Именно они и презентовали все это.Ну это уже лучше. Просто из текста новости этот момент не очевиден.
Впрочем, если они не лгут, то скоро уже не надо будет делать различие между разработчиками.
> Ну это уже лучше. Просто из текста новости этот момент не очевиден.Можно было сходить по ссылкам и посмотреть на слайды/фото с новости. Где АМДшный Alex Deucher (один из первых опенсорсных разработчиков принятых на работу в AMD, если не ошибаюсь) как раз презентует все это.
> Впрочем, если они не лгут, то скоро уже не надо будет делать
> различие между разработчиками.По ядерной части видимо так. Еще остается проприетарный OpenGL/OpenCL. Это конечно фи, но здорово лучше того что было. По крайней мере, AMD решили не ссaть против ветра и признать DRM+KMS и все что вокруг основным интерфейсом графики для линуха. Как это и задумано. Как ни крути, а это нормальная интеграция с майнлайном.
Майкрософты какие по счёту в твоей очереди, дорогая погрешность измерения?
> Майкрософты какие по счёту в твоей очереди, дорогая погрешность измерения?Хренадцатым. Я не пользуюсь виндами и мне совершенно все-равно что у них в болоте творится. Меня открытые системы интересуют.
AMD можно верить - с 2008 года радуют открытыми стандартами и спецификациями.
> Думаю следует подождать комментарий от разработчиков текущего открытого драйвера.Вообще-то это как раз один из них и рассказывал на XDC про новую стратегию.
> Тем не менее, это скорее всего коснется только новых GPU, предположительно начиная с серии Pirate Islands.Открытость открытостью, а маркетинг - превыше всего!
При чем тут маркетинг, они просто не хотят поддерживать старые видеокарты и добавлять лишний гемор с исправлением новых багов, которые в результате однеозначно появились бы.
> При чем тут маркетинг, они просто не хотят поддерживать старые видеокарты и
> добавлять лишний гемор с исправлением новых багов, которые в результате однеозначно
> появились бы.Называя вещи своими именами - весь catalyst заслуживает того чтобы его закoпaли, а раз пошла такая пьянка то и новый модуль логично сделать "по заявкам слушателей" и "как лучше", а не "как вышло по историческим причинам". И кстати R600g/RadeonSI никуда деваться не собираются, так что и поддержка старых GPU будет до тех пор пока оно кому-то надо.
во, наконец-то стратегия! а то всё шутеры, шутеры.
> во, наконец-то стратегия! а то всё шутеры, шутеры.А разве амд выпускали шутеры? :)
> Открывать эти реализации не планируется из-за опасений, что конкуренты могут использовать ряд трюков в своих продуктах.Деньги на реверс-инжиниринг у конкурентов точно не в избытке!
> ряд трюковПомойму самый обычный гуонно-код
> по-моему
да скоро вообще тесселяцию в мезе допилят и все "трюки" будут доступны открыто
Собственно да. Главное доделать чтоб было не хуже. А трюки можно и среверсинженирить.
Тоже резануло глаз. Может только если VIA или еще более экзотические видюхи что-то подчерпнут из "трюков".
Наконец-то нормальное название! А то 2014 год, а у меня в xorg.conf по-прежнему fglrx. Это название дискредитировало себя ещё в 00-е! Я понимаю что у AMD нашлись большие деньги на вылавливание багов из этого наследия ATi, поэтому fglrx больше не означает "глюкодром". А у NVIDIA тем временем нашлись большие деньги на "отвязывание" драйвера от иксов (для работы c CUDA и OpenCL), реализацию EGL и проталкивание патчей для гибридной графики в ядро (которыми Catalyst до сих пор не пользуется).Вообще радуют - повернулись к открытым стандартам лицом! Amdgpu вместо fglrx, закрыли разработку Stream в пользу OpenCL, и открыли спецификации на чипы. Если бы не AMD, то ATi могла бы даже отказаться от OpenGL в пользу Direct3D - вон как тормозит на старых чипах. Вместо этого реализовали 3.x и 4.x, и "починили" производительность.
> Наконец-то нормальное название! А то 2014 год, а у меня в xorg.confНа дворе 2014 год, а у тебя за каким-то лядом xorg.conf :). По логике вещей теперь он вообще станет архаикой - каталист будет заменять MESA и прочая в юзермоде, а модуль ядра, кусок drm-ной либы и прочее останутся те же что и были. И DDX.
> наследия ATi, поэтому fglrx больше не означает "глюкодром".Мне он не нравится, потому что глюкодром. Открытые драйвера лучше. И я там хотя-бы понимаю куда репортить баги и кого примерно пнуть, если какой-то shit все-таки случился.
> А у NVIDIA тем временем нашлись большие деньги на "отвязывание" драйвера от иксов
Да не надо там никаких огромных денег - там основной кус работающий с GPU вообще от системы не зависит, меняется только обвязка вокруг этого шмата кода. Если вы еще не поняли, всем дико западло с ноля писать драйвера целиком под каждую систему, вынос фич в либы не чужд даже проприерасам, ибо силы экономим. Так что все что этим будакам реально надо - немного пропатчить обвязку.
> (для работы c CUDA и OpenCL),
Это вообще к иксам никак не относится и иксы к этому - никаким боком. Не знаю как у невидии, но вообще OpenCL может работать и совсем без иксов. Иксы во всех этих схемах довольно побочный элемент, а отнюдь не центр вселенной.
> реализацию EGL и проталкивание патчей для
> гибридной графики в ядро (которыми Catalyst до сих пор не пользуется).У каталиста теперь будет круче. Пока нвидия пытается заставить свой проприетарный крап косить под нормальный DRM+KMS (а ей машут факами), AMD попросту переведет каталист на опенсорсный DRM+KMS выносок и пилить будет именно его. Такая вот разница в политике контор...
> этого реализовали 3.x и 4.x, и "починили" производительность.
Тут скорее всего надо сказать спасибо открытым разработчикам. Они из числа комьюнити кстати. Вот так вот люди из комьюнити и меняют мир. А вы говорите - корпорации, корпорации. Корпорации тоже из людей состоят. И у них есть имена.
Не соглашусь в двух вещах.1). Отвязывать драйвер от иксов это всё-таки дорого. Иначе Catalyst давно бы умел считать OpenCL с отключенными иксами. Можешь проверить сам, например на майнере лайткойнов cgminer 3.7.2. OpenCL не работает не только без иксов, но и даже с другого монитора/терминала: я как-то хотел 5870 поставить считать, а на интеграшке 3250 пользоваться десктопом, ничего не полуличлось.
2). Не будет "хода конём" с внезапным появлением KMS, DRI PRIME и DMA-BUF в Catalyst. Новый драйвер Amdgpu не будет поддерживать старые устройства, а все конфигурации PowerXPress - на них. Сомневаюсь что технология будет иметь продолжение с новыми видеочипами.
> 1). Отвязывать драйвер от иксов это всё-таки дорого.1) Как таковой драйвер не привязан к иксам или чему там еще. Есть некий набор core либ, работающих с GPU. А к винде, пингвину и прочему их адаптирует некая прослойка. Поменять эту прослойку так или иначе - не особая проблема. Если этим заниматься, а не выеживаться.
2) В линуксном графическом стеке иксы вообще нынче сильно сбоку. По задумке это как-то так: есть по сути отдельный DDX драйвер, сферический и в вакууме. Он интерфейсится к ядерным интерфейсам DRM+KMS и обвязке. Ядру и DRM+KMS вообще до лампочки, иксы будут этот интерфейс юзать или кто-то еще. Там есть MESA, OpenCL, есть какие-то потуги wine прикрутить к этому, вплоть до state tracker для DX :). Да и в иксах предпочли пойти по пути наименьшего сопротивления и тенденция такова что ускорение оформляется как 3D, выпихнутое через OpenGL. Это называется GLAMOR (см например http://www.phoronix.com/scan.php?page=news_item&px=MTgwOTg - там немного написано что за фигня).
> Иначе Catalyst давно бы умел считать OpenCL с отключенными иксами.
У каталиста вообще много странных дурных закидонов оставшихся с времен царя гороха по историческим причинам. Ну да, сделали его через ж..., и потому икалось. Вот нашли в себе силы переделать по человечески. Жаль что не полный опенсорс как у интеля, но на голову лучше того у...ща которое было.
> Можешь проверить сам, например на майнере лайткойнов cgminer 3.7.2.
Спасиб, я себе git-овый cgminer билданул и изучаю его глючность на MESA. Был удивлен, когда он в два счета врубился в "физической" консоли хотя я ему вообще ни разу не указывал где брать X сервер. Правда если sha256 он долбит как из пушки, то с scrypt пока все несколько хуже. Куча странностей и иногда потеря стабильности. И я не совсем врубился как правильно подбирать интенсивность vs глючность. Для биткоинов есть testnet, его можно поднять и на низкой сложности очень быстро убедиться что майнер долбит правильно. А для scrypt-based валют тестнет в природе не обнаружено. Сусанины в раздумьях: а как техническую валидацию майнера на предмет правильности счета проводить? :)
> OpenCL не работает не только без иксов, но и даже с другого монитора/терминала: я как-то хотел 5870
> поставить считать, а на интеграшке 3250 пользоваться десктопом, ничего не полуличлось.Там есть какие-то странности. У открытого стека тоже какие-то закидоны есть. Но я больше могу сказать про закидоны открытого стэка. Каталист мне неинтересен. Я ему желаю просто тихо умереть. Кстати не врут про то что открытый драйвер приближается к проприетари, на числодробильной задаче типа счета sha256 - на 5xxx в аккурат 80% номинала. А GCN и поболее, если потюнить.
> 2). Не будет "хода конём" с внезапным появлением KMS, DRI PRIME и DMA-BUF в Catalyst.
Новый драйвер будет изначально строиться поверх этих интерфейсов и адаптирован к ним.
> Новый драйвер Amdgpu не будет поддерживать старые устройства,
Ну да, увы. Но они уже неплохо поддерживаются R600g/RadeonSI, которые можно считать предшественниками amdgpu - вероятно, существенная часть кода оттуда и будет взята. И в открытом виде система с amdgpu будет довольно похожа на то что есть сейчас. Стимул развивать GL/OpenCL там только усилится, а ядерные подложки вроде уже неплохо работают. За глаза я считаю что рулить должен целиком открытый стек и видимо амдшные разработчики решили сварить маркетинговых лягушек на медленном огне: мол, если резко открыть все сорцы - это ой. А если постепенно пилить открытые реализации - это нормально, за...сь :). Хотя результат по идее одинаковый.
> а все конфигурации PowerXPress - на них. Сомневаюсь что технология будет
> иметь продолжение с новыми видеочипами.Честно говоря я даже не знаю что это за технология. Зато знаю что управление питанием DPM - то самое, реализующее гибкое прыгание по частотам которым так гордились в маркетинговых материалах AMDшники - такое же как в каталисте. Уже здесь и сейчас. В уже существующих дровах. Наверное там есть чего допиливать, но могучий R9 270 на холостом редиме - почти комнатной температуры. А если его нагрузить - это годная числодробилка :).
> Спасиб, я себе git-овый cgminer билданул и изучаю его глючность на MESA.Пардон, bfgminer. Он и в свежих версиях GPU умеет. И scrypt.
> OpenCLА я тут попробовал запустить Blender на radeonsi с мезой - теперь баги компилятора (LLVM бэкенда R600) ловлю, ибо оно крашится. Багов нашлось уже по ходу три - во-первых, StructurizeCFG иногда генерирует phinode'ы, ссылающиеся на себя в качестве одного из incoming value, а SIAnnotateControlFlow такое не может обработать, во-вторых StructurizeCFG иногда генерирует инструкции условного ветвления с условием, равным константе (O_O), и SIAnnotateControlFlow не может обработать и это, в-третьих есть ещё какие-то чудеса на примере со вложенными if()'ами в циклах...
Короче баг на баге, багом погоняет...
Ну вы нашли чем удивить - багами в шланге :). По идее это кстати шлангу в багтрекер, но у этих бакланов даже нет отдельного раздела под LLVM бэкэнд для радеонов. Вообще, достаточно сырая штука.Из очевидных грабель - все что активно работает с памятью имеет свойство валить GPU нахрен. Включая и майнер в режиме scrypt, достаточно поиграться с параметрами и оно запросто свалит GPU. Раньше по линии багов LLVM падали еще и игры на тяжелых настройках и даже браузер вываливался на тяжелых webgl демках (актуальнее для RadeonSI, у R600 по дефолту свой кодогенератор, хотя можно и LLVM, а у SI только LLVM и выбирать не приходится). В llvm 3.5 хотя-бы это починили. Но там еще чинить и чинить.
Так что да, пока:
> баг на баге, багом погоняет...
>PowerXPress
>>Честно говоря я даже не знаю что это за технология.Это то же самое что и Optimus от NVidia, но только для связок видеокарт Intel+AMD и AMD+AMD. И она поддерживается в Linux ничуть не лучше чем Optimus, а скорее даже хуже, т.к. для неё нет bumblebee.
> Это то же самое что и Optimus от NVidia, но только для
> связок видеокарт Intel+AMD и AMD+AMD. И она поддерживается в Linux ничуть
> не лучше чем Optimus, а скорее даже хуже, т.к. для неё нет bumblebee.С технической точки зрения это с точки зрения устройства пингвина как-то так: цепляем оба GPU через DRM/KMS, а потом по мере надобности у безглавого GPU таскаем буфер кадра через штуки типа DMA-BUF в сторону GPU с нормальным выводом. GPU ведь не так уж важно куда класть картинку.
Оно может быть еще не полностью в годном для юзерей виде, но сделано круто и достаточно generic. И постепенно начинает использоваться для того для чего и делалось. Включая подпертую DMA автоматом кантовку буфера кадра из GPU без собственного выдеовывода. Так что громкие маркетинговые названия постепенно становятся всего лишь стандартной системной фичой. И сабж всем этим по идее сможет нормально пользоваться, будучи разрабатываемым как часть линуха. Как раз AMDшникам будет не особая проблема свои GPU интерфейснуть к интелу, или наоборот.
Сам по себе DRM как таковой подразумевает что бывают "безмозглые" долбилки на экран (CRTC), по типу контроллеров дисплея в эмбедовке, "мозги" которым некуда рисовать, как в этих ваших ноутах, а также обычные нормальные GPU, где мозги и долбилка на экран вместе упакованы. И я как минимум недавно видел что в амдшный открытый драйвер упаковали какой-то фикс чтобы он вывешивал состояние GPU даже если с него питание снято. То-есть фичу по идее пилят. Насколько оно работает - хз, у меня нет ноутов с гибридной графикой. Я вообще не очень понимаю смысл в этих заморочках на ноутах. Как игровая машина ноуты все-равно гуано, а для десктопных эффектов хватит и интеграта.
Нормально она поддерживается! В открытом драйвере.У меня есть ноут Intel+Radeon. Говоришь xrandr --setprovideroffloadsink <ID> <ID> (ID берёшь из xrandr --listproviders), потом пускаешь приложение с переменной окружения DRI_PRIME=1, и оно запускается на дискретке.
«На дворе 2014 год, а у тебя за каким-то лядом xorg.conf :).»
расскажите нам, убогим, как µltiseat без оного завести?
> и проталкивание патчей для гибридной графики в ядроЧто? Не может быть такого
>> и проталкивание патчей для гибридной графики в ядро
> Что? Не может быть такогоВы с предыдущим комментатором живёте стереотипами. Один в 2006, и для него fglrx по-прежнему глюкодром. Другой в 2010-м, и для него под Linux всё ещё нет Optimus.
https://www.opennet.ru/opennews/art.shtml?num=33858
https://www.opennet.ru/opennews/art.shtml?num=34715
https://www.opennet.ru/opennews/art.shtml?num=34763
https://www.opennet.ru/opennews/art.shtml?num=35067
https://www.opennet.ru/opennews/art.shtml?num=35531
https://www.opennet.ru/opennews/art.shtml?num=36647
>Другой в 2010-м, и для него под Linux всё ещё нет Optimus.Вот только врать не надо, а. Я обладатель ноутбука с Optimus и его поддержка на сегодняшний день есть в полноценном виде только в bumblebee (да и то она не оптимальна по производительности и после выхода из ждущего режима иногда видеокарта NVidia самопроизвольно оказывается с включённым питанием).
>https://www.opennet.ru/opennews/art.shtml?num=35067
Это исправлено в последнем ядре Linux 3.17, так что ждём когда NVidia сделает официальную и главное полную поддержку Optimus.
Слайды - это хорошо. Перевод новости - перегружен лишним текстом.
> Слайды - это хорошо. Перевод новости - перегружен лишним текстом.Ну так в следующий раз пость новость сам, быстрее меня. И будет выглядеть так как тебе нравится. И мне заодно экономия сил.
Я так и не понял, этот новый amdgpu будет поддерживать мою карточку 7790 или нет?
Нет. Сказано же новые модели начиная с Pirate Islands.
Драйвера нужно предоставлять, а не стратегии
А мне наоборот всегда нравился подход "7 раз отмерь 1 раз отреж".
> отреж.Cut & paste fail, походу ;).
В будущем фокус возможно перенесут. Пошёл радоваться
Теперь можно смело закрывать поддержку всех видюх до ice чего-то там. Гениальный ход. С прогиба, Вася.
15 лет назад, я както пару раз купил карточки АМД радеон и после этого я понял, что nVidia наше всё. А АМД это отстой. Эти обещалки об улучшении драйверов уже 15 лет в новостях, а току ноль.
> 15 лет назад,За 15 лет многое может измениться.
> Эти обещалки об улучшении драйверов уже 15 лет в новостях, а току ноль.
Да я бы так не сказал. Как человек купивший свежую видяху от амд пару месяцев назад. Открытый драйвер на редкость приятно работает нынче. Ну правда самый свежак. Любители дебиан стэйбла дефолтный драйвер не оценят, разумеется.
У АМД с драйверами, как у Брагина с РеактОС.
> У АМД с драйверами, как у Брагина с РеактОС.В отличие от реактоси я их драйверами пользуюсь на практике. А нвидия с своими блобами может идти нафиг. Если б я хотел блобы - винда у меня уже была, добавки что-то не хочется.
И вообще, покупайте карты нвидии. Там при случае лишние мониторы отпилят, кулер бажным драйвером остановят, цифровых подписей навесят и чего там еще.А при каких либо проблемах будете писать в спортлото и слушать каркания павлина о том как у вас все должно быть замечательно. Если же "замечательно" вдруг почему-то не наступает - вся шайка-лейка певцов дифирамбов дружно прыскает в кусты. Ибо нормального багтрекера у них нет, живых разработчиков найти сложнее чем верблюда в антарктиде, etc.
Оно просто работает без каких либо проблем.
У АМД такого просто нет.
> Оно просто работает без каких либо проблем.Я и заметил. То три версии ядра к ряду драйвер не может модуль собрать, то мониторы лишние отпилят, то вон arisu рассказывал про непереключающуюся консоль.
> У АМД такого просто нет.
У амд есть достаточно приличный открытый драйвер. Он вообще в режиме плагнплея работает - без всяких правок xorg.conf'ов, ребутов и прочего кластерфака.
> Некоторым потребителям ряд возможностей нужен уже сегодня, из таких возможностей отмечается полная реализация OpenCL и OpenGL. Открывать эти реализации не планируется из-за опасений, что конкуренты могут использовать ряд трюков в своих продуктах.Чем же это хуже/лучше того, что предлагает NVIDIA в своих блобах? НИЧЕМ!
> Чем же это хуже/лучше того, что предлагает NVIDIA в своих блобах? НИЧЕМ!Это - да. Но ядерный выносок пилить теперь будет все АМД, которое пилило каталиста. И от этого выиграют в том числе и любители открытого стека.
>> Чем же это хуже/лучше того, что предлагает NVIDIA в своих блобах? НИЧЕМ!
> Это - да. Но ядерный выносок пилить теперь будет все АМД, которое
> пилило каталиста. И от этого выиграют в том числе и любители
> открытого стека.Но реализации OpenCL и OpenGL идут без исходников и там и тут.
> Но реализации OpenCL и OpenGL идут без исходников и там и тут.Да, и мне это не нравится. Разработчикам амд видимо, тоже. Подозреваю что они постепенно постараются перенести фокус на открытые компоненты а потом скажут - мол, а зачем нам мучаться с этим блобом, если открытый стек не хуже?! :)
>> Но реализации OpenCL и OpenGL идут без исходников и там и тут.
> Да, и мне это не нравится. Разработчикам амд видимо, тоже. Подозреваю что
> они постепенно постараются перенести фокус на открытые компоненты а потом скажут
> - мол, а зачем нам мучаться с этим блобом, если открытый стек не хуже?! :)А я сильно сомневаюсь в этом. Ведь основные конкурентные преимущества у них в этих точках. Такие вещи принято защищать всеми возможными способами, а не раздавать направо и налево. Тренд на открытие закрытых разработок давно спал.
"юридический отдел проводит рецензирование открываемого кода" круто у них там с юристами... Хотя может быть просто тупо такие-то строки/файлы отмечены как такой то патент и смотрят можно ли отдать этот патент...