Выпущена сборка Stable Diffusion WebUI Neuro Linux

Когда-то я зарёкся делать сборку Stable Diffusion для Linux, ведь сборки SD WebUI Neuro подразумевают портативность, а существующие Linux дистрибутивы отвратительны в плане поддержки портативного софта, я уже не говорю про "удобство" использования в целом, чем линуксы заслужили своё место под плинтусом на протяжении уже почти трёх десятилетий подряд:
![]() |
![]() |
реклама
Создавать сборку под линуксы, которыми невозможно по-человечески пользоваться? В которых на протяжении всей истории бурлит ад зависимостей и постоянно что-нибудь ломают? Извольте, но поддерживать зоопарк вечно кривых линуксов я не собирался, и не собираюсь.
Однако недавно я выпустил свой дистрибутив, кривой и косой Chimbalix 23.1 Alphachi, ведь меня некоторое время уже просили выпустить образ, и я пытался успеть до Нового Года.
Но сейчас я работаю над новой версией дистрибутива Chimbalix 24.1 Alphachi, и попутно решил выпустить сборку Stable Diffusion WebUI Neuro Linux, ведь благодаря каталогу "portsoft" появилась возможность устанавливать и использовать подобный софт хранящий всё в своей папке, не размазывая фекалиями (файлы конфигурации, дополнения, результаты работы и т.п.) по всему сортиру (линуксу), как это делает практически любой линуксоидный софт...
реклама

Однако характерный для Linux ад зависимостей никуда не исчезает, хоть и сведён моими трудами к минимуму, среди таких зависимостей особо отмечу абсолютные пути, формирующиеся по принципу "и так сойдёт" при крассической "установке" оригинального SD WebUI...
Если в Windows версиях Stable Diffusion WebUI достаточно исправлять один единственный файл "pyvenv.cfg", чтобы сборку можно было запустить даже после перемещения на другой ПК, то в среде Linux обмазались абсолютными путями как могли, и приходится исправлять порядка ~60 файлов (уже точно не помню сколько), пришлось автоматизировать это мракобесие, иначе любое изменение путей к Stable Diffusion WebUI приводило к неработоспособности приложения, что абсолютно неприемлемо:

реклама
Так же отмечу, пользователи всяких Ubuntu (по умолчанию не установлен даже git...), а так же дистрибутивов с Glibc версии ниже 2.35 пролетают мимо моей сборки, не поможет даже если в системе будет полноценно установлен Python3.11, скажите спасибо характерному для Linux болоту зависимостей:


Особенно меня позабавили характерные для Ubuntu принудительные обновления без разрешения пользователя:
реклама

Это просто отвратительно, когда операционная система без разрешения выкачивает обновления и засоряет кэш пакетов, а ведь если в процессе принудительных обновлений что-то пойдёт не так, это легко приводит к поломке дистрибутива, ведь зависимость за зависимость и поехало...

Да, я пытался в Ubuntu 20.04 LTS запустить сборку, даже пытался Python "оторвать" от системы, чтобы сборка полагалась на локальный Python в своей же папке, как это происходит в Windows версии сборки Neuro, но линуксоиды разорвали на части даже "Питухона", оторвав от него модуль venv необходимый для работы, в итоге просто указать пути к исполняемым файлам недостаточно...

