Comments 18
Кому-то пора в АМД - драйверы писать
Чтобы отбить у них желание прекращать выпускать обновления драйверов для довольно свежих видеокарт, как недавно случилось с Vega?)
с чего такой вывод? я имел ввиду писать драйверы в принципе, а вовсе не этот конкретный. емнип, у АМД с дровами вечная проблема, там то ли один то ли пара кодеров пишут им дрова (потому что очень трудно найти специалистов!). третий кодер им точно лишним не будет.
вечная проблема с дровами амд только у обладателей нвидиа
для затравки: https://www.ixbt.com/news/2024/03/28/geforce-rtx-4080-virtus-pro-counter-strike-2-1-25.html
Мне кажется, чисто с точки зрения качества поддержки Vulkan было бы продуктивнее развивать RADV, а не пытаться постоянно его кое-как догонять, как они уже долгие месяцы или годы пытаются завести graphics pipeline library, когда в RADV уже завезли VK_EXT_shader_object.
Как в альтернативе на всякий случай, может быть, и есть для пользователей смысл в официальных драйверах, в том числе за счёт того, что у них во многом единая кодовая база (в смысле, их Platform Abstraction Library) для разных API, и один и тот же компилятор шейдеров (хотя, в открытом AMDVLK и в Radeon Software/AMDGPU-PRO, как я понимаю, разные), и наработки для Direct3D попадают и в драйвер Вулкана.
Но RADV в любом случае интереснее с точки зрения фичей, и было бы, наверно, круто и более эффективно, если бы AMD не двойную работу параллельно делали, а сами сконцентрировали бы свои ресурсы на RADV. Но да, тут опять же встаёт вопрос, кто там этим будет заниматься, а ещё какой там тогда менеджмент будет. Если они его будут разрабатывать так, как у них Марек Ольшак делает драйвер Gallium RadeonSI в Mesa, то это было бы максимально классно, но он драйверами Radeon в Mesa занимается ещё со времён TeraScale. А вот если как в AMDVLK, где огромный кусок кодовой базы для GPU старше Vega перенесли в отдельную папку, на которую, как мне показалось, быстро подзабили, где новые фичи (порой в недоделанном виде) включают только для отдельных приложений (https://github.com/GPUOpen-Drivers/AMDVLK/issues/324#issuecomment-1961291027), и где под предлогами вроде «оно у нас слишком медленно работает» годами не добавляют fragment shader interlock, при том, что он у них и так есть в Direct3D (https://github.com/GPUOpen-Drivers/AMDVLK/issues/108), из-за чего мне пришлось самому идти и реализовывать его в RADV — пожалуйста, лучше не надо, пусть лучше будет остаётся подход, как сейчас, при котором я на могу на RADV играть с программным рейтрейсингом на HD 7xxx :D
а много ли HD6000 живых вообще? мне что-то помнилось, что там достаточно мручая серия вышла...
Топовых может и мало осталось, но вот чего то типа 6450/6570/6770 достаточно. Для 6450 с её заявленным потреблением 20/27 Вт вообще аналогов не просматривается в нынешних поколениях.
Кстати непонятно, драйвер только для vliw4 (6950/6970) или на vliw5 (все остальное 6хх0 и 5хх0) тоже.
для 6450 кмк замена - встройка
Для VLIW5 тоже, причём для них в первую очередь, так как для них надо больше костылей — нет виртуальной памяти, по-разному биндятся ресурсы в зависимости от того, используется ли тесселяция, unnormalized coordinates включаются не в параметрах сэмплера, а в константных полях инструкции чтения из текстуры, вершинные буферы поддерживают stride максимум 2047, а не 2048.
Неужели между vliw4 и vliw5 такая большая разница?
Не очень большая, в R9xx всякие мелкие странности починили, но главная новая фишка там это виртуальная память, с которой в теории можно реализовать, например, VK_KHR_buffer_device_address (хоть и костыльно, поверх биндинга буфера размером 4 ГБ, потому что просто доступа к памяти по произвольным адресам в шейдерах там, в отличие от GCN, нет), а если сделать поддержку в ядре, то, может быть, и sparse binding.
А не будет продуктивнее вместо костыления сделать экстеншен, который честно говорит "не шмогла" и явно ограничивается тем, что можно сделать в DX11, OpenGL ES 3.0 или даже 2.0? Типа OpenGL 3.2, но для explicit API. Понятно, что Doom 2016 так не запустить, зато есть больше чем нулевой шанс, что кто-то заморочится да поддержит в его в DXVK, или напишет такой же драйвер для другой архитектуры.
Очевидно, что это проект для фана, а не пользы, но мало ли.
Стоит в старом компе 6950. Надо попробовать Вулкан!
То что на компе Windows 11 имеет значение?
На 69xx пока на Windows не пробовал (да и на Linux на них не тестирую, у меня 6990 как-то странно работает, то с ней компьютер запускается, то отваливается порт PCI Express до тех пор, пока не сделаю CMOS reset), я пока виртуальную память даже не начинал прикручивать, не знаю, обязательно ли её использовать на них в AMDшном драйвере, или патчинг адресов в буферах команд тоже будет работать. Ещё не проверял, совпадают ли между R8xx и R9xx смещения полей с информацией о GPU (типа параметров тайлинга текстур) в KMTQAITYPE_UMDRIVERPRIVATE. Я ещё пока пробовал только на драйвере Crimson Edition в 64-битном приложении, на Catalyst 2015 года тоже могут другие структуры потенциально быть.
На 11 должно работать, на 7 пока нет, но там, вроде, проблема только в том, что функции D3DKMTOpenAdapterFromLuid нет, и придётся, используя известную технику удаления гланд, как-то через cfgmgr32 или даже WMI доставать путь к видеокарте для D3DKMTOpenAdapterFromDeviceName.
Но там всё равно пока нечего смотреть по большей части. Vulkan 1.0 реализован пока, как примерно говорит разработчик одного аналогичного по духу проекта, чуть менее, чем наполовину)
Для Windows представлен Vulkan-видеодрайвер с открытым исходным кодом проекта Terakan для видеокарт серии Radeon HD 6000