LLVMpipe проблема современных дистрибутивов Linux: Поломали что работало
Предисловие
В прошлой части я провёл тестирование в 17 дистрибутивах Linux, 3 из которых были совсем старые (2013-2014 года выпуска), и 14 более современных дистрибутивов, по итогу 5 дистрибутивов прошли тест, а 9 откровенно провалились:
LLVMpipe проблема современных дистрибутивов Linux
В чем суть данного тестирования? Всё очень просто, в дистрибутивах Linux есть драйвер под названием LLVMpipe, он создан как раз для случаев когда установлена нефункциональная видеокарта, например в виртуальной машине, или ПК со встроенной графикой.
Драйвер LLVMpipe обязан заменять неполноценную видеокарту используя процессор для работы, да, процессор гораздо медленнее видеокарты, но это не всегда имеет значение, порой достаточно чтобы приложение хоть как-то работало, да и производительность современных процессоров уже достигла достаточно высокого уровня, чтобы в принципе заменить многие очень старые видеокарты.
Короче, благодаря этому драйверу у пользователя не должно быть проблем с запуском OpenGL приложений и игр, даже когда установлена древняя "затычка" вместо видеокарты (банально нет нужды в полноценной видеокарте на конкретной системе).
Кстати, у Microsoft есть аналог драйверу LLVMpipe, называется Windows Advanced Rasterization Platform (WARP), благодаря ему у Windows 10/11 нормально работает композитор рабочего стола даже в виртуальных машинах, и даже позволяет в некоторые игры поиграть без драйвера на видеокарту, но для обычного пользователя этот драйвер не представляет особого интереса, ибо в большинстве случаев и без него всё прекрасно работает, ибо у Windows практически всегда под любые видеокарты есть рабочий драйвер.
Но сейчас речь идёт не про WARP.
Почему я решил ещё раз поднять тему
В первой статье затронувшей проблему LLVMpipe появился один фанат Linux, он рассказывал какой я рукожоп, даже не смог запустить свой собственный тест, в этом уже есть логическая проблема - разработчик приложения не может запустить своё же приложение:
Собственно вот прикреплённый скриншот, что он такой крутой прекрасно запустил всё, правда запускал он из дистрибутива Gentoo, а такого у меня вообще не было в тестировании:
Ну выпендривался человек, показал свою "крутость", мне то что, набрасываться на него как петух? Нафиг он мне сдался. Однако вышла другая статья, а этот фанатик так и липнет как банный лист до жопы попутно выбрасывая оскорбления в мой адрес:
Обзор Wubuntu 11.3 (KDE): Пользовательский интерфейс
Причем важно заметить, человек не понимает разницы между LLVM и драйвером LLVMpipe, либо он специально занимается софизмом подменяя понятия, чтобы выставить себя красивее в глазах неопытных пользователей, в общем пустой трёп, тем более в прошлой статье я чётко разграничивал LLVM и LLVMpipe:
LLVM - Проект программной инфраструктуры для создания компиляторов и сопутствующих им утилит. Состоит из набора компиляторов из языков высокого уровня, системы оптимизации, интерпретации и компиляции в машинный код. (2023-07-31).
LLVMpipe - Драйвер Gallium LLVMpipe — это программный растеризатор, который использует LLVM для генерации кода во время выполнения. Шейдеры, растеризация точек/линий/треугольников и обработка вершин реализуются с помощью LLVM IR, который транслируется в машинный код x86, x86-64 или ppc64le. Кроме того, драйвер является многопоточным, чтобы использовать преимущества нескольких ядер ЦП (до 32 в настоящее время). Это самый быстрый программный растеризатор для Mesa. Переведено с помощью Google Translate. (2023-07-31).
Теперь каждый кто прочитал - знает разницу между LLVM и LLVMpipe.
Но это не основная причина поднять тему и сделать ещё одну статью, основная причина в обнаруженных новых нюансах, например, в дистрибутиве Kubuntu тест зависал намертво, однако отключение анизотропной фильтрации всё меняло, если её отключить драйвер LLVMpipe не зависал, так же и в среде Windows получилось:
А это значит что у драйвера есть проблемы с анизотропной фильтрацией, осталось только выяснить, какие именно версии драйвера имеют столь серьёзную проблему, ведь я наверняка знаю что старые версии не подвержены проблеме, а значит проблема появилась относительно недавно.
-
--
---
Подготовка
Можно ставить десятки дистрибутивов и смотреть на зависшее окно по вине кривого драйвера LLVMpipe, но что это даст в целом? Думаю ничего, потому я взялся за сам LLVMpipe драйвер, и буду проверять скомпилированные версии для Windows, да, вот так резко и нагло!
Использовать буду релизы Mesa3D из репозитория GitHub, называется mesa-dist-win от пользователя pal1000:
https://github.com/pal1000/mesa-dist-win
Неужели я настолько безумец, чтобы выкачивать две сотни релизов ради проверки? И да, и нет, я не все релизы скачал, но этого думаю хватит для тестов, весит это всё почти 9ГБ:
Не обошлось без "подозрительных" файлов, но их я тоже постараюсь протестировать, в конце концов любой старый файл можно отметить как "подозрительный", тут уже зависит от того, что именно считать "вирусом", и насколько далеко зайдёт "шиза" у антивирусных компаний, да и просто у любителей "безопасности", всё хорошо в меру:
А ведь отличная идея помечать старое как "вирус" для реализации запланированного устаревания и принуждения людей к переходу на более "новое", этакая манипуляция страхом, да и антивирусы часто без разрешения пользователя удаляют файлы которые не понравились, так что можно ещё и принудительно вычищать таким способом "неугодное" из систем пользователей... Но не будем отходить от темы.
Следует отметить факт наличия разных версий Mesa3D, одна скомпилирована через MinGW (Minimalist GNU for Windows), вторая через MSVC (Microsoft Visual Studio Compiler), в чем разница?
На самом деле я не знаю в чём разница, ибо MinGW (Minimalist GNU for Windows) версия ругается на отсутствующие зависимости, при этом весит гораздо больше MSVC версии, я не хочу вручную прикручивая костыли для удовлетворения зависимостей, потому MinGW версия Mesa3D не будет участвовать в тестировании:
В качестве тестового приложения использую свой же ChimbaBench, а для удобства создам BAT файлы в которых буду указывать параметры перед запуском:
Тестирование буду проводить только в среде Windows, просто потому что под дистрибутивы Linux я не нашёл уже готовых для нормального использования библиотек Mesa3D, так что увы, но дистрибутивы в сторонку. У меня и так достаточно большой объём работы впереди, если я буду ещё возиться с компиляцией библиотек и попыткой их использовать в дистрибутивах Linux, то никаких сил и времени не хватит всё проверить:
А чтобы тестирование было интереснее, в качестве полноценной игры я возьму SuperTuxCart v1.3, правда через мониторинг MSI Afterburner не видно какой именно драйвер использован, потому нужно очень внимательно раскладывать собранные результаты по полочкам, иначе легко перепутать разные версии:
Сторонняя игра как раз решит вопрос отсутствия проблемы именно в моём тесте, ведь если разные приложения будут зависать, значит дело не в приложениях, а в драйвере через который работают приложения.
Полагаю логика проста и понятна, закидываю Mesa3D к ChimbaBench, открываю один из подготовленных BAT файлов, смотрю как работает, сохраняю скриншот в отдельной папке. Аналогично для SuperTuxCart:
-
--
---
Сбор результатов
Начну с простого, соберу информацию используя свой же тест, анизотропная фильтрация 4x, сглаживание отключено, разрешение 360p (640x360), приложение перенёс на основной NVMe SSD так как он гораздо быстрее обычного SATA SSD:
Содержимое BAT файла для запуска, здесь выставляю переменную GALLIUM_DRIVER чтобы принудительно запустить с драйвером llvmpipe, если этого не сделать то будет использован по умолчанию DiretctX 12 драйвер, а это мне не нужно:
Игру SuperTuxKart было решено проверять вместе с ChimbaBench, просто чтобы лишний раз не возвращаться к копированию Mesa3D библиотек, утилиту MSI Afterburner тоже было решено не запускать, и так понятно когда зависает, а когда работает, настройки на скриншотах:
Вот и первые результаты собраны, SuperTuxKart тестирую запуская "Режим истории", то есть пытаюсь поиграть, главное не забывать перемещать скриншоты в свои папки, сейчас я проверил Mesa3D версии 23.2.0 RC1, в одноимённую папку и перемещу полученные два скриншота:
Прямо сейчас я не буду никакие таблицы составлять, сейчас только сбор результатов, ничего более, анализ и представление результатов буду делать когда всё протестирую.
А ещё отмечу факт, Microsoft Windows прекрасно видит зависшие приложения и вежливо предлагает закрыть, в дистрибутивах Linux приходилось через диспетчер задач закрывать всё что зависло, просто потому что дистрибутивы не понимают когда зависло, а когда нормально работает, и это ещё одна весомая причина по которой я сейчас провожу тесты именно в среде Windows, а не Linux.
Но скриншоты я буду сохранять без этого окошка... Чтобы захватить и саму "игру", и окошко "приложение не отвечает", мне нужно вручную выделять область для сохранения как скриншот, что крайне непродуктивно, потому я просто буду сохранять скриншот основного окна, всё равно в заголовке видно "приложение не отвечает", а само окно переходит в серый цвет:
Протестировал Mesa3D 23.x.x, всего 10 версий, для разминки сойдёт, но в итоге всё версии драйвера провалились, тут даже говорить нечего, зависает и всё на этом:
Далее версии 22.x.x, всего 23 теста провести, это не так уж и много если посмотреть на общее число файлов, сейчас я специально не пропускаю ни одной версии Mesa3D так как нужно узнать с какого именно момента появилась проблема:
Начинаю с версии 22.3.5 и по убывающей, Mesa32 22.3.4 и 22.3.5 сразу же отморозились, ChimbaBench даже не запустился, а SuperTuxKart выбросил ошибку "no symbol available", короче начало многообещающее...
Mesa3D версии 22.2.1 и 22.2.0 показали забавное поведение, ChimbaBench завис как обычно при попытке запустить тест GPU Heavy, а вот SuperTuxCart просто закрывался без сообщений об ошибках при попытке зайти в игру, ещё две откровенно кривые версии драйвера обнаружены. С таким же косяком Mesa3D версий 22.0.1, 22.0.2 и 22.0.3.
Итого все версии Mesa3D 22.x.x провалились, похоже косяк довольно старый, удивительно почему его до сих пор не обнаружили и не исправили, неужели разработчики не пользуются своими же творениями? Иначе я не знаю как это объяснить:
И вот добравшись до Mesa3D версии 21.x.x начались изменения, начну с хорошей новости! Mesa3D версии 21.2.5 и всё что старее смогли пройти как GPU Heavy тест, так и SuperTuxKart:
А теперь к плохой новости, с дайвером LLVMpipe всё не так хорошо как хотелось бы... И нет, претензий к работе ChimbaBench GPU Heavy у меня нет, этот тест пройден без претензий:
У меня возникли вопросы во время проверки игры SuperTuxKart, многие наверное уже заметили что следующие скриншоты имеют разные пропорции?
Как же так получилось? Давайте посмотрим внимательнее на размер скриншотов, после каждого тестирования размер скриншота уменьшался на 10 пикселей по ширине и высоте, и это серьёзная проблема:
То есть после каждого запуска через драйвер LLVMpipe у игры снижалось разрешение на 10 пикселей по каждой стороне, и происходит это не во время запуска игры, нет, это происходит после загрузки уровня, то есть когда нажимаю кнопку "Режим истории" и могу играть:
С нормальным драйвером OpenGL от NVIDIA такой проблемы нет, и никогда у меня не было в данной игре. Вот и преимущество тестирования с разными "играми", ибо ChimbaBench отлично работал с драйвером LLVMpipe, а в игре SuperTuxKart проявился косяк.
На этом можно было закончить тестирование, ведь я определил версию Mesa3D начиная с которой драйвер LLVMpipe перестал работать как положено, но разве уже есть смысл останавливаться? Конечно нет, так что продолжаю.
В процессе обнаружен нюанс, обычно в игре SuperTuxKart производительность была на уровне ~4-6 FPS (на глаз), то есть не совсем слайд шоу, но с драйвером LLVMpipe в составе Mesa3D-20.0.7 производительность оказалась действительно на уровне "слайд шоу", 2 FPS максимум, и это притом, что разрешение окна значительно уменьшилось относительно стандартных 1280x720 так как при каждом тестировании по 10 пикселей срезается с драйвером LLVMpipe, из разницы я заметил что LLVM теперь 128-bits, вероятно дело в этом, ибо более новые версии 256 битные.
Так или иначе все протестированные старые версии драйвера работают, это на секундочку уже версии 2020-2021 года:
Так как ничего больше кардинально не меняется, было решено тестировать через одну версию Mesa3D, не то чтобы для меня было проблемой протестировать каждую версию, это просто дурная работа, я таблиц не наберусь чтобы результаты представить, потому немного прорежу ряды:
Всё шло предсказуемо, пока я не взял Mesa3D версии 19.2.7, с которой ChimbaBench не запустился выдав ошибку 0xc0000142, а вот SuperTuxKart запустился весьма бодро, и на удивление показал производительность даже выше, чем была у последних рабочих версий LLVMpipe... Теперь на глаз не 1-2 FPS, и даже не 4-6 FPS, а все 6-8 FPS, вот кто же знал что такой нюанс всплывёт, теперь нужно тестировать и следующую ближайшую версию драйвера, а ведь я только проредил списочек:
В итоге большинство версий прошло испытания, начиная с 19.2.0 ломали драйвер, но в версии 19.3.0-2 починили обратно, но при этом значительно снизился уровень производительности:
Ладно, перейдём к 18 версии Mesa3D... Из примечательного отмечу лишь одно, скорость загрузки значительно снизилась относительно более новых версий Mesa3D, ну и сам проект теперь называется просто Mesa:
Да, я протестировал и 17 версии Mesa, ничего особенного не происходило:
Теперь остался нудный и кропотливый процесс создания таблицы с результатами...
-
--
---
Результаты
Пришло время посмотреть на ситуацию в целом.
Mesa версии 17.x.x - 18.x.x без проблем прошли испытания, да, со скоростью запуска были проблемы, но GPU Heavy и игра SuperTuxKart абсолютно без проблем работали.
В версиях Mesa3D 19.0.0 - 19.1.7 поправили скорость запуска, и в целом всё отлично работало, пока не вышла версия 19.2.0 с которой ChimbaBench при старте просто закрывался с ошибкой приложения, а потом вышла версия 19.3.0-2 и "CRASH" исправили, но появилась другая проблема, уровень производительности снизился в разы, собственно выглядит это как то так:
Драйвер LLVMpipe в составе Mesa3D 20.x.x оказался самым работоспособным, ни одной проблемы:
Так же и Mesa3D 21.0.0 - 21.2.5, драйвер LLVMpipe прекрасно работал, пока не вышла версия 21.3.0, с этого момента начинаются тотальные проблемы:
Драйвер LLVMpipe в составе Mesa3D 22.0.0 и новее показал себя просто как откровенный нерабочий хлам, без вариантов:
Собственно проблема LLVMpipe современных дистрибутивов максимально подтвердилась, современные версии драйвера имеют серьёзные проблемы, а они встроены во многие современные дистрибутивы Linux.
-
--
---
Заключение
Тут больше нечего говорить, проблема есть, и она серьёзная, и совершенно непонятно когда разработчики драйвера LLVMpipe эту проблему будут исправлять, ведь проблеме уже больше года, и нет никаких положительных изменений до сих пор...
Причём важно заметить, в старых версиях драйвера проблем не было, а если и бывали в совсем старых версиях то достаточно быстро исправлялись.
А ещё не удивлюсь если фанатики Linux попробуют оправдывать выявленные проблемы тем фактом, что тесты проведены в среде Windows, увы, но в среде Windows я это всё сделал как раз потому, что в среде Linux проблема и была обнаружена, а протестировать её полноценно в той же среде Linux попросту невозможно, ибо не нашёл готовых для нормального использования библиотек Mesa3D с драйвером LLVMpipe, а танцевать с бубном и компилировать из исходников довольно проблематичное занятие, на красноглазого любителя.
Благодарю за внимание, больше интересных статей в блоге Hard-Workshop.
Лента материалов
Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
Комментарии, содержащие оскорбления, нецензурные выражения (в т.ч. замаскированный мат), экстремистские высказывания, рекламу и спам, удаляются независимо от содержимого, а к их авторам могут применяться меры вплоть до запрета написания комментариев и, в случае написания комментария через социальные сети, жалобы в администрацию данной сети.
Комментарии Правила