Но Питухон (Python) та ещё мерзкая "зависимость", даже скомпилировав и установив в систему Python3.11 и Python3.12 из исходного кода, оно никак не желало дружиться со сборкой, наверное нужно ещё сам venv особым образом подготовить в каком-нибудь старом дистрибутиве, чтобы локальные исполняемые файлы были зависимы от очень старого Glibc, ведь простые методы подмены не сработали:
![]() |
![]() |
Тем не менее, моя сборка в моём дистрибутиве работает даже если полностью вычистить из системы Python3.11 установив вместо него Python3.12 скомпилированный из исходного кода, так даже отпадает возня с модулем venv, послужившим причиной выпуска первого сервис пака для дистрибутива Chimbalix 23.1 Alphachi, но характерный для Linux ад зависимостей конечно же не позволит просто так сменить Питухон 3.11 на 3.12, ведь есть много системных зависимостей несовместимых с версией 3.12...
![]() |
![]() |
![]() |
Однако ради интереса был проверен дистрибутив Manjaro 23 KDE, и на удивление разработчики позаботились о том, чтобы в системе был установлен git и python полноценно, потому всё заработало с пинка в виртуальной машине:
![]() |
![]() |
![]() |
![]() |
![]() |
Будем считать это приятным бонусом, что сборка Stable Diffusion WebUI Neuro Linux способна работать в некоторых других дистрибутивах, которые не настолько ущербны как Ubuntu или оригинальный MX Linux...
Конечно в сборке была предусмотрена и экспериментальная возможность установки в стандартный каталог "portsoft", я даже набросал скрипт для этой задачи, однако важно заметить, эта возможность доступна только для дистрибутива Chimbalix:
![]() |
![]() |
![]() |
Ведь происходит не только копирование папки с приложением в стандартный каталог "portsoft", но и размещение ярлыков в меню "Пуск" для быстрого доступа, а я не поддерживаю линуксоидные принципы, когда одно приложение может занимать две и более категории одновременно, что обычно приводит к дублированию ярлыков в разных разделах, потому структура моего меню отличается от структуры в других линуксах, и является лишь частично совместимой:

Хотя если честно, Whisker Menu меня очень огорчает своей функциональной несостоятельностью, а именно невозможностью создавать вложенные меню, как это может делать даже Меню древней Windows 7, потому в новой версии дистрибутива, вполне возможно, я сделаю стандартом обычное Xfce меню, да, это возврат к уровню Windows XP, и даже хуже, но в целом это может быть лучше и практичнее функционально несостоятельного Whisker Menu:
![]() |
![]() |
К слову, про последнюю версию Whisker Menu, а то вдруг кто-то подумает что я говорю про "устаревшие" версии плагина, а новые даже не трогал... Взял значит последнюю версию плагина, и начал компилировать:

И тут пошло поехало, то одной зависимости не хватает, какой-то "gtk+-3.0", которого в репозиториях и близко не существует под таким названием:

То другой зависимости нет:

И так я собрал список из 8 зависимостей, имена которых не особо то и совпадали с тем, что требовалось в сообщениях об ошибках, и так каждую зависимость приходилось угадывать методом логики и перебора в совокупности с поисковой системой, а ещё линуксоиды говорят что это в Windows проблемы с поиском нужных VC Redist по кодам ошибок вроде "MSVCR120"...

Так я скомпилировал плагин, но вместо нового функционала получил всё то же меню, только разработчики умудрились сделать его ещё хуже, чем было, ведь в старой версии можно было изменять размер меню простым растягиванием за грани, а в новой всё поломали, теперь меню не растягивается... Впрочем, в линуксах всегда так, идиоты постоянно ломают что раньше прекрасно работало, а некоторые другие идиоты ещё и принуждают к обновлениям похлеще чем Microsoft...

Но не будем далеко отходить от темы.
Для запуска сборки достаточно просто запустить один из скриптов в терминале, для обычного запуска никакие дополнительные права в системе не нужны, но для установщика нужны root права, в новой версии дистрибутива это можно сделать прямо из контекстного меню, однако в доступном Chimbalix 23.1 Alphachi придётся это всё делать через терминал, увы:

Установщик обозревать не буду, это по сути просто поделка на коленке:
![]() |
![]() |
После установки доступны ярлыки в меню, так как у меня установлен полноценный драйвер NVIDIA, то буду использовать GPU c оптимизациями Xformers:

Так как SD WebUI по большей части это набор Python скриптов, то и работают они в терминале, но пугаться нечего:
![]() |
![]() |
Ведь после запуска открывается стандартный в системе браузер с интерфейсом:

