А разработчики вяленого-то тупые, и не слышали про вулкан.

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

как сделать святую толстоту?

Что, никто не знает как сделать толстоту святой??

т.к. завязан чуть более чем полностью на OpenGL API

Шта?

Ссылку на место в спецификации, где об этом написано, в студию!

" а вдоль дороги ... мертвые с косами стоят.. и тишина" Wayland будет очень долго умирать. Там много чего понаписано но это опять же на воде вилами... и в 2-3 раза производительность выше на некоторых приложениях. И в принципе чему удивляться. Чем ниже уровень тем выше производительность и сильнее привязка к железу. Пишем на ассемблере все и имеем ураганную скорость.У меня в свое время загрузчик на PDP-1170 вообще ни чего не весил и вводился с пульта набором байтовых команд.

Удваиваю этого. Эпичный тред, подписываюсь.

наверно имелось введу egl

прирост производительности у которого в 2-3 раза выше

Если проблема только в этом то пофиг, это же не игрушка.

когда мы в реальности увидим работающие Gtk/Qt

Разве оно не уже работает?

морально устаревает уже сейчас

И поэтому предлагается... остаться на супер-современных иксах? :) Впрочем, меня это устраивает.

Ссылку на место в спецификации, где об этом написано, в студию!

А што, он, принципиально, через что-то другое умеет отрисовывать? Может через вендовый dx? ))

завязан чуть более чем полностью на OpenGL API

Это, пардон, в каком месте? О_О

А што, он, принципиально, через что-то другое умеет отрисовывать? Может через вендовый dx? ))

Wayland это вообще протокол, он по определению не «умеет» ничего рисовать.

Ссылку на место в спеках можно не ждать, да?

Если проблема только в этом то пофиг, это же не игрушка.

Угу, вот только сегодня и игрушки, и гном/кеды рисуют через одно и тоже место. Завтра будет тоже самое, ибо тебе же захочется крутить кубы на твоём супер-пупер 4к )

Разве оно не уже работает?

Ога, тото мы видим как во все поля гномы/кеды на этом вейланде работают и прям релиз за релизом идут без оговорок типа «только для предпросмотра».

Да наблюдая за потугами вейланда/разрабами DE последнии пару-тройку лет у меня всё больше создаётся впечатление что канониклсы свой мир быстрее допилят, чем эта студота своё домашнее задание сделает :)

Ссылку на место в спеках можно не ждать, да?

Не, не стоит. На тупняк фанбоев вейландов/поттерингов с ЛОРа в гугл не набегаешься.

немного жира

http://wayland.freedesktop.org/docs/html/ch03.html

Hardware Enabling for Wayland

Typically, hardware enabling includes modesetting/display and EGL/GLES2. On top of that Wayland needs a way to share buffers efficiently between processes. There are two sides to that, the client side and the server side.

On the client side we've defined a Wayland EGL platform. In the EGL model, that consists of the native types (EGLNativeDisplayType, EGLNativeWindowType and EGLNativePixmapType) and a way to create those types. In other words, it's the glue code that binds the EGL stack and its buffer sharing mechanism to the generic Wayland API. The EGL stack is expected to provide an implementation of the Wayland EGL platform. The full API is in the wayland-egl.h header. The open source implementation in the mesa EGL stack is in wayland-egl.c and platform_wayland.c.

Да это давно очевидно было. И мир там же, в братской могиле.

Иксами едины.

А што, он, принципиально, через что-то другое умеет отрисовывать?

Да. Например, в weston есть software renderer: http://www.phoronix.com/scan.php?page=news_item&px=MTI2Nzg

а зачем читать тёрки «людей разбирающихся»?

тут уже и Петре Пяточкину видно одно большое и тёмное отверстие и оттуда торчат ноги Х11.

Ссылку на место в спеках можно не ждать, да?

Не, не стоит.

Да ты охренел, толстячок :D

Да. Например, в weston есть software renderer: http://www.phoronix.com/scan.php?page=news_item&px=MTI2Nzg

Оно не юзабельно чуть более, чем полностью, если у тебя машина по спекам не соответствует машине Кармака канеш.

Да ты охренел, толстячок :D

Да ему вона выше принесли уже, пусть покушает.

Не стану спорить насчет производительности pixman renderer (потому что сам его не тыкал), но само наличие такой штуки наглядно демонстрирует то, что принципиальной завязки на рендеринг исключительно через opengl нет. Вместо gl renderer может появиться vulkan renderer, или что там еще из rendering api в будущем появится.

FIXED: Графика на Линуксе уже умерла, не успев родиться

The EGL stack is expected to provide an implementation of the Wayland EGL platform. The full API is in the wayland-egl.h header.

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

Это поддержка <...>

Он в курсе. Там же написано: «немного жира».

Он в курсе. Там же написано: «немного жира».

