LINUX.ORG.RU
ФорумTalks

Почему иксы надо закопать

 ,


10

6

Как задолбало смотреть на деградантов, агитирующих сидеть на иксах. Для тех, кто хоть немного разбирается в современных GPU - иксы это дикость. Это такое же legacy как терминалы в ядре.

Так получилось, что пока SGI со товарищи занимались ИБД, и надували щеки - вот прям также, как местные ололо, «разбирающиеся в архитектуре иксов», компания микрософт день и ночь думала о том, как сделать графику быстрее. И поэтому майкрософт(а не красноглазые) придумали шейдеры. Поэтому они придумали стандарт на API для ускорения видео. Микрософт а не «опенсорс сообщество» задает направление развития графики.

В невидии, амд и интеле есть подразделения, которые первыми узнают о том, что выйдет новый директХ или новая винда 9. Эти отделы получают список фич, которые будут в винде и бегут к железочникам, чтоб узнать, что есть в железе уже, что будет сделать сложно, а что - дорого по ваттам. После чего начинается перетягивание одеяла между амд, невидией,интелом и микрософтом, где каждая сторона норовит облегчить себе задачу.

А опенсорс идет по остаточному принципу. И главным образом благодарить за это вы должны сраные иксы.

Видите ли, пока микрософт сокращало и упрощало путь от «знаю что рисовать» до железа в линупсе городили, городили, и городили. В седьмой винде приложение создает «адаптер», из него создает «видео-девайс» и настраивает его и начинает скармливать ему GOPы. на выходе оно имеет surfacы, которые можно поставить в очередь «на экран», забрать себе обратно или в текстуру превратить. В ядре только «минипорт» - штука которая умеет готовые пакеты команд скормить в драйвер. Всё. Никаких иксов здесь не задействовано.

То же самое и для 3д: есть api, есть драйвер, есть минипорт. На выходе получаешь surfacы. Их можно поставить в очередь отрисовки(flip queue) откуда их будет подбирать DWM и собирать в окошки.

И то же самое для 2Д. каким надо быть идиотом, чтоб городить всякие XAA/EXA/UXA/XAXAXA вместо того, чтоб дать приложению самому отправлять команды на gpu. Там есть полная поддержка всей графики-2д 3д и видео. тот же интелоGPU можно проинструктировать программой, и он сам будет отдавать команды на blit-функцию, рисовать градиенты, глифы печатать, и кривые малевать.

Вот ровно то же самое делает wayland. он подбирает surfacы из flip queue и собирает их в картинку.

Никакого геморроя с bumblebee и прочими костылями для убогих иксов: surfacы которые видит интегрированное видео - они в памяти. mmapнул памяти, занес ее в GTT интеграшки - есть окно. открыл драйвер мегаgpu, занес в его GTT ту же область. все работает. gpu рисует и блитит, интеграшка под чутким руководством оконного манагера собирает и показывает.

Я думаю, иксмены понимают, что их аргументы «за иксы» - это полный бред. Они отлично понимают, что wayland проще и меньше жрет ресурсов. Они отлично понимают, что рисовать можно и без иксов, и даже удобнее, т.к. нет самодельных проблем с несколькими видяхами. И даже их сетевая прозрачность проигрывает RDP по всем параметрам: флешки звук и даже скорость.

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

☆☆☆

Последнее исправление: CYB3R (всего исправлений: 1)

Ответ на: комментарий от Xenius

В идеале да, но в реальности нужно будет полностью разделить логику и интерфейс и сделать так чтоб приложение могло динамически выбирать интерфейсы.

Причём здесь оконная система?

Тем, что это не ненужности. Хватит уже по третьему кругу повторяться.

Ты так и не обозначил зачем оно нужно... Раз не получается придумать зачем, значит не надо.

Ну знаешь, compiz иногда падает. Я считаю что это очень хорошо, что можно просто подождать пару секунд пока он перезапустится, а не запускать все приложения заново

Откуда инфа, что падение композитора убивает вяленого?! пахнет аццким 4.2

erfea ★★★★★
()
Ответ на: комментарий от Xenius

Весьма сомнительно, всё-таки изначально HTML не для этого придуман.

