nixp.ru v3.0

29 марта 2024,
пятница,
13:51:43 MSK

13 января 2015, 11:23

Кроссплатформенный игровой движок C4 Engine отказался от поддержки Linux

6
Игровой движок C4 Engine больше не поддерживает Linux
Игровой движок C4 Engine больше не поддерживает Linux
Иллюстрация с сайта phoronix.com

11 января вышла новая версия кроссплатформенного игрового движка — C4 Engine 4.2 — без поддержки GNU/Linux. Официальная причина: ведущий разработчик «не осилил» Linux.

С4 Engine — проприетарный игровой движок, портированный на Linux в 2012 году. Он поддерживает Windows начиная с XP и новее, Mac OS и PlayStation 4 и другие системы. Эрик Ленгйел (Eric Lengyel) создал движок и компанию, занимающуюся его развитием — Terathon Software.

Отказ от Linux Ленгйел комментирует в анонсе новой версии: «Поддержка Linux была удалена из C4 Engine с версии 4.2. Решение принято на основании несоразмерных затрат времени и денег, которые мы несём поддерживая Linux, к возврату на инвестиции. Также на решение повлияло желание сохранить собственный рассудок, т.к. мой личный опыт с Linux был крайне негативным и привёл к огромным потерям времени, которые можно было направить на более продуктивные задачи. Terathon Software больше не будет способствовать популярности системы, которая, на мой взгляд, уступает по дизайну и Windows, и Mac OS. Linux показал себя как Франкенштейн ОС, собранная из разрозненных и едва функционирующих частей с отвратительной надёжностью и ничтожной надеждой на исправление в будущем. Время, расходуемое на Linux, теперь будет потрачено на усиление нашего продукта на более жизнеспособных системах».

При этом Эрик Ленгйел указывает, что в будущем они могут поддерживать SteamOS, но не позволят запускать движок на обычном Linux.

Постоянная ссылка к новости: http://www.nixp.ru/news/13088.html. Никита Лялин по материалам phoronix.com.

fb twitter vk
Waldo-de-Kard

>они могут поддерживать SteamOS, но не позволят запускать движок на обычном Linux.
Что за наркомания вообще? И что вообще за игры есть на этом движке?

tinman321

Тивоизация или как там её )

Ameise
…т.к. мой личный опыт с Linux был крайне негативным и привёл к огромным потерям времени, которые можно было направить на более продуктивные задачи. Terathon Software больше не будет способствовать популярности системы, которая, на мой взгляд, уступает по дизайну и Windows, и Mac OS.


в этом вся и суть — тыркнул, не пошло, кака — бросил. человеческий мозг трудиться не любит, затратно это. Да и рынок не такой большой как Win.

Raiser_ZX

Как-то это очень странно звучит на фоне:
«Дрю Блисс (Drew Bliss) из компании-разработчика игр Valve, выступая на мероприятии для разработчиков Ubuntu (Ubuntu Developer Summit), сообщил, что Linux становится всё более и более перспективной платформой для игр на фоне выхода Microsoft Windows 8.»
http://www.nixp.ru/news/11967.html

fhunter

Судя по отзывам — автор нарвался на Ubuntu 14.04, ну и…. дальше пошёл троллинг. А разработчик у движка вроде бы только один.
Дословно там было вплоть до «sudo apt-get install это кошмар». Есть подозрение что автор не осилил командную строку, а без неё работать в linux тоскливо.

tinman321

Жирный лойс, товарищ!

fhunter

http://www.terathon.com/forums/viewtopic.php?f=2&t=14050&start=25#p127661

Здесь отписался сам автор.


Re: Version 4.2 Final Now Available

Postby Eric Lengyel » 12 Jan 2015, 20:27
A lot of people seem to think that maintaining the engine code for Linux is what was costly. That’s not the case. The engine ran fine in Linux, and I rarely had any problems with graphics, audio, input, etc., once the engine code became robust on that platform. The problem is Linux itself not working. I cannot afford to spend weeks at a time just trying to install Linux, get it to boot, and get a development environment working. I simply don’t have the funding to justify letting the engine stagnate while I mess around with an OS that should just work. It’s extremely wasteful and unfair to users who are waiting on new features.