А, видимо не так понял фразу. Тогда ладно.

канониклсы свой мир быстрее допилят

«Mir, like Wayland, is built on EGL» (с) википедия.

Оттуда же: In September 2013, an Intel developer removed XMir support from their video driver and wrote «We do not condone or support Canonical in the course of action they have chosen, and will not carry XMir patches upstream»

«только для предпросмотра»

Ну хоть признаёшь что оно работает. А то всё «запускает одну панельку и два терминала».

эта студота своё домашнее задание сделает

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

Меня вот беспокоит потенциальный бардак среди композиторов. По причинам безопасности (что конечно дело хорошее, но все же) некоторые вещи не стандартизированы или попросту невозможны. Управление окнами через внешние утилиты, снятие скриншотов и запись скринкастов, опять же через внешние утилиты - низзя. Все это должно реализовываться в композиторе, как разработчики композитора решат. EWMH говорят тоже не сразу родился и был бардак, вот тут нас ожидает то же самое.

Не стану спорить насчет производительности pixman renderer (потому что сам его не тыкал), но само наличие такой штуки наглядно демонстрирует то, что принципиальной завязки на рендеринг исключительно через opengl нет. Вместо gl renderer может появиться vulkan renderer, или что там еще из rendering api в будущем появится.

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

Так собственно вся соль треда как раз в том, что эти телодвижения по сути бесполезны (это не моя точка зрения. Мне производительности Иксов+интеловского железо с головой хватает. Чего там вейланд мне «наулучшает» - я даже не замечу). Там собственно весь шум пошёл от того, почему вейланд не готово к продакшену. Вейландцы отвечают: у нас всё готово, весь спрос с гтк/куте-писателей. В тред подтянулись эти самые писатели и накидали им пачку косяков вейланда (и первое по треду - аналог иксового PRIMARY буфера, который я, к слово, активно юзаю).

Общем мораль в том, что когда с вейландом всё станет ЗБС придёт время всё опять глобально переписывать и начнётся очередная поргнография и садом. И, насколько я понимаю, проблема не в програмистах, они есть. Проблема в толковых архитекторах. Тех, кто, к примеру создавал теже иксы, которые прослужили не один десяток лет и продалжают служить. И, к слову, это проблема не одного вейланда. Это проблема всех крупных опенсурс проектов: systemd (куда идём?), гном/кде (всё бросить и переписать с нуля). То есть пейсатели-то есть, а вот толковых людей, которые бы направляли всё это в верном направлении по пути не распыляя в два раза больше усилий на фейлы и «ненужно» - маловато. Такие дела, поэтому имеем то, что имеем :)

EWMH говорят тоже не сразу родился и был бардак, вот тут нас ожидает то же самое.

Да нас вечный бардак ожидает. Пока не придёт человек, не треснет по столу, не покажет паре корпораций фак, не поорёт время от времени матом на кодеров. Ибо 95% процентов человечества, как известно, идиоты, которыми нужно управлять. Так что либо Линус/Путин, либо Поттеринг и всё говно с ним и его «творчеством» связанное ))

выхода Vulkan'a

он еще толком не вышел, и поддерживают эго дай ктулху половина геймерских ПК, а сколько еще негеймерских, вулкану до мейнстрима очень далеко.

Не завязан он на OpenGL. OpenGL - один из бекендов у weston.

либо Поттеринг и всё говно с ним и его «творчеством» связанное ))

Я знаю, что не стоит вскрывать эту тему, но выходит, что Поттеринг у нас как Путин. В стиле «кто, если не он». Жопа какая-то. На все сообщество один человек с харизмой и влиянием, но без мозгов напрочь.

Да без разницы, по большому счёту, если всё работает через EGL, который и есть прослойка ко всем этим GL https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#/media/File:W...

То есть ситуация даже ещё хуже.

Нет, это Линус, как Путин. А Поттеринг - просто говно :)

но без мозгов напрочь.

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

На тупняк фанбоев вейландов/поттерингов с ЛОРа в гугл не набегаешься.

Ведь насрать проще, чем свои слова подтверждать.

А устаревает он по причине выхода Vulkan'a.

В этот момент хотелось бы особенно узнать, каким образом это происходит, при условии, что Wayland принципиально не содержит в себе функций рисования?

Или вас смущает эталонная реализация Weston? так в нём всё в порядке, учитывая, что его задачи лишь правильно отрисовать прямоугольные области, к небольшому файлику gl-renderer.c добавляется файлик чуть побольше, vk-renderer.c и на этом всё кончается.

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

Гномеры, емнип, добавляли поддержку software rendering через драйвер llvmpipe, что есть программная эмуляция OpenGL. Pixman-бэкенд weston'а же не имеет к эмуляции opengl никакого отношения, там, если ничего сильно не путаю, все сводится к созданию композиции рабочего стола из нескольких буферов посредством программного блендинга. И судить о тормознутости software rendering в weston по тормознутости software rendering в gnome-shell - как минимум неправильно.

когда мы в реальности увидим работающие Gtk/Qt/... DE и приложения на вейланде, а этого видимо следует ожидать лишь года через три (я имею в виду *РЕАЛЬНО РАБОТАЮЩИЕ* DE, а не менеджер сеансов, который запускает одну панельку и два терминала

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

Wayland - это тупо протокол. А композитор может использовать что угодно. Добавят в композитор тот же вулкан и всё.

выхода Vulkan'a

И чо? Ну, добавят в kwin, mutter, weston поддержку vulkan, Wayland тут причем? Weston это просто WM, использующий вяленд.

А сам вулкан никому не нужен будет. Игрульки будут на D3D12.

Wayland это протокол. Уверен что приделать еще один бэкенд к нему, наравне с wayland_egl.so, никакого труда не составит. Будет просто рядом wayland_vulkan.so.

Пол-жизненного цикла обеспечивали совместимость с X-ами, вторую половину будут впиливать вулкан.

ТС глуп и толст.

Почитал дискуссию по ссылке. Я понял примерно так:

ТС сообщил о скором внедрении vulkan, о том, что вулкан оперирует command buffers, так же, как это делает сейчас chrome, и что всем всё срочно надо переделывать на command buffers. В течении всего треда у него пытались узнать зачем, пока не узнали.

К как таковому OpenGl (ES) и EGL это отношения не имеет. Принципиальный вопрос в том, что сейчас wayland предоставляет приложению буферы (wl_subsurface), в которые приложение отрисовывает как хочет. ТС предложил wayland'у выделять command buffers, куда приложение будет складывать команды для GPU, а композитор добавлять туда команды для композитинга, и как-то это всё синхронизировать и разделять между приложениями. Возможно тут я ошибаюсь, это я так понял.

На это предложение ТС'у сообщили, что возникнет куча проблем:

• Повышаются задержки работы композитора, приходится гонять кучу комманд через композитор, причём игры часто отрисовывают кадр в несколько заходов, используя несколько command buffers, которые должны быть переданы серверу. А сейчас в худшем случае надо копировать буфер по DMA.
• Придётся копировать отрендеренное через command buffers в случае с гибридной графикой, когда приложение захочет отрендерится на дискретке, а вывести надо через встройку.
• Приложению придётся самому управлять памятью, т.к. может возникнуть ситуация, когда приложение сделает unmap в то время, пока шейдеры ещё обрабатывают эту память. И, как минимум, когда адрес прописан напрямую в шейдере (embed literal memory addresses inside shaders, что не рекомендовано, но бывает), не может отслеживаться ядром.
• Проблема с безопасностью, ибо смешивать все приложения в одном GPU-контексте не безопасно.
• В крайней степени не очевидно, какой профит это даст. ТС сказал так сделано в хроме, и в общем-то всё.

когда мы в реальности увидим работающие Gtk/Qt/... DE

у Qt внутре вообще GL2.0. Qt умер!

ТС предложил wayland'у выделять command buffers, куда приложение будет складывать команды для GPU, а композитор добавлять туда команды для композитинга

Короче, ТС просто ололошка с горящими глазами, увидевший как что-то зачем-то сделано в хроме, и решивший что вот он, священный грааль. А потом пришли аналитики с ЛОРа, увидели много сложных слов и тоже поняли.

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

То есть, когда мы в реальности увидим работающие Gtk/Qt/... DE и приложения на вейланде, а этого видимо следует ожидать лишь года через три (я имею в виду *РЕАЛЬНО РАБОТАЮЩИЕ* DE, а не менеджер сеансов, который запускает одну панельку и два терминала исключительно на железе/драйверах от интела) - это будет прошлый век

Они есть уже сейчас. GNOME Shell поддерживает Wayland не на словах, а на деле. А в следующей версии там будет ещё больше Wayland. И прогнозы насчёт его запиливания по умолчанию не 2-3 года, а уже лишь 1 год. 2-3 года будет лениво перетекать лишь Java, игры из Steam, и прочая лабудень.

И где твой Vulkan? В сети нет не то что спецификаций API, нет его реально рабочих, используемых всеми реализаций(тем более швабодных дров). Слишком он сильно распиарен для того, что ещё даже не родилось.

так как будет нужен новый фреймворк, завязанный уже на апи вулкана. И тут, ВНЕЗАПНО, схватив ноги в руки, мы в ускоренном темпе начнём переход на... на вейланд 2.0 :)

В вяленом напишут протоколы для Vulkan. В GTK/Qt/Whatever напишут всякие там бэкенды для Vulkan. Всё, переход на Vulkan готов.