Спасибо патентам за пляски с libtxc_dxtn и за то, что для телефонов приходится сжимать текстуры отдельно от ПК и консолей. Особенно очень полезно (нет) для развития опенсорса.
Не очень большая, в R9xx всякие мелкие странности починили, но главная новая фишка там это виртуальная память, с которой в теории можно реализовать, например, VK_KHR_buffer_device_address (хоть и костыльно, поверх биндинга буфера размером 4 ГБ, потому что просто доступа к памяти по произвольным адресам в шейдерах там, в отличие от GCN, нет), а если сделать поддержку в ядре, то, может быть, и sparse binding.
На 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 реализован пока, как примерно говорит разработчик одного аналогичного по духу проекта, чуть менее, чем наполовину)
Для VLIW5 тоже, причём для них в первую очередь, так как для них надо больше костылей — нет виртуальной памяти, по-разному биндятся ресурсы в зависимости от того, используется ли тесселяция, unnormalized coordinates включаются не в параметрах сэмплера, а в константных полях инструкции чтения из текстуры, вершинные буферы поддерживают stride максимум 2047, а не 2048.
Мне кажется, чисто с точки зрения качества поддержки 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
Играть более-менее можно (насчёт стабильности не могу ничего обещать только), но в графике творится что-то крайне странное, в разных то ли плитках, то ли просто участках фреймбуфера земля рисуется по-разному (и везде неправильно), либо вообще не рисуется, а в нижней части не работают тени. Снежинки какие-то огромные, но, может быть, на консоли шейдеры выдают всю ширину point sprite, а эмулятор её использует как половину ширины (хочу как-нибудь проверить, чтобы уж наверняка знать, во что компилируется gl_PointSize на телефоне на Adreno 200, но всё руки не доходят из-за других задач). Возможно, какие-то неточности в эмуляции GPU (вот сейчас копаюсь в поддержке текстур, у которых расстояние между строками в памяти отличается от ширины — из-за того, что это сейчас не учтено, в некоторых играх на экране возникает полосатость), а может быть, что проблемы и на CPU, AltiVec и FPU у нас далеки от совершенства, особенно в плане обработки особых случаев вроде бесконечности. Точно пока не могу сказать, в чём конкретно проблема, хотел в прошлом году поотлаживать, но в основной ветке эмулятора был какой-то вылет, видимо, в нашей самодельной реализации ядра, так до геймплея и не добрался, но сейчас померджили пулл реквесты, можно будет попробовать снова.
Думал и сюда запостить, но оригинальная статья и так блокировала разработку так, что было уже невыносимо… PatientZero, огромное спасибо за перевод!
Спасибо патентам за пляски с libtxc_dxtn и за то, что для телефонов приходится сжимать текстуры отдельно от ПК и консолей. Особенно очень полезно (нет) для развития опенсорса.
Не очень большая, в R9xx всякие мелкие странности починили, но главная новая фишка там это виртуальная память, с которой в теории можно реализовать, например, VK_KHR_buffer_device_address (хоть и костыльно, поверх биндинга буфера размером 4 ГБ, потому что просто доступа к памяти по произвольным адресам в шейдерах там, в отличие от GCN, нет), а если сделать поддержку в ядре, то, может быть, и sparse binding.
На 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 реализован пока, как примерно говорит разработчик одного аналогичного по духу проекта, чуть менее, чем наполовину)
Для VLIW5 тоже, причём для них в первую очередь, так как для них надо больше костылей — нет виртуальной памяти, по-разному биндятся ресурсы в зависимости от того, используется ли тесселяция, unnormalized coordinates включаются не в параметрах сэмплера, а в константных полях инструкции чтения из текстуры, вершинные буферы поддерживают stride максимум 2047, а не 2048.
Мне кажется, чисто с точки зрения качества поддержки 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
Чтобы отбить у них желание прекращать выпускать обновления драйверов для довольно свежих видеокарт, как недавно случилось с Vega?)
Больно на такое смотреть, лучше бы раздали нуждающимся тестировщикам.
Думал и сюда запостить, но оригинальная статья и так блокировала разработку так, что было уже невыносимо… PatientZero, огромное спасибо за перевод!