Also, I didn’t rage-quit. I’ve been very patient with Linux for over two years, and the latest problems were simply the proverbial «last straw». I struggled very hard with this decision, knowing that it would piss off some people, but ultimately I had to choose what I thought was best for the future of the C4 Engine. I should be working on iOS support, new features like the particle system editor, and performance optimizations, not spending my entire day trying to get a computer to boot up properly, work with the GPU, and remain stable after installing updates.


Вообще, тред интересный. Хотя автор так толком и не отписал «что именно» ему не нравится.

rgo

Процитированное натолкнуло меня на предположение, что автор использует какие-то специфичные инструменты разработки, которые либо сложно, либо невозможно поднять в линуксе, что и вызывает такую реакцию. У меня примерно такую же реакцию вызывает разработка в Windows, где единственный способ получить адекватную командную строку — это что-то типа mingw/cygwin, но оба этих проекта инородны для венды, и создать на их основе окружение для работы схожее с тем, что я имею в linux довольно сложно и требует утомительной возни.
Учтём при этом, что скорее всего он поставил win8 с линуксом в дуалбуте — а я с этим поимел радостей совсем недавно: говорят с использованием UEFI ещё как-то можно, но подружить вендовый загрузчик с линуксовым при legacy загрузке мне не удалось. Правда я не пробовал закатать grub в mbr, очень хотелось оставить там именно вендовый загрузчик, но… Но общий результат печален: загрузка идёт через EasyBoot, который типа запускает свою собственную копию grub. При этом, во-первых, дождаться когда вендовый загрузчик отдаст управление grub не намного проще, чем дождаться загрузки венды — я не знаю, чем именно там загрузчик венды занимается, складывается впечатление, что он загружает венду, после чего выводит загрузочное меню, и после этого устраивает софтовую перезагрузку в grub. Во-вторых, я так и не понял как грубу из easyboot можно подсунуть конфиг-файл, те же что по-умолчанию не работает — то есть мне приходилось каждый раз вгонять команды загрузки в командную строку grub. С grub’ом установленным в дистрибутиве линукса мне так и не удалось подружить вендовый загрузчик: я уж и так и эдак с device-map тыкался — эквипенисуально, grub всё равно не находит свои stage 1.5 и прочие.
Подводя итог: если бы мне пришлось поддерживать порт своей программы для венды, то я бы может быть годик выдержал бы, а потом сказал то же самое что и Ленгйел, мои слова ненависти отличались бы от его лишь заменой Linux на Windows. Точнее не совсем — я бы поплевавшись засунул бы венду в KVM, и запускал бы её в виде линуксового процесса. Он до этого видимо не догадался, или может быть в венде всё не так просто с виртуализацией.

defender

У любой виртуализации все не так просто с GPU… Вон Интелы собирались пропатчить ядро для виртуализации GPU, посмотрим…

rgo

Вроде ж прокидывают в гостевую систему? Или я что-то не так понимаю?

fhunter

Неа, очень всё медленно и жутко. по крайней мере с virtualbox. Правда детально мы не копали за отсутствием времени, может и можно завести чтобы нормально работало…

rgo

Насколько я знаю, можно любую железяку отдать под управление гостевой системе. То есть она напрямую будет рулить железякой, пользуясь своими дровами. Это плюс-минус то же самое, как запуск dosemu из-под рута, с прописанным в конфиге разрешением для dosemu напрямую обращаться к портам ввода-вывода. То же самое, только с меньшим количеством софтовых костылей. И это не должно быть сильно тормознее чем напрямую без виртуализации. Думаю, что не больше 10% замедления выйдет.
Мне просто всё никак не добраться до этих экспериментов: у меня слишком древний проц для аппаратной виртуализации CPU, без неё виртуализация реально тормозит, да и какой-то практической пользы для себя я не вижу, только чистое любопытство движет мною.

defender