Обычно в терминал можно вообще не заглядывать, там в основном техническая информация, и в случае ошибок всплывает более подробная информация, в общем вписываю Promt и генерирую грибы в лесу со скоростью примерно 2 итерации в секунду со своей GTX 1070:
![]() |
![]() |
![]() |
![]() |
Вот так легко и просто, правда как многие уже наверняка заметили, сборка предназначена для видеокарт от NVIDIA, ведь в отличие от AMD, достаточно просто установить полноценный драйвер с сайта NVIDIA (~4.1 ГиБ, например cuda_12.3.1_545.23.08_linux.run) чтобы всё работало как положено, никакой возни с ROCm/OpenCL и прочим дерьмом даже на системах без доступа к интернету.
Почему я даже не подумаю делать сборку SD WebUI Neuro Linux для видеокарт AMD? Хм, как бы сказать, начнём с того, что у меня нет сейчас под рукой лишней видеокарты, а ещё...
Когда AMD прекратит относиться к потребителям как к говноедам, тогда я подумаю над AMD сборкой SD WebUI для Linux, сейчас у AMD даже автономных установочных пакетов драйверов для Linux нет, только убогие скрипты (под видом установочного пакета) качающие из репозиториев зависимости, которые наверняка будут поломаны если вдруг что не так пойдёт, например не будет доступа к интернету при установке "драйвера" видеокарты:
![]() |
![]() |
Ну да ладно, перейдём к более интересному, а именно к расширениям для SD WebUI, так как при выпуске первых версий Neuro я облажался не собрав все доступные расширения из вечно обновляющихся репозиториев, а новые версии расширений порой отказываются работать со старыми версиями SD WebUI, сейчас этот недочёт был учтён, да, я сделал локальный архив расширений доступных на 2024-01-16:

Архив доступен в репозитории со сборками Neuro:
https://github.com/Shedou/Neuro
![]() |
![]() |
Теперь можно взять любое расширение из архива и использовать не боясь того, что автору репозитория ударит моча в голову и некогда исправное расширение будет поломано, или банально удалят репозиторий и цепочка зависимостей поломается...
![]() |
![]() |
![]() |
![]() |
Да, модели и прочие ресурсы не входят в комплект по понятным причинам (огромный размер), но модели наверняка можно наскрести где угодно так как это "ходовой ресурс", в отличие от расширений, в конце концов расширения содержат в себе ссылки на конкретные зависимости из интернета, по которым можно вычислить необходимую для работы модель:

На скриншоте выше автоматически скачиваются недостающие модели, у пользователя останется название недоступного файла когда репозитории умрут с такими зависимостями, а найти один файл в интернете гораздо проще, чем целое расширение неизвестной версии из десятков файлов, в этом и суть архива расширений:

Однако зависимости в виде моделей это ещё пол беды:

Возьмём довольно популярный ControlNet, и тут же выясняется, что если просто скопировать расширение в папку, оно не будет полноценно работать, ведь для полного функционала необходимо устанавливать всё через репозиторий чтобы сработал установочный скрипт, а там начинает подсасываться пачка "левых" зависимостей прямо в venv сборки:

Хотя в более новой версии часть зависимостей разработчики расширения переработали, и даже пытались убрать мусор за собой, но пока что кардинально ничего не изменилось, просто некоторые зависимости тянутся через whl пакеты, та же помойка, только в профиль...
![]() |
![]() |
Про какую пачку зависимостей я говорил? 73 каталога (2 удалены мною вручную, их нет на скриншоте) и 5 файлов, из которых модули cv2 и numpy были обновлены без какого либо разрешения и уведомления во время установки ControlNet, а это легко может привести к конфликту зависимостей, что полагались на старые версии обновлённых модулей:

Так что архив хоть и есть, но ад зависимостей разведённый не очень разумными разработчиками всё равно присутствует в какой-то степени, и это следует понимать...
А ещё в процессе написания статьи выяснилось, что я перестарался со сжатием архива пытаясь уложиться в три части до 2 ГиБ каждая, и обычные линуксоидные архиваторы после распаковки ругаются на ошибки:

Которых по сути нет...

И раз уж мне придётся перепаковать архив с более простыми настройками сжатия, а это повлечёт за собой четвёртую часть, так как с простым сжатием будут превышены лимиты размера, не вижу ничего зазорного в том, чтобы интегрировать расширение ControlNet в сборку, ведь появились "лишние" 2 ГиБ на это дело:

Только одна проблема, комплект моделей аннотации занимает гораздо больше, чем я могу себе позволить, особенно модели clip_vision, для использования которых недостаточно 8 ГБ памяти на моей GTX 1070...

Это на самом деле большая проблема, даже если избавлюсь от clip_vision, остальные модели всё равно весят больше 8 ГиБ, и самое ужасное в том, что они плохо поддаются сжатию.
Ну что же, делать нечего, придётся решить проблемы с вечно раздражающими зависимостями, и выпустить вторую версию сборки установив самый свежий на текущий момент ControlNet!
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Но разве могло всё пройти идеально в болоте зависимостей? Особенно если нужно компилировать модули из исходного кода? Конечно же нет, да и нет в этом ничего нового, собственно потому Windows и продолжает доминировать несмотря на "современный путь" корпорации...
![]() |
![]() |
Ещё немного пердолинга с вечно кривыми зависимостями в стиле "Linux":
![]() |
![]() |
![]() |
И мне надоело пинать кривой мусор, так как не хотелось оставлять явно проблемный функционал в сборке, было решено просто убрать "проблемы", если кому-то это не по нраву - вперёд и с песней, танцуйте с бубном хоть до поседения:
![]() |
![]() |
![]() |
Надеюсь все желающие потанцевать с бубном умеют пользоваться поисковыми системами, ведь они просто наводнены бесконечными проблемами с этим всем дерьмом кривым, наверняка нужно будет просто пару команд прописать в терминале и всё само чудесным образом починится, ага:

Да и набор моделей препроцессоров весит неприлично много, как раз почищу "лишнее", всё равно часть моделей не выйдет использовать, а место ведь не резиновое:

В процессе очередной проверки меня очень позабавили обнаруженные зависимости в каталоге ".cache", это какими должны быть придурками разработчики, чтобы модули и модели хранить в папке кэша? А если пользователь захочет перенести на другой ПК приложение? Тащить и папку кэша? Которая кстати может быть очищена в любой момент просто при чистке операционной системы от мусора...
![]() |
![]() |
![]() |
Сразу видно линуксоидный подход, ибо адекватный человек не станет такое вытворять, и конечно же не я один офигел от такой дикости с хранением модулей в кэше, а это по сути и есть то самое "прибито гвоздями к системе":

Радует лишь одно, такие мерзкие зависимости получилось окучить простым костылём в одну строку, причём замечу, раньше можно было это сделать через переменную TORCH_HUB, но сейчас она "deprecated", потому нужно использовать TORCH_HOME, никакой стабильности в "линуксоидном" софте, как всегда...

Эх, что-то растянулась статья, а ведь я очень старался танцы с бубном над сборкой Neuro под Linux оставить "за кадром", но не вышло, не получилось, чем больше проверяю и тестирую, тем больше всплывает кривого дерьма... Пожалуй на этом завершу текущую статью, ибо работа над новой версией сборки ещё не закончена, а объём набрался приличный.
В начале статьи я уже оставлял ссылку на репозиторий со сборками Neuro, но сделаю это и в конце, на текущий момент доступна только первая версия сборки SD WebUI Neuro Linux с выявленными недостатками, не думаю что она будет востребована, однако несмотря на недостатки она есть и работает, потому не вижу смысла удалять, и заменять обновлённой версией:
Репозиторий со сборками Neuro: ( https://github.com/Shedou/Neuro ).

Когда будет выпущена новая версия сборки с интегрированным ControlNet? Это уже как получится, в конце концов мало набросать всего подряд и выпустить, как это обычно принято у "линуксоидов" с вечно кривыми поделками, всё же тестирование на работоспособность и доработка всяких "ControlNet" занимает некоторое время...
Благодарю за внимание, больше интересных статей в блоге Hard-Workshop.

Лента материалов
Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
Комментарии, содержащие оскорбления, нецензурные выражения (в т.ч. замаскированный мат), экстремистские высказывания, рекламу и спам, удаляются независимо от содержимого, а к их авторам могут применяться меры вплоть до запрета написания комментариев и, в случае написания комментария через социальные сети, жалобы в администрацию данной сети.






















































Комментарии Правила