Я тоже плевался (да и продолжаю плеваться) на web в том виде, в котором он есть. Но сами по себе html5+css3+js (в вакууме, ну или в любой среде без оперы, ie и moz- webkit- костылей) вполне себе хороши для отображения как статического, так и динамического содержимого.

PolarFox ★★★★★
()
Ответ на: комментарий от PolarFox

То kernel panic vfs not syncing. Можно азбукой морзе промигать на клавиатуре.

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

Xenius ★★★★★
()

Что иксы, что тормозной вайленд все говно, мне симпатизирует directfb - но писать на нем говорят ад.

druganddrop-2 ★★
()
Ответ на: комментарий от erfea

Это не оконные менеджеры поверх вейленда, а реализации wayland, засунутые внутрь оконных менеджеров. Weston — не оконный менеджер, а голая реализация wayland, без оконного менеджера.

PolarFox ★★★★★
()
Ответ на: комментарий от PolarFox

он еще из глубокой альфы не выбрался - 3 видео на ютубе и все с дикими тормозами.

druganddrop-2 ★★
()
Ответ на: комментарий от geekless

зачем ты пользуешся чем ты там пользуешся?

давай отдай свои гигобайты оперативы голодающим в африке

а сам пускай эмулятор VAX и сиди в православных UNIX

qulinxao ★★☆
()
Ответ на: комментарий от geekless

Будут отдельно локальные, и отдельно удаленные :) Кому нужна сетевая прозрачность - юзают только по сети, кому не нужна - только локально. Все счастливы.

stevejobs ★★★★☆
()
Ответ на: комментарий от geekless

Почему? Тут возможны аж три варианта. Либо запускаемые в оффлайне приложения на js (+ возможно костыли вроде NaCl), использующие всякие offline storage и прочие фишки из хтмл5 для оффлайна. Второй вариант — локальный вебсервер в каком-либо виде, ну а третий — возможность дёргать html-движок из нативного кода минуя js-прослойку.

Вроде бы в вебоси были реализованы первый и третий методы.

PolarFox ★★★★★
()
Ответ на: комментарий от PolarFox

А если нет монитора или видеопамяти, в которую можно писать ASCII?

Если фреймбуфер есть, пусть буквочки туда рендерит.

geekless ★★
()

И то же самое для 2Д. каким надо быть идиотом, чтоб городить всякие XAA/EXA/UXA/XAXAXA вместо того, чтоб дать приложению самому отправлять команды на gpu.

Я надеюсь, ты понимаешь, что второй вариант более низкоуровневый и привязанный к определенным предположениям о железе. ОК, пишите код на асме, пишите в порты, потому что это эффективно и задействует весь потенциал железа, а весь мир будет пользоваться высокоуровневыми интерфейсами.

И вообще, если что-то появилось на свет раньше тебя, школьник, это еще не повод его обсирать.

annulen ★★★★★
()
Ответ на: комментарий от geekless

речь о том что ты гриш - ах как не эфективно тратятся ресурсы в новомодных технологиях.

здоровее тебя.

qulinxao ★★☆
()
Ответ на: комментарий от geekless

Буковки в графическом режиме рендерить уже на порядок сложнее, чем в видеопамять в текстовом режиме.

Хотя в ядре, где есть драйвера на вибратор, почему бы и не оставить рисовалку буковок.

PolarFox ★★★★★
()
Ответ на: комментарий от carasin

ситуация тут буквально следующая: есть дрова под винду, где игры, видео, все сверкает и ярлык WHQL наклеен.

дрова в принципе делают ровно одну вещь: принимают на вход команды из какого-то стандартного api, посылают буфера с данными и программами для gpu на карту, и ждут ответов.

т.к. строго говоря даже переписывать особо не придется. в амд у блоба основная часть общая для винды и для линукса например. и 90% гемора с линуксодровами - это иксы.

ckotinko ☆☆☆
() автор топика
Ответ на: комментарий от PolarFox

буковки в графическом режиме рисует blitengine. это даже в мануале на intelоHDвидяхи написано

ckotinko ☆☆☆
() автор топика
Ответ на: комментарий от erfea

А оно умеет DRM хотя бы? Он умеет нормальные оконные менеджеры?

DirectFBGL

Он вообще хоть что-то умеет? Я историй успеха про него что-то не нашёл.

