Wayland 0.95.0 released

Вообще у меня есть ощущение, что получится опять как всегда: через задницу. Потому что. Очень. Сильно. Не. Хватает. Разработчиков. Ни на что.

В итоге всё делается «лишь бы работало».

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

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

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

А в чем, кстати, отличие от Xshm в данном случае?

А как работает этот ваш Xshm, если приложение таки отрисовало окно и его теперь надо композитить?

А что, на фряхе wayland нельзя запустить?

Однооконная графическая система?

Видимо, следующей вашей блестящей идеет станет однозадачная ОС.

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

А как работает этот ваш Xshm

Xshm — X shared memory extension. Все в точности так же, как описано тобой: приложение выделяет shared memory buffer, делает в нем что хочет, а потом говорит иксам «картинка лежит вот тут», а не гоняет битмапы по сокету.

ну разве что на voodoo 1-2. где микрухи памяти были физически разные для TMU и пикселилки.

Как и в виде: beginpaint/endpaint, которые уже руководствуются своей логикой и рисуют в нужные offscreen buffers.

а потом говорит иксам «картинка лежит вот тут»

Говорит ЧЕРЕЗ что?

а не гоняет битмапы по сокету.

Какие битмапы по сокету? Ты точно упорот.

Все в точности так же, как описано тобой: приложение выделяет shared memory buffer, делает в нем что хочет, а потом говорит иксам «картинка лежит вот тут», а не гоняет битмапы по сокету.

Ок, у иксов есть картинка. Но в иксах работает композитный WM, а у него нет никаких битмапов. Иксы не могут рисовать сами. Что дальше?

Любое приложение может задать соответствующий хинт для WM.

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

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

У сокета есть один неприятный недостаток: то, что из него приходить, нужно парсить. Если клиент и сервер на одной машине, передавать структуры данных через shmem было бы эффективнее.

Как обычно: все п-расы, а я д'артаньян...

И как ты сообщишь серверу, что ему пора что-то делать?

Какую именно функциональность и какой именно профит от этого?

Поддержку видеокарт.

Точно, я почему то подумал про гораздо больший диапазон карт.

Framebuffer objects (GL_ARB_framebuffer_object) DONE (i965, r300, r600, swrast)

http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt

А оказалось его не проблема поддерживать.

Я просто уточнить DRI или DRI2?

Любое приложение может задать соответствующий хинт для WM.

И что (дубль два)? Вот у меня есть пиджин (для примера). Ты сначала предложил, ололокая и непонятно на что возражая, вырубить ему декорации средствами WM. Ок, вырубил. И как мне теперь поможет то, что «любое приложение может задать соответствующий хинт для WM»? Мне надо перед экраном будет эту мантру прочесть, чтобы у пиджина внезапно декорации появились?

Например, так: передать все инструкции через shmem, а затем послать в сокет команду sync

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

// C современными GPU знаком только на прикладном уровне, т.е. на opengl писал.

Говорит ЧЕРЕЗ что?

Как и вяленое говно — через сокет.

Какие битмапы по сокету? Ты точно упорот.

Деточка, а как по-твоему иксы могут работать по сети? Если Xshm недоступно, то понеслися битмапы по сокету.

Какую именно функциональность и какой именно профит от этого?

Поддержку видеокарт.

Иксы и вяленд уже используют общие драйверы видеокарт, не?

Это по издержкам почти ничем не отличается от «передать что-то более осмысленное вместе с параметрами, а в shmem писать только сырые данные».

Что дальше?

Очевидно, что дальше wayland ничем не отличается в лучшую сторону от иксов. Только иксы уже проверены временем, а вяленд — линакс-онли невнятный костыль.

Для вяленда нужен KMS (он вроде умел работать и поверх иксов, но в таком виде он нафиг никому не нужен).

Деточка, какая нахрен сеть на локальной машине, если ты только рассуждал про прямые вызовы gdi.dll? Перестань бредить.

Вроде нет. Иксы используют свои собственные драйвера для 2Д, вялый использует 3Д драйверы месы.

Framebuffer objects (GL_ARB_framebuffer_object) DONE (i965, r300, r600, swrast)

ограничения - только в случае когда ограничения железа. ну там память разная и/или копировать нельзя.

Бывает так, что работать можно, но с workaroundом. К примеру, на R600 видеокодек выдает текстуру в формате NV12. силами 3д engine её конвертят в RGB и отдают приложению. то её кладет в flip queue и сдает в DWM. почему надо конвертить - не поддерживает видяшка прозрачное использование текстур в NV12.

На практике же с и915 есть только одно ограничение - входные кэши некогеррентны с выходными. Надо их пинать перед подачей картинки обратно на вход.

Я просто уточнить DRI или DRI2?

DRM- сплошь и намертво. его ровесник из utah kernel kit тоже явно был прибит к иксам. DRI - местами покусан. DRI2 - в паре мест.

Иксы используют свои собственные драйвера для 2Д, вялый использует 3Д драйверы месы.

Иксы используют какие-то другие 3Д-драйверы, или ты не считаешь использование 3Д частью иксов?

но с workaroundом

Я по началу подумал что большая часть вообще не сможет работать.

Нет не считаю. Для работы иксов нужен только xf86-video-vesa/intel/ati. xf86-video-vesa/intel/ati ИМХО лишняя сущность. Если нужно еще и 3Д то тогда нужно доставить месу. Вялы же использует сразу драйверы месы для 2д операций.

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

хз.. они настолько разные, что зная как интел работает, в радеоне не разберешься.

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

интелоGPU наиболее близки к нормальным процам. т.е. можно скачать мануал на i915 и почитать. это дедушка современных HD4000. 4 GEM(не тот что в ведре)-процессора, у которых есть особенные инструкции ассемблерные. особенный кэш учитывающий текстуры. буфер для комбинации пикселей - это как кэш но только на запись и его байты могут быть невалидны(т.е. в память не пишутся-у памяти на каждый байт есть отдельная линия write-enable)

в радеонах уже черт ногу сломит. есть командный процессор, у него один набор команд. есть simd-процессоры, которые он может активировать охапками. у них другой набор команд. есть еще блоки текстур, у их тоже может командный проц дергать. в остальном так же - кэш на входе, буфер на выходе, и еще промежуточный и обменный буфера есть. но без internal docs по открытым нихрена не понять.ибо доки писали жопой.

кстати тут вообще доков нет часто. «читайте сорцы там все написано».

Бладж да сколько же во мне неграмотности и опечаток:(

Дайте мне кто нибудь 3ю звезду я хочу редактировать свои посты(

ты не считаешь использование 3Д частью иксов?

Нет не считаю.

(пожимая плечами) тогда конечно.

Для работы иксов нужен только xf86-video-vesa/intel/ati

ИДля работы иксов железо вообще не нужно, доказано Xvfb.

Я не понимаю что конкретно тебе не нравится? Объясни зачем нужно 3Д иксам?

Xvfbx выкинут и заменен на f86-video-fbdev.

При падении иксов (если нормальные ядерные драйвера) прибивается только сессия юзера, при падении Wayland будет умирать вся система сразу, что даже в виртуальную консоль не залогинится?

Я не понимаю что конкретно тебе не нравится?

Идея выноса из иксов кода просто ради выноса кода.

Объясни зачем нужно 3Д иксам?

После того, как ты объяснишь мне принципиальные отличия 3Д и 2Д драйверов.

если сделать некривые DRI, то при падении wayland, иксов и чего угодно будут прекращать двигаться окошки и приходить input до оживления иксов, wayland и чего угодно.

это как я хочу сделать. чтоб в драйвере были нумерованные манагеры окон, и можно было им сдать с flipqueue готовую картинку. получатель упал-waitqueue в ведре вернула «опаньки».

консоль кстати умирала раньше и с иксами. без KMS.

Принципиального отличия сферических 3Д драйверов от 2Д драйверов я тебе не объясню, но про них я и не говорил. Я говорил про конкретную реализацию в линуксе. Для иксов нужен 2д драйвер xf86-video-* с кучей архитектур EXA, XNA, UXA, GLAMUR + к этому 3Д драйвер в месе. Я считаю это все лишним кодом, когда можно использовать только один драйвер месы и для вялого и для OpenGL(3D).

Идея выноса из иксов кода просто ради выноса кода.

Идея выноса кода ради уменьшения количества кода что упростит разработку и поддержание.

Поясни конкретнее что тебе не нравится в моих утверждениях.

Я считаю это все лишним кодом, когда можно использовать только один драйвер месы и для вялого и для OpenGL(3D).

И по каким принципиальным причинам ты не можешь использовать его же вместо 2D-only драйвера иксов?

Поясни конкретнее что тебе не нравится в моих утверждениях.

То, что я никак не могу найти в них смысла.

кривой парсер у тебя :3

И по каким принципиальным причинам ты не можешь использовать его же вместо 2D-only драйвера иксов?

Их нет? Но почему мы тогда имеем xf86-video-* драйверы?

То, что я никак не могу найти в них смысла.

Как и я в твоих, поэтому и прошу пояснить конкретней.

Ну так дороги же :-).

дороги не актуальны же тут
или я просто напрыгался и сейчас туго соображаю :3

И по каким принципиальным причинам ты не можешь использовать его же вместо 2D-only драйвера иксов?

Их нет?

Я их не знаю. Существование Xgl и AIGLX как бы намекают.

Но почему мы тогда имеем xf86-video-* драйверы?

По привычке. Из старых времен.

прошу пояснить конкретней.

Behem0th> Идея выноса кода ради уменьшения количества кода что упростит разработку и поддержание.

Вынос кода ничего не упростит, если код используется только в одном месте (2D-драйверы xf-video-*); улучшить ситуацию может уменьшение количества кода (т.е. OpenGL в качестве для механизма отрисовки), но ты отказался говорить о разнице между 2D и 3D драйверами.