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)
Ответ на: комментарий от no-dashi

90% приложений не нужны все эти сюрфейсы, шейдеры и прочие обдроченые тобой идеи. Им достаточно fillrect(), drawpixmap(), line(), drawtext().

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

Видеокарта отправляет на физическое устройство (дисплей) растр, а значит выгоднее иметь синхронный обмен кадрами между приложением (или менеджером, который комбинирует запросы приложений на отрисовку в одну «картинку») и видеокартой/дисплеем. Здесь рисование примитивов становится накладнее и легче обмениваться «готовыми решениями», то есть заранее отрисованными/растеризованными кусочками, которые компонуются в общий растр менеджером отрисовки и передаются драйвером на видеоустройство.

И ещё. Чем «дальше» от приложений находится точка синхронизации графических операций, тем медленнее происходит отрисовка.

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

Видеокарта отправляет на физическое устройство (дисплей) растр, а значит выгоднее иметь синхронный обмен кадрами между приложением (или менеджером, который комбинирует запросы приложений на отрисовку в одну «картинку») и видеокартой/дисплеем.

Узколобые, ограниченные юзеры бытовой техники! Кто вам сказал, что вообще «Видеокарта отправляет на физическое устройство (дисплей) растр» ? А если это векторная видеокарта? Или вообще девайс CGH?

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

Кто вам сказал, что вообще «Видеокарта отправляет на физическое устройство (дисплей) растр» ? А если это векторная видеокарта? Или вообще девайс CGH?

Не видел таких в природе. Значит их не существует. :)

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

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

Фейл номер один. Все эти функции должен прозрачно для приложения брать на себя GPU.

Видеокарта отправляет на физическое устройство (дисплей) растр, а значит выгоднее иметь синхронный обмен кадрами между приложением (или менеджером, который комбинирует запросы приложений на отрисовку в одну «картинку») и видеокартой/дисплеем.

Фейл номер два. Что там делает видеокарта - никого не волнует. Основная задача - оптимизировать (в разумной степени минимизировать и упростить) обмен между приложением и GPU. Для отрисовки текста разумным миниумумом служит пиксмап, а вот для отрисовки кривой, линии или градиента - уже команда. Все эти идеи «обмена кадрами» это бред по сути своей. В случае с обычным приложением единственное, что должно делать приложение, это инструктировать графическую подсистему «начинаю обновление контекста (drawable)» и «контекст обновлен, можешь перерисовывать экранный буфер». И никакого «обмена кадрами».

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

В клиент-серверных системах (коими является взаимодействие приложений и X-сервера, приложений и Windows и т.д.) есть два вида взаимодействия: интерактивный и пакетный.

Интерактивный вид взаимодействия включает в себя синхронный обмен командами между клиентом и сервером: приложение посылает команду и ждёт её выполнения/ответной реакции.

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

Интерактивный вид взаимодействия при длинной цепочке промежуточных трансформаций отдельной команды очень медленный на сериях команд, следующих одна-за-другой, так как тратится время на ожидание ответной реакции на КАЖДУЮ команду.

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

Взаимодействие приложений с графической подсистемой — лишь частный случай клиент-серверного взаимодействия. А вид взаимодействия определяет скорость реакции и отрисовки. Умение компоновать команды отрисовки в очередь и работать с очередями/агрегатами вместо отдельных «векторных» команд отличает развитую графическую подсистему от примитивной.

Но это не значит, что каждое приложение должно заботиться о каждом пикселе своего окна и растеризовать собственные векторные элементы (пиктограммы на кнопках, например) — этим должен заниматься тулкит, а не приложение. А вот как это делает тулкит и должно интересовать разработчиков графической подсистемы, какие возможности должны предоставляться тулкитам со стороны графической подсистемы по задействованию фич видеокарт и т.д. — одного фреймбуфера маловато будет.

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

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

Твоя проблема в том, что ты пытаешься наделить приложение искуственным интелектом. А это ненужно

Приложение не должно в принципе задумываться о том, что и в каком порядке делать. Захотело нарисовать три пиксела - нарисовало три пиксела. Захотело обновить всё - обновило всё. Единственое что от него требуется - уведомление «я начало рисовать» и «я закончило рисовать». Всё остальное должна брать на себя графическая подстсиема. В том числе опциональную конвейеризацию и т.п. - так же, как это происходит с HDD. А вызовы «я начало рисовать» и «я закончило рисовать» - это примерно как барьеры.

Но это не значит, что каждое приложение должно заботиться о каждом пикселе своего окна и растеризовать собственные векторные элементы (пиктограммы на кнопках, например) — этим должен заниматься тулкит

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

no-dashi ★★★★★
()
Ответ на: комментарий от Stanson

А если это векторная видеокарта? Или вообще девайс CGH?

Держите чуточку Алана Купера:

Программисты разделяют присущий математикам взгляд на сложные системы, а потому неудивительно, что они смотрят на вещи не так, как большинство людей. Что я имею в виду? Представьте, что вы подбросили монету 1000000 раз; из них 999999 раз монета упала орлом вверх, и только один раз вверх решкой. Для математика утверждение «монета всегда падает орлом вверх» является ложным. Единственный раз, когда монета упала вверх решкой, опровергает утверждение. Говоря математическим языком, утверждение верно, если оно верно всегда. Этот образ мысли привычен и кажется разумным хомо логикус, поскольку именно так ведут себя компьютеры.

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

синхронный обмен

Я может и путаю но для иксов в замен синхронной xlib написали асинхронный xcb.

Behem0th ★★★★★
()
Ответ на: комментарий от no-dashi

Единственое что от него требуется - уведомление «я начало рисовать» и «я закончило рисовать».

Насколько я помню, в вяленде от них оставили только второе.

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

кстати зря. это должен сообщать драйвер. в винде так.

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