В embedded очень широко используется. WM там, естественно, никому не нужны.

annulen ★★★★★
()
Ответ на: комментарий от PolarFox

запускаемые в оффлайне приложения на js (+ возможно костыли вроде NaCl), использующие всякие offline storage и прочие фишки из хтмл5 для оффлайна

Это полный п...

Второй вариант — локальный вебсервер в каком-либо виде, ну а третий — возможность дёргать html-движок из нативного кода минуя js-прослойку.

Я только один православный вариант вижу. Сервер приложений + http-клиент, рисующий морду. Конкретная технология в принципе не важна — будет это html + js или какой-нибудь принципиально новый язык разметки.

Так мы полностью отделяем гуй от приложения. Приложение может быть дома на десктопе, а пользуемся им с андройдофона.

Иначе смысл самой идеи пропадает.

«Всякие offline storage и прочие фишки из хтмл5» тут уметсны только в рамках интерфейса, без переноса в них логики приложения. Т.е. «как gmail».

geekless ★★
()
Ответ на: комментарий от druganddrop-2

directfb - это и есть говно, как оно есть. у них там ажно костыль в виде ядерного модуля. там помоему до сих пор можно послав SIGSTOP приложению которое в модуле ждет чего-то, можно сделать весело всем прогам в округе

ckotinko ☆☆☆
() автор топика
Ответ на: комментарий от PolarFox

Это не оконные менеджеры поверх вейленда, а реализации wayland, засунутые внутрь оконных менеджеров. Weston — не оконный менеджер, а голая реализация wayland, без оконного менеджера.

Хе-хе и правда... уже забыл что у него композитор и есть реализация вяленого сервера ))) В любом случае, это уже оконные менеджеры, пусть они ещё и сервером вяленого являются )) Да и основной-то функционал в либах проекта вяленого лежит, эти приложения лишь его юзают. ЗЫ Вот и ответ нытикам с их сетевой прозрачность. Надо то всего написать оконный менеджер который картинки окон шлёт по сети, вместо . Со стороны удалённой машины, очень мизерный клиент принимает её и гонит в локальный вяленый, ну и там с устройствами ввода общается.

ЗЫ не ты ли говорил (листать вверх влом, тред жирный) что в вяленом с клавиатурой работать приложение самостоятельно должно? Вот на этой картинке под циферкой 1 что-то не сходится.

erfea ★★★★★
()
Ответ на: комментарий от geekless

Надо учесть, что не от всех приложений надо отделять гуй. Если minesweeper может вместе с логикой целиком и полностью быть выполненным локально, почему бы и нет?

PolarFox ★★★★★
()
Ответ на: комментарий от erfea

Я не вижу проблем её реализовать... А какие препядствия на это пути видешь ты?! Что мешает её сделать хатя бы не хуже?!

Если ты не видишь проблемы, это не значит, что её нет. Короче говоря, или давай пруф, что можно или спор бессмысленный пока не сделают. Когда сделают — будем смотреть, а пока не сделали, X.org однозначно лучше.

Xenius ★★★★★
()
Ответ на: комментарий от qulinxao

вообще-то dbus нормальный. там полное решето.

ckotinko ☆☆☆
() автор топика
Ответ на: комментарий от PolarFox

Буковки в графическом режиме рендерить уже на порядок сложнее, чем в видеопамять в текстовом режиме.

Хотя в ядре, где есть драйвера на вибратор, почему бы и не оставить рисовалку буковок.

Ну нам же не ttf туда отбражать задача стоит. Обычные битмапы вкопипастить в буфер вполне простая задача.

geekless ★★
()
Ответ на: комментарий от annulen

В embedded очень широко используется. WM там, естественно, никому не нужны.

Т.е. для десктопа оно не годится, правильно?

erfea ★★★★★
()
Ответ на: комментарий от erfea

С фига ли тогда иксы рендерят в десять раз медленнее чем бэкенд растер в Qt?

Кривизна Qt. Ну и совсем не в десять

annulen ★★★★★
()

Вброшу.

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

Но... ШОК! Сенсация! Иксы - решето и никак не мешают одним окнам рулить жизнью других. Также, известная «фича» SDL - в полноэкранном режиме не реагировать на Alt+Tab и Alt+F4, если только программа сама на это не согласится; т.е. зависон программы лечится только перезапуском иксов, и хорошо ещё если нужная комбинация работает. В итоге безопасность в стиле XWindows - это многозадачность в стиле DOS'а, т.е. не более чем джентельменское соглашение.

Wayland фиксит эту проблему. Люди заботятся о вас; haters gonna hate.

Я уже не говорю о плавности в интерфейса - то, что в Mac OS X решается повышением приоритета процесса, осуществляющего рендеринг, в wayland присутствует от дизайна. Да, понятно, что на сервере wayland и графика наоборот должны иметь пониженный приоритет - ну так wayland это и позволяет вам делать, в т.ч. запуском от пользователя.

Для тех, кто не понял важность плавности для завоевания десктопа: человек - это вам не какая-то там прокладка, он владелец персонального компьютера (да, это капитанство), и он желает, чтобы его действия обрабатывались сразу же. А это значит, что и само приложение, и система должны всё бросать и обрабатывать любое событие ввода, так же, как QNX обрабатывает критические сообщения от ядерных реакторов и начинки самолётов, так же, как сервера подхватывают тысячи запросов в секунду, работая в обход тормознутых select.

quiet_readonly ★★★★
()
Ответ на: комментарий от Reset

более эффективно, так как в отличие от X11 это работает на полудохлых каналах

Есть пруф? Ну вот предположим у меня есть мобильник с GPRS, где ssh с буквами тормозит, будет RDP работать быстрее?

Xenius ★★★★★
()
Ответ на: комментарий от quiet_readonly

пользуйся другим DE ладно?

и не будет проблем смотреть фуллскин(без декораций) в удобном для тебя размере окошке и паралельно ещё чё делать за тем же монитором.

qulinxao ★★☆
()
Ответ на: комментарий от quiet_readonly

Я уже не говорю о плавности в интерфейса - то, что в Mac OS X решается повышением приоритета процесса, осуществляющего рендеринг, в wayland присутствует от дизайна.

Поставь ulatencyd и прекрати баттхертить.

annulen ★★★★★
()
Ответ на: комментарий от Xenius

Короче говоря, или давай пруф

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

А теперь давай ты на те вопросы что я выше у тебя спрашивал! Слабо?! :D слабо...

Когда сделают — будем смотреть, а пока не сделали, X.org однозначно лучше.

То что он не готов, не отменяет недостатков иксов. Соответственно не отменяет нужности замены. А кто лучше, да время покажет (и с этим я не спорю ну ни разу просто). Кто выживет тот и лучше.

erfea ★★★★★
()
Ответ на: комментарий от annulen

>Xt с Motif же не тормозят

/dev/null тоже, говорят, не тормозит… :)

Deleted
()
Ответ на: комментарий от PolarFox

Если minesweeper может вместе с логикой целиком и полностью быть выполненным локально, почему бы и нет?

Да, в этом случае «сервер приложений» вырождается до /usr/share/minesweeper/minesweeper.html. Но если этот minesweeper или тетрис умеет вести статистику игр...

geekless ★★
()
Ответ на: комментарий от Xenius

отключи криптование - обьём данных увеличится ;)

qulinxao ★★☆
()
Ответ на: комментарий от quiet_readonly

Но... ШОК! Сенсация! Иксы - решет

В чем сенсация?

geekless ★★
()

Прямой доступ к GPU давать тоже плохая идея. В итоге в винде мы получаем игры, которые не возможно свернуть (можно, но когда развернёшь она уже не может перерисовать окно), игры, которые не переживают ждущий режим и т. д. Та же игра запущенная в Wine является простым окном. В итоге с ним можно творить что угодно - переключаться на другие виртуальные десктопы, сворачивать, разворачивать, отправлять систему в сон - приложение даже не заметит и будет абсолютно корректно работать.

Это я к чем... да, скорость надо повысить, но оторванность от железа надо сохранить просто потому что иначе мы получаем кучу приложений, которые написаны авторами, которые думают «никакому пользователю не придёт в голову сворачивать нашу убер игру! а уж запускать её на ноутбуке и закрывать крышку тем более!». Нужна абстракция.

KivApple ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.