Неа, не выйдет. Да, можно заюзать видяшку для вычислений. А вывести изображение как? Весь сыр-бор в том, что надо как-то получить контекст экрана хостовой системы для вывода туда. Да, мы могем быстро посчитать. И что с того?.. Как эффективно обмениваться посчитанной картинкой с хост-системой, чтобы та ее отобразила?..

rgo

Дать доступ к DMA? DMA не такая уж и сложная штука, на него поверх можно одеть софтварную эмуляцию, которая даст гостю интерфейс к железному DMA, причём снимет конфликты между гостем и хостом.

Я не вижу на этом пути каких-то принципиальных проблем.

defender

DMA и видео-память — вещи совсем-совсем разные. В том и дело, что DMA — это программируемый контроллер, который сам выполняет работу. Его надо запрограммировать и подождать результата. А тут — доступ в память. Или вы имели в виду DRM? Небезопасно, поскольку туда могут выполнять запись и другие программы и тд, и тп. И софтверная эмуляция… Она родимая и тормозит процесс. Или это должно быть частью ядра. Или драйвера устройства должны что-то знать о виртуализации как таковой. Что и делают интела в своем патче.

rgo

Доступ к памяти настраивается через mmap. Гостю можно создать произвольную конфигурацию его «физического» адресного пространства. Если прав, конечно, хватит. Но руту хватит без вопросов, при этом, вероятно, не обязательно иметь права рута, достаточно иметь rw права на несколько файликов из /dev (быть может на эти: find /dev -group video). Другие процессы весьма ограничены в плане доступа к АП данного процесса. Требуется ряд соблюдённых условий. Которые легко не соблюсти, сделав невозможным ни для кого получить доступ к этой памяти. Например запустив виртуалку под выделенным под эти цели пользователем.
Ну, а то, что вообще небезопасно давать доступ к железу — это понятно. Но чем это принципиально отличается в плане безопасности от натуральной установки венды, с полным доступом для неё для всего железа? Мне кажется, что имеющиеся отличия — скорее в лучшую сторону отличия, потому что гость будет иметь доступ только туда, куда мы разрешили.

defender

Виртуализация — в первуюочередь это изолирование. Полное. От других процессов, не обязательно иметь в виду доступ к диску, например. И аппаратная поддержка виртуализации на 90 процентов состоит в том, что контроллер памяти знает о существовании гипервизора и гостей. И умеет аппаратно разделять доступ к страницам памяти. В результате чего имеется возможность запустить ядро другой операционки (а ведь ему тоже нужен доступ к 0 кольцу режима работы процессора). А без аппаратной поддержки пользовательская программа следила за этим. В результате что? Переключение контекста в случае доступа к странице памяти, что очень долго. А вы хотите, например, чтобы гость имел доступ к видеопамяти без аппаратного разделения, где вы вводите в браузере данные своей кредитки? В общем, все не так уж и просто. И речь даже не сколько в безопасности, а в том, как разограничить доступ к видеопамяти? Как взять воображаемый мютекс, дабы не попортить иным «писателям/читателям» чего? Без модификации гостевой операционной системы и ее графической подсистемы…
И да. Нельзя физически влазить в память гостя, а уж тем более и гипервизора. Аппаратура против…

rgo
Виртуализация — в первуюочередь это изолирование. Полное.

Вы отстали от жизни. Виртуализация давно гораздо больше, чем «полное изолирование». Правильнее сказать, что весьма гибкое изолирование, позволяющее точно контролировать степень изоляции.

А вы хотите, например, чтобы гость имел доступ к видеопамяти без аппаратного разделения, где вы вводите в браузере данные своей кредитки?

Если я запускаю фуллскрин игрушку, то браузер не обращается к видеопамяти. Ну, точнее теоретически он может. Но так же теоретически, он может не обращаться, так же теоретически эти обращения возможно срезать на уровне Xorg или ниже. Сложнее будет если у меня несколько процессов напрямую пишущих в память… Но я не настолько хорошо знаю как работает графический стек, чтобы говорить возможно ли просто вырезать эти обращения и проигнорировать. Ну, например, повесив всем offscreen процессам флаг ro на страницы видеопамяти, и просто игнорируя все попытки туда писать.

И речь даже не сколько в безопасности, а в том, как разограничить доступ к видеопамяти? Как взять воображаемый мютекс, дабы не попортить иным «писателям/читателям» чего?

Просто не давать им писать и всё. Сделать на каждого гостя по самостоятельному «рабочему столу». Немного поплясать с бубном вокруг операции переключения между рабочими столами.
Переключение контекстов будет происходить тогда, когда я переключаюсь между «рабочими столами» — но этот процесс сильно завязан на мою скорость восприятия информации, и скорость переключения контекстов на этом фоне — ничто.

И… Как бы это сказать… Вот смотрите, вы тут доказываете мне что это невозможно. Зачем? Чего вы хотите добиться? Убедить меня в том, что прокинутая видеокарта будет тормозить? Если да, то мне придётся вас огорчить: выбранный вами подход для достижения вашей цели неработоспособен. Он не может привести вас к цели.

Я объясню почему. Судя по вашим словам вы никогда не делали ничего подобного и даже не пытались. Вы понимаете, что вы можете тут десять трактатов написать о том, почему это будет тормозить, я всё равно выкину все ваши слова в окно? Просто потому, что я знаю, что люди прокидывают видеокарты в гостевую венду, чтобы поиграть в игрушки. В современные игрушки. Может быть конечно у них при этом железо полученное из будущего при помощи машины времени — я не знаю. Но и тем не менее, знание мною самого факта прокидывания видеокарты ради игры приводит к тому, что я присваиваю вероятность >50% тому, что существенных тормозов из-за этого не возникает. И умозрительные умствования имеют весьма низкий приоритет перед фактами. Даже если факты столь неопределённы. Выше я показал это и уже неоднократно: вы умозрительно находите какие-то потенциальные преграды для производительности, я умозрительно же нахожу обходные пути. Мы можем до скончания века заниматься этой мастурбацией не изменив реальность ни на грош. И не изменив ни на грош убеждений друг друга.

Если вы хотите меня переубедить — прокиньте видеокарту. Запустите тесты. Напишите статью о том, что вы делали, как вы делали, как ещё можно было сделать и как вы не делали. Приложите к статье результаты тестирования производительности. Оставьте здесь ссылку на статью. Если вы проделаете всё это, то это может сработать. Может и не сработать — тут я не могу дать гарантий до того, как ознакомлюсь со статьёй, но может и сработать. А тот подход который вы практикуете сейчас заведомо бесперспективен.

defender

О да. Я знаю, что на текущий момент практически все вендоры в своих драйверах пилят возможность этого долбанного Passthrough. Абы драйвер не офигел от того, что не он один рулит железкой. А есть еще какой-то хмырь, пытающийся это сделать.
И уж чего я не буду делать, так это ублажать Вас, уважаемый, доказывая очевидное. Ваши неведомые «люди» сделали то, что судорожно пытаются сделать писатели драйверов для видеокарт, респект им. Да только экспериментальной поддержкой NVIDIA CUDA для подобного разделения люди хвастаются на профильных конференциях — т.е. далеко от обычного пользователя. Я специально порылся в сетке, может я действительно головой бахнулся. И нашел доказательства своим словам. Вы хотите верить себе? Да пожалуйста. Оставлю Вас в Вашей вселенной в покое. И мне хорошо, и Вам не напрягаться.

rgo
Да пожалуйста. Оставлю Вас в Вашей вселенной в покое. И мне хорошо, и Вам не напрягаться.

Вот это правильно.

fhunter

Эта штука у AMD звалась IOMMUv2. аналогичное было и у Intel, но это железная фича.

Diafour

4.2 =))))
Может ему надо было на кикстартере денег насобирать на дополнительного разработчика, шарящего в Linux, а не опускать руки?

Дмитрий Шурупов

Ты можешь всё изменить одним простым письмом! ;-)

fhunter

Если бы он просто отказался от поддержки — я бы его понял. И денег бы дал на kickstarter-е.
Но то как был сделан этот отказ….
Нет, после объяснения позиции (а она была том thread-е, и с ней я могу частично согласиться), я могу понять, и частично согласиться.
Но простить и помогать после этого… Спасибо, не буду точно.