| |
| |
| |
| 4.50, soarin (ok), 12:38, 22/04/2023 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
 В 2022 году стало дефолтное, хотя за исключением Nvidia.
Средний палец ещё нескоро будет - через четыре года.
| | |
|
|
|
| |
| 2.18, User294 (ok), 01:02, 05/11/2008 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
> В общем даёшь уменьшение потребления памяти на 50 мегов и увеличение производительности!!!
А также падения ядра в панику заместо падения иксов?...
P.S. а облегченые иксы и так в природе есть.Хотя для мобильных девайсов по любому лишним не будет.
| | |
|
| |
| 2.19, User294 (ok), 01:10, 05/11/2008 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– | |
>Угу. Опять "глюк в видео драйвере" начнёт класть всю машину сразу. Удобно.
Ну, вообще, нынче видеодрайвера могут довольно основательно положить систему. Скажем атевый драйвер когда-то давно был с забавным глюком - мог заглохнуть и при том - в своем модуле, на уровне ядра.При этом система вроде и не дохнет совсем, но видео отваливается напрочь, половина пользовательских процессов встает колом и работает только аварийное Alt+SysRs+<буква>.Даже в консоль переключиться - фиг.Впрочем, эта байдень пофикшена уже достаточно давно и теперь оно месяцами не грохается =).Но лучше бы в кернеле поменьше дряни такого плана таскалось.
| | |
| |
| 3.43, Sergey (??), 20:16, 06/11/2008 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
 да ничего, и сейчас не менее забавный глюк, правда связанный с тем, что X-Server 1.5 по сию пору не поддерживается драйвером fglrx. При хагрузке консоли все еще ничего, а как только стартуют Х, то сразу черный экран, и все! Ни Х убить, ни в консоль выйти, только ресетом клацнуть, как на венде! Ну или можно удаленно войти, поправить конфиг и перегрузить все.
| | |
|
|
| |
| 2.8, Georges (ok), 22:03, 04/11/2008 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
рассчитано под тех, кто имеет полноценные опенсурс дрова реализующие GEM и Kernel Mode setting (ati intel)
под Nvidia не рассчитано. (разве что реверс инжиниринговый noveau)
зачем рассчитывать под проприетарщиков?
| | |
| 2.9, anonymous (??), 22:04, 04/11/2008 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
>А ничо что речь идет пока что об intel-only? Кто дрова под
>это писать будет? Никто? :)
ну как бы AMD, Intel и VIA уже сейчас имеют открытые дрова, не думаю что сложнго будет их перенести. Если всё будет действительно продумано и грамотно сделано nvidia тоже подтянется
| | |
| 2.39, Аноним (7), 21:33, 05/11/2008 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
>А ничо что речь идет пока что об intel-only? Кто дрова под
>это писать будет? Никто? :)
Ну логично, только у Intel opensource-дрова. Если проект разовьётся и хорошо себя покажет, то nvidia и ati возможно драйвера портируют под него.
| | |
|
| 1.10, crot (?), 22:13, 04/11/2008 [ответить] [﹢﹢﹢] [ · · · ] [↑] [к модератору]
| +/– |
Ну наконец то. Давно пора. X.org стал очень тяжелым и не поваротливым. Может хоть это подтолкнет разработчиков игр делать игры тоже под Linux. Вот бы скорее первый релиз увидеть. На ЛОРЕ вроде писали что Wayland поддерживает nvidia и ati.
| | |
| 1.12, valexey (?), 23:07, 04/11/2008 [ответить] [﹢﹢﹢] [ · · · ] [↓] [к модератору]
| +/– | |
Правильно ли я понимаю, что фактически этот сервер ломает совместимость с X Window System core protocol'ом? Судя по новости, этот новоявленый Х-сервер не будет заниматься отросовкой, а будет принимать от клиентов грубо говоря, только готовые bmp-шки. Т.о. ему уже нельзя будет сказать нарисуй мне линию вот тут, а вот тут полигон. А вот тут текст выведи. (всё это позволяет очень сильно снизить нагрузку на сеть).
Т.о. этот "X-server" на самом деле уже не является X-сервером, является уже чем-то другим. Имеющиеся программы с ним работать не будут (по кр. мере те, которые не только bmp-шки гоняли).
| | |
| |
| 2.15, Аноним (7), 23:24, 04/11/2008 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– | |
Совместимость ломает. Линию рисовать, конечно, можно, но делать это будет не сервер, а тот, кто с ним работает. Любой рендеринг является direct rendering'ом, и все то, что реально рисует придется переписывать (для начала cairo и freetype, со временем, возможно, монстров вроде gtk и qt). Благодаря этому и достигается основная цель сервера - приложение (или тулкит) может контролировать отрисовку, не допуская дефектов изображения в ее процессе; с текущим X-протоколом, гарантирующим только окончательный вид, но не то, что появляется в процессе это сделать непросто. Приходится использовать двойную буферизацию в тулкитах, чтобы X-сервер имел дело только с конечным вариантом изображения, и это все равно не спасает от лагов при перерисовке.
Почти все программы используют тулкиты, никто напрямую через Xlib и Xt не работает - мороки слишком много. А переписать athena, motif, gtk, qt и всякую экзотику - работа, в принципе, реальная.
Нагрузку на сеть.. Ну текст уже давно локально все рендерят. Нагрузка, наверное, возрастет.. Да и сейчас при запуске чего-нибудь на java со swing'ом с удаленной машины по X-протоколу вылезают совершенно немерянные тормоза при работе по небыстрому каналу, с временем реакции в несколько секунд - vnc решает проблему.
| | |
| 2.16, geekkoo (??), 23:40, 04/11/2008 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
>>а будет принимать от клиентов грубо говоря, только готовые bmp-шки. Т.о. ему уже нельзя будет сказать нарисуй мне линию вот тут, а вот тут полигон. А вот тут текст выведи.
Ну, про текст уже выше сказали (freetype рендерит шрифт в клиенте, а на сервер уже пересылается растеризованный глифы). Так и с линиями и полигонами практически тоже самое - каиро ИМХО делает отрисовку в клиенте, на сервер идет уже результат.
Да и если подумать - кому сейчас нужны эти draw-primitives? Любой тулкит сейчас использует шкурки, так что все равно с клиента приходится гнать на сервер картинки. Так что не проще ли не морочить себе голову Х-протоколом, а гнать сразу скриншоты с экрана. Тем более с современными гигабитными сетями разницы слать ли скрины мощным потоком, или время от времени посылать короткие команды по сети особой разницы нет. Может даже первый вариант предпочтительней (на таймаутах больше выигрыш).
| | |
| |
| 3.17, geekkoo (??), 23:45, 04/11/2008 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Ну, и с фритайпом Кейт Паккард на самом деле проводил сравнения со старым ХFont (чисто серверной реализацией). По его измерениям получалось, что разницы практически никакой нет.
| | |
|
|
| 1.13, СуперАноним (?), 23:14, 04/11/2008 [ответить] [﹢﹢﹢] [ · · · ] [↑] [к модератору]
| +/– |
А по мне, так пусть лучше сам X-сервер занимается рендерингом виджетов. Зато окошки, выводимые разными тулкитами будут выглядеть одинаково. Да и траффик при таком подходе должен быть меньше.
| | |
| 1.14, valexey (?), 23:20, 04/11/2008 [ответить] [﹢﹢﹢] [ · · · ] [↓] [к модератору]
| +/– | |
Та-ак... Прочитал по диагонали что это за зверь такой. Так вот -- это НЕ X11-сервер! Т.о. совместимость с имеющимися приложениями нет и не планируется:
"They got the headline wrong, though, it's not a new X server, it's a tiny display server + compositing manager."
Поправьте заголовок новости и содержимое -- иначе вводит читателя в заблуждение.
| | |
| |
| 2.25, Аноним (-), 08:47, 05/11/2008 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
>Поправьте заголовок новости и содержимое -- иначе вводит читателя в заблуждение.
Читай внимательнее. Разработка только началась, сейчас нет X-сервера, но скоро сделают.
| | |
| |
| 3.38, Щекн Итрч (?), 15:45, 05/11/2008 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
>>Поправьте заголовок новости и содержимое -- иначе вводит читателя в заблуждение.
>
>Читай внимательнее. Разработка только началась, сейчас нет X-сервера, но скоро сделают.
Цитатку, плиз.
| | |
|
|
| 1.23, Аноним (7), 03:29, 05/11/2008 [ответить] [﹢﹢﹢] [ · · · ] [↓] [к модератору]
| +/– | |
> Всё необходимое перемещается в ядро
А сколько в своё время было наездов на Windows за такую вот организацию: некрасиво, небезопасно... Спустя пару десятков лет к тому же и пришли
| | |
| |
| 2.26, I (?), 09:02, 05/11/2008 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +/– |
>А сколько в своё время было наездов на Windows за такую вот
>организацию: некрасиво, небезопасно... Спустя пару десятков лет к тому же и
>пришли
Все не так просто. Это другая архитектура.
| | |
| |
| 3.29, Аноним (7), 10:38, 05/11/2008 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
>Все не так просто. Это другая архитектура.
А никто и не утверждал, что в винде и в линуксах будет все одинаково. Имелся ввиду лишь АСПЕКТ под названием "ядерная графика". За эту самую ядерную графику винду сильно ругали, дескать, постоянно будет в БСОДы падать из-за ошибок в этом модуле и т.д. Сейчас в линуксе хотят также перенести часть кода в ядро, и получится схема, очень похожая на применяемую в виндовс. Красивое слово "архитектура" тут не уместно по большому счету, не тот масштаб
| | |
| |
| 4.31, User294 (ok), 11:39, 05/11/2008 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
>очень похожая на применяемую в виндовс.
Говоря об архитектуре - очень интересно, а что будет выступать аналогом win32k.sys? :)
| | |
|
|
| 2.27, Хелагар (ok), 09:44, 05/11/2008 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
>> Всё необходимое перемещается в ядро
>
>А сколько в своё время было наездов на Windows за такую вот
>организацию: некрасиво, небезопасно... Спустя пару десятков лет к тому же и
>пришли
Не к тому же, друже аноним.
Но чтобы понять разницу, надо сделать над собой определённое усилие - внимательно почитать новость. Ну и знать организацию ядра Винды и Никсов (не микроядерных), само собой.
| | |
| |
| 3.28, Аноним (7), 10:27, 05/11/2008 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
>Не к тому же, друже аноним.
>Но чтобы понять разницу, надо сделать над собой определённое усилие - внимательно почитать новость. Ну и знать организацию ядра Винды и Никсов (не микроядерных), само собой.
Ну и где же тут принципиальные различия? В винде есть драйвер режима ядра win32k.sys, который отвечает за отрисовку графики, в то время как аналогичный функционал в *никс-системах находится в юзерспейсе. Сейчас же и в линуксе хотят это перенести в ядро. Точно так же над ядерным модулем находятся различные библиотеки и тулкиты более высокого уровня, находящиеся в юзерспейс. Естественно, сходство не на 100%, но _Принципиальные_ различия назовите? А подчеркивание анонимного статуса собеседника - это первый признак того, что по теме сказать нечего.
| | |
| |
| 4.33, geekkoo (??), 12:20, 05/11/2008 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
>[оверквотинг удален]
>>Но чтобы понять разницу, надо сделать над собой определённое усилие - внимательно почитать новость. Ну и знать организацию ядра Винды и Никсов (не микроядерных), само собой.
>
>Ну и где же тут принципиальные различия? В винде есть драйвер режима
>ядра win32k.sys, который отвечает за отрисовку графики, в то время как
>аналогичный функционал в *никс-системах находится в юзерспейсе. Сейчас же и в
>линуксе хотят это перенести в ядро. Точно так же над ядерным
>модулем находятся различные библиотеки и тулкиты более высокого уровня, находящиеся в
>юзерспейс. Естественно, сходство не на 100%, но _Принципиальные_ различия назовите? А
>подчеркивание анонимного статуса собеседника - это первый признак того, что по
>теме сказать нечего.
Принципиальное различие, что Х (был и остается) - это сетевой протокол с клиент-серверной архитектурой. Никто это не оспаривает, вопрос только какую часть функциональности перенести в клиент, а какую - в сервер. Т.е. если X11 это толстый сервер и тонкий клиент, то Wayland предлагает скорее толстого клиента и тонкого сервера (что непосредственно отражается на размерах исходного кода).
Хотя, конечно же, это моё ИМХО.
Т.е. если кто-то попытается написать книжку про современные Х-ы, то он гарантированно попадет в bestselling authors. "Та самая" книжка про Xlib уже давно устарела, там нет ничего про freetypе, композит, mesa и OpenGL, DRI и AIGLX.
| | |
|
|
|
| 1.30, AsphyX (??), 10:58, 05/11/2008 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| +/– |
Похоже, сбывается моя мечта: выкинуть бОльшую часть графических команд из core protocol'а, поскольку они всё равно уже практически не используются (отрисовка примитивов, глифов, блиттинг и Porter-Duff alpha blending давно уже выполняются через XRender).
| | |
| |
| 2.32, maximnik0 (?), 12:03, 05/11/2008 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +/– |
Боюсь все заглохнет , про фрамбуфер (framebuffer ) надеюсь не забыли - и где эта технология ?
А вeдь для фрамбуфера был написан легкий X сервер .Потом появился dri ....и что то до сипор то починят то поломают .
| | |
| |
| 3.35, geekkoo (??), 13:11, 05/11/2008 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
>>и где эта технология ?
Вот здесь -> http://www.directfb.org/
Т.е. о чём я и говорил -
DirectFB 1.3.0 - first development release with OpenGL based acceleration - 2008-09-29
Фреймбуффер без OpenGL ускорения - мало кому нужен. Сейчас процессоры мощные, так что классические 2D операции их не сильно грузят, композит для затушевывания графики как-то худо бедно реализовали, любители шкурок - сами себе злобные буратины, а вот с 3D косяк ...
Правда, к этому DirectFB сетвая прозрачность прилеплена как с боку бантик ...
| | |
|
| 2.34, geekkoo (??), 12:32, 05/11/2008 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
>Похоже, сбывается моя мечта: выкинуть бОльшую часть графических команд из core protocol'а,
>поскольку они всё равно уже практически не используются (отрисовка примитивов, глифов,
>блиттинг и Porter-Duff alpha blending давно уже выполняются через XRender).
Это может и правильно, только как тогда быть с 3D?
Я (может быть по наивности) полагал, что OpenGL, как бы, хорошо ложится на Х-протокол. Т.е. клиент шлёт себе команды OpenGL, обёрнутые в соответсвующий сетевой пакет, а X-сервер выступает в роли диспетчера - отдельные команды он просто пересылает видео-карте (в отличии от клиента он имеет непосредственный доступ к модулю, управляющему видео-картой), а некоторые отрабатывает на CPU. Может я просто не сильно въехал в архитектуру Х-ов, но я не очень понял, с чем связаны такие сложности с реализацией A(ccelarated)I(ndirect)GLX, которое появилось значительно позднее DRI.
Т.е. мне казалось, что framebuffer (а именно это на мой взгляд пытается реализовать Wayland, пусть и с сетевой прозрачностью) слишком примитивный уровень абстракции, чтобы на нем получить существенное ускорение 3D операций. Или я не прав?
| | |
| |
| 3.36, AsphyX (??), 13:31, 05/11/2008 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
>я не очень понял, с чем связаны такие сложности с реализацией A(ccelarated)I(ndirect)GLX,
>которое появилось значительно позднее DRI.
А с тем, что в течении длительного времени X-сервер не имел доступа к OpenGL, ему просто некуда было слать десериализованные OpenGL-команды. Сервер только создавал некую низкоуровневую подстилку, позволяющую клиенту, через OpenGL обращаться к GPU и фреймбуферу напрямую. От сервера требовалось, если я правильно понимаю, только предоставить информацию, где во фреймбуфере расположено окно, куда выводить, и как отсекать вывод. Остальное делал клиент через DRI.
>Т.е. мне казалось, что framebuffer (а именно это на мой взгляд пытается
>реализовать Wayland, пусть и с сетевой прозрачностью) слишком примитивный уровень
>абстракции, чтобы на нем получить существенное ускорение 3D операций. Или я
>не прав?
См. выше. Если фреймбуфер (вернее, offscreen-буфер, связанный с окном) расположен в памяти видеокарты и доступен GPU, то ничего не мешает нам рисовать в него средствами OpenGL. Главное, корректно этот буфер лочить, чтобы клиент с сервером не поругались. Собственно, как-то так сейчас и делается у Nvidia, в случае включённого композитинга. Ребята из Nvidia просто сделали своего рода эмуляцию AIGLX без "Indirect" составляющей, т.е. рендеринг по-прежнему прямой, но в offscreen-буфер.
| | |
| |
| 4.41, geekkoo (??), 23:32, 05/11/2008 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
Да действительно, я был неправ с этим DRI. Т.е. он представлял из себя костыль, который позволял клиенту напрямую работать с аппаратурой, минуя вообще говоря Xserver. Собственно поэтому им и могли воспользоваться только клиенты работающие на той же машине, где находится видеокарта. ПОявление AIGLX ситуацию несколько выпрямило, поскольку с его появлением OpenGL команды стали проходить через сервер. Т.е. я действительно ошибался, считая, что это уже давно было реализовано.
Но все же сомнительно, что AIGLX (или что-то похожее) будет реализовано в Waуland. Т.е. они оставят DRI для локальных клиентов, коль скоро это все равно реализуется клиентскими библиотеками. Действительно остается только спинлок прицепить к видеобуфферу, чтобы разграничивать доступ между OpenGL клиентами и сервером.
| | |
|
|
|
| 1.40, Дмитрий Ю. Карпов (?), 22:15, 05/11/2008 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| +/– | |
Для работы с терминалом нужен протокол типа HTTP+HTML, когда X-клиент составляет форму, в которой прописано, что он хочет визобразить на экране, а X-сервер сам это отображает.
Идея гонять уже отрисованные картинки совершенно дурная - GPU на терминалах будут простаивать, зато CPU на хосте будет дико загружен отрисовкой.
PS: Для игр нужен будет отдельный протокол работы с экраном, типа DirectX, который не связан с окнамию
| | |
| |
| 2.44, Василий (??), 19:29, 07/11/2008 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
>Для работы с терминалом нужен протокол типа HTTP+HTML, когда X-клиент составляет форму,
>в которой прописано, что он хочет визобразить на экране, а X-сервер
>сам это отображает.
>
>Идея гонять уже отрисованные картинки совершенно дурная - GPU на терминалах будут
>простаивать, зато CPU на хосте будет дико загружен отрисовкой.
>
Это точно. Сервера надо разгружать. Иначе клиенты своей массовостью сделают работу сервера совершенно невозможной. С веб-серверов никто ж не гоняет в сторону броузеров готовые отрендеренные картинки с изображением веб-страницы. Веб-сервера в сторону броузера гонят текст/хтмл, а каждый броузер загружает "рендерингом" хтмл-страницы процессор уже локальной машины.
| | |
|
| 1.42, Lx (?), 00:09, 06/11/2008 [ответить] [﹢﹢﹢] [ · · · ] [↑] [к модератору]
| +/– |
Мдя.. Полное крушение представлений о жизни. А я - наивный - полагал, что xorg очень важная и нужная чать системы... что-то там отрисовывает, ускоряет... а оказывается она тупо выводит на экран, уже готовые картинки. К чему тогда она? Давайте фреймбуфер использовать.
| | |
| 1.45, Света (?), 20:05, 07/11/2008 [ответить] [﹢﹢﹢] [ · · · ] [↓] [к модератору]
| +/– |
Никак не пойму, чем вызвана такая большая любовь к C без ++. Разве не удобнее писать тот же графический сервер на C++? Драйвер действительно можно сделать не в ядре (как в микроядерных ОС), но тут надо оценивать соотношение "требуемая надежность/требуемое быстродействие" (для игр, наверное, важнее второе, для серверов - первое, правда там и графика практически не нужна).
| | |
| |
| 2.46, Taz (?), 00:08, 27/05/2011 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
 > для серверов - первое, правда там и
> графика практически не нужна.
не практически, а не нужна.
| | |
|
|
