fix

тьфу, i mean "MSN дотком".

> Нет чтобы в троём собраться и что-то придумать.

Хрен там. NVIDIA SLI недоступна на последних интеловских чипсетах по причине упорства NVIDIA. И ответ Intel последовал. И будет ли лучше от этого это жалкое поделие X

> Приведешь Top5 ограничений, которые таким образом снимаются?

Каким образом? :) Нужно ведь всё-равно как-то передавать команды иксам, то есть надо IPC. Какой бы механизм выбрать... а, я знаю: сокеты!

Предлагайте тоже, не всё же одному отдуваться ;)

> А если впихнуть иксы в ядро, то программа дёргает системный вызов, тот отрабатывает в контексте самой программы и все в ажуре.

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

угу, от чего шли, к тому и вернулись.

cоотв, лучше Х - ПОКА, только Х. надо просто, этот наш, всеобщий, Х - делать лучше ;)

> Вот это уже теплее

Такое ощущение, что ты знаешь правильный ответ... Только не говори, что это сокеты!!!!!!!! :)

> только одна загвоздка: очередь сообщений позволяет отложить контекстное переключение, что выглядит очень привлекательным

А разве пре вызове привилегированного кода ядра происходит переключение контекста??? Там вроде просто повышаются права (типа ring0 :) ), а при возврате права вновь становятся прежними. Так, что это не аргумент, или я тебя не понял...

> cоотв, лучше Х - ПОКА, только Х. надо просто, этот наш, всеобщий, Х - делать лучше ;)

Угу, угу. В win2000 графика летает в linux еле шевелиться... Нет, что-то с нашим всеобщим Х не в порядке...

>> Приведешь Top5 ограничений, которые таким образом снимаются?

> Каким образом? :)

Какие ограничения снимаются за счет отсуствия IPC?

> Нужно ведь всё-равно как-то передавать команды иксам, то есть надо IPC. Какой бы механизм выбрать... а, я знаю: сокеты!

Ты не всё знаешь - X-сервер спроектирован так, что умеет использовать кучу разных IPC, от TCP-сокетов до разделяемой памяти.

Это полноценное переключение, просто при системных вызовах не делается TLB flush, поэтому они быстрее, чем переход с задачи на задачу. Нужно ведь всё равно переключиться на стек ядра и сохранить/восстановить все регистры, сегментные в том числе.

В общем, реально, замкнулись на сокеты опять. Например, можно придраться, что некоторые проги гоняют изображения через сокет, но если лезть из кожи вон и пытаться это соптимизировать, то получится, что сэкономим только пару копирований массива умеренного размера (для больших изображений целесообразно заморочаться с XShm, и люди это делают). Когда качается через сокет, имеем два копирования: в буфер в ядре и из ядра в иксы, а через shared memory - одно копирование. Шиш с маслом, а не оптимизация.

Я вот, когда комп был слабый, заморачивался темой, почему можно окошками пользоваться как ластиком в paint'е - стирать содержимое других окон так, что они перерисовываются только когда перестаёшь окошко-ластик двигать. Разобрался, что дело в порядке переключений между приложениями, иксами и window manager'ом. Но тогда нормального фикса придумать так и не получилось, как бы нет его, окромя костылей. Вот в архивах лежит переписка (картинки из LTT не сохранились): http://lists.freedesktop.org/archives/xorg/2005-September/009770.html

...а теперь, на радость, наступила эра composite, и стало неактуально, потому что с композитом содержимое всех окон в памяти отдельно лежит, а не на общем холсте, и когда одно окно поверх других таскаешь, expose'ы всем подряд не рассылаются.

> Какие ограничения снимаются за счет отсуствия IPC?

Я вообще про денонсацию. Что значит "отсутствие IPC"? Всё равно ведь нужно передавать запросы из одного адресного пространства в другое. Нет смысла перечислять преимущества того, чего нет, верно? Про разделяемую память я в курсе, релакс.

> Это полноценное переключение, просто при системных вызовах не делается TLB flush, поэтому они быстрее, чем переход с задачи на задачу. Нужно ведь всё равно переключиться на стек ядра и сохранить/восстановить все регистры, сегментные в том числе.

Нужно не спорю. Но при сетевой коммуникации происходит значительно больше переключений контекста: программа захотела переслать запрос в Х, происходит системный вызов сетевой подсистемы (2 переключения), далее по истечению кванта времени ядро переключит контекст на Х (1 переключение), далее Х через системный вызов вытащит из сокета запрос (2 переключения) обработает его и пошлет ответ (2 переключения), вытесниться при истечении кванта (1 переключение), далее ещё 2 переключения уйдет на получение программой ответа. Короче, переключений дофига, а если впихнуть Х в ядро то переключений будет всего 2, да и то не полноценных.

Кроме того, я могу предположить, что Х работает в один поток. Если это так, то получается Х не может обработать несколько запросов "одновременно". А в случае с модулем ядра, если минимизировать критические секции, и все это дело по уму синхронизировать, то интерактивность за счет "параллельной" обработки запросов должна повыситься...

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

Наверное так...

ты прикинь, Х работают не только на линаксе (сюрприз!).

> Короче, переключений дофига, а если впихнуть Х в ядро то переключений будет всего 2, да и то не полноценных.

В своем "дофига" ты смешал "полноценные" и "неполноценные" переключения контекста, и не привел никаких цифр для оценки соотношения накладных расходов на переключения с чистыми расходами на выполнение запроса.

> В своем "дофига" ты смешал "полноценные" и "неполноценные" переключения контекста

А посчитать слабо? 2 неполноценных против 8 неполноценных + 2 полноценных, когда работает шедулер и прочая ядерная канитель.

> и не привел никаких цифр для оценки соотношения накладных расходов на переключения с чистыми расходами на выполнение запроса.

Это пожалуй да... Допустим, сколько по времени занимает выполнение системного вызова пересылки данных по сети еще примерно можно оценить, но как замерить сколько времени занимает переключение контекста или выполнение Хом запроса... Уважаемые спецы, как это замерить? Хотя, наверное, это уже кто-то мерил... Можно ссылку?

А вот как быть с многопоточностью? Х может на 4х ядернике в 4 потока рубить? Или когда Х зарядит запрос в видеокарту в ожидании выполнения оного переключиться на обслуживание другого запроса от программы?

> Но при сетевой коммуникации происходит значительно больше переключений контекста

Я думаю, что накладные расходы на собственно переключения не так уж велики. В первую очередь потому что запросы накапливаются в буфер в Xlib, а потом делается XFlush(), и всё это хозяйство за раз уходит к иксам. То есть на одну перерисовку, даже достаточно сложную, этот каскад переключений в большинстве случаев проходит только один раз.

Но, безусловно, вся эта чехарда с переключениями не на пользу... Например, в Quake3 мышка работает с лагом, потому что сообщение о перемещении путешествует через keventd к процессу xorg и от него к процессу quake3, и всё это при загрузке проца квакой 100%. Ручным заданием приоритетов через nice не лечится: то один процесс "вылезет", то другой. В результате, по моим ощущениям, для хардкорных квакеров (да и для других игр наверняка) путь в Linux заказан, они в нём просто не смогут нормально играть. Но это прямого отношения к теме не имеет - так, зарисовка на тему.

> Кроме того, я могу предположить, что Х работает в один поток.

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

> как это замерить?

Я делал через Linux Trace Toolkit - там все переключения разворачиваются в графике на временной шкале. Это, пожалуй, самый удобный способ. По скриншотам на сайте проекта можно заценить: http://www.opersys.com/LTT/screenshots.html

> В первую очередь потому что запросы накапливаются в буфер в Xlib, а потом делается XFlush()

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

> Но это прямого отношения к теме не имеет - так, зарисовка на тему.

Как это не имеет? В ядро, исключительно в ядро!!! Достаточно посмотреть на положительный в этом плане опыт оффтопика. Недостатков у этого подхода почти нет.

> То есть выиграем только если несколько клиентов рисуют одновременно, а это относительно редкая ситуация.

Вот догонит кде висту по количеству анимации, вот тогда посмотрим... :)

Вообще надо посмотреть на сколько Qt злоупотребляет перегонкой в Х уже самостоятельно отрисованных картинок. Кто-нибудь на это смотрел, как там дела обстоят?

а вот и недобыдлопсехолаги подтянулись...

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

p.s. нудк, мало кто сейчас помнит - что оффтопик - начинал с клонировани Х-ов. не только для терминальных серверов. и ничего - написали что-то !! абсолютно неприемлемое для мира UX. но это не значит, что Х-ы не нужно дорабатывать ? без "фанатизма", будем надеяться.

те, Stripped-down X ? как решение ? плюсы по перформансу - будут не столь сильны, как надеются многие(в тч я, в свое время). в любом случае - последние два года(мб и дольше ?)X-ы двигались, в направлениях, обратных, нужным, IMO. в тч - "благодаря" активности компаний, вынесенной в топик и других "спонсоров".

> с кучей очень опасных особенностей. опасных и очень дорогих для дальнейшего развития. и - никуда не ведущих, его.

Например?

>p.s. нудк, мало кто сейчас помнит - что оффтопик - начинал с клонировани Х-ов. не только для терминальных серверов. и ничего - написали что-то !! абсолютно неприемлемое для мира UX.

Это было, во время dos-win9X

>но это не значит, что Х-ы не нужно дорабатывать ?

Если только не добавлять очередной слой абстракции

>без "фанатизма", будем надеяться.

для начала тогда нужно выгнать старых пердунов (приверженцев "сетевой прозрачности" и прочих костылей)

если есть интерес продолжать, то нужно обсуждение перенести отсюда куда-нибудь. Вот сюда что-ли: http://xorg.wikidot.com/start м?

> Например, в Quake3 мышка работает с лагом, потому что сообщение о перемещении путешествует через keventd к процессу xorg и от него к процессу quake3, и всё это при загрузке проца квакой 100%. Ручным заданием приоритетов через nice не лечится

Открой для себя chrt.

> для начала тогда нужно выгнать старых пердунов (приверженцев "сетевой прозрачности" и прочих костылей)

Для начала молодым сосункам нужно понять, что они многого не понимают.

talgunner, не забывайся. Давайте по-людски вести себя. Кстати, хочу напомнить, что молодость стремительно переходит в зрелость, и не менее стремительно - в старость. Молодым остаётся только завидовать.

chrt? что это?

> Для начала молодым сосункам нужно понять, что они многого не понимают.

Если все так в Х хорошо, тогда я никак не могу понять, почему микрософт за пару лет довела графику до вменяемого состояния забив на сетевые рюшечки. В то время как всеобщий Х пилят-пилят, пилят-пилят, пилят-пилят, пилят-пилят, пилят-пилят... ...уже 20 лет пилят и все никак не могут допилить до приличной скорости? Вот как специалист расскажи мне в чем жеж засада???

> chrt? что это?

Исшо один костыль для латания "сетевой прозрачности"? o_O

> Исшо один костыль для латания "сетевой прозрачности"? o_O

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

> если есть интерес продолжать, то нужно обсуждение перенести отсюда куда-нибудь. Вот сюда что-ли: http://xorg.wikidot.com/start м?

Надо сначала у себя сформировать представления по данному вопросу.

> talgunner, не забывайся

Я сознательно ответил человеку в его же тоне.

> Давайте по-людски вести себя.

Давайте.

> хочу напомнить, что молодость стремительно переходит в зрелость, и не менее стремительно - в старость

Я знаю %)

> chrt? что это?

man chrt

CHRT(1) Linux User's Manual CHRT(1)

NAME
chrt - manipulate real-time attributes of a process

SYNOPSIS
chrt [options] [prio] [pid | command [arg]...]

DESCRIPTION
chrt(1) sets or retrieves the real-time scheduling attributes of
an existing PID or runs COMMAND with the given attributes. Both
policy (one of SCHED_FIFO, SCHED_RR, or SCHED_OTHER) and priority
can be set and retrieved.

Если у тебя лаги в обработке прерываний из-за низкого приоритета
keventd, назначь ему приоритет повыше. Хочешь - назначь ему класс
планирования RT.

> chrt - manipulate real-time attributes of a process

Это предложение о потере времени. Я довольно долго экспериментировал с командой "nice", и положительных результатов не получил. Понижение/повышение приоритетов xorg/quake/keventd в любых комбинациях либо не сказывается, либо ухудшает лаг.

>> chrt - manipulate real-time attributes of a process

>Это предложение о потере времени.

Как скажешь.

> Я довольно долго экспериментировал с командой "nice", и положительных результатов не получил.

Ничего удивительного.

> Понижение/повышение приоритетов xorg/quake/keventd

Совсем недавно речь шла о лагах мыши из-за keventd. Такие ситуации решаются переводом keventd в RT. Зачем манипулирвать приоритетом quake, я не понимаю.

Если шире - проблема называется "инверсией приоритетов", и ей страдают все клиент-серверные системы без исключения (если ОС не поддерживает наследования приоритетов)

>> для начала тогда нужно выгнать старых пердунов (приверженцев "сетевой прозрачности" и прочих костылей)

>Для начала молодым сосункам нужно понять, что они многого не понимают.

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

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

Почитай о проекте Berlin, о [KG]GI. Там были реально талантливые ребята, и рабочий код, и куда это пошло? В никуда. Почему? Потому что X показал отличную приспосабливаемость к современным условиям.

> поэтому ваше время вышло, уходите на покой

Ты уже сделал форк X? Взялся за Berlin, GGI, или написал свою оконную систему?

>Потому что X показал отличную приспосабливаемость к современным условиям.

3-я смена акселерации за 3 года - это теперь называется приспосабливаемостью?! А мне кажется, что это именно архитектурные косяки (что есть причина придумывания вещей вроде xcb)

>Ты уже сделал форк X? Взялся за Berlin, GGI, или написал свою оконную систему?

Играю я под виндой :)

2-я смена, конечно

>> Потому что X показал отличную приспосабливаемость к современным условиям.

> 3-я смена акселерации за 3 года - это теперь называется приспосабливаемостью?!

Это называется "Кит Пакард суетится под клиентом".

> А мне кажется, что это именно архитектурные косяки

Во всех системах есть архитектурные косяки. В твоей, еще непридуманной - тоже. А у X есть огромное преимущество - она уже работает.

> (что есть причина придумывания вещей вроде xcb)

Причем тут xcb? O_o

> Играю я под виндой :)

Прикинь, а кое-кто работет под Линуксом, и им нужна сетевая оконная система.

Это два типичных заблуждения. Ими, к сожалению, страдают многие. Первое - "я крут, все дураки", второе - "ничего не надо делать, всё и так хорошо".

/quit

>Во всех системах есть архитектурные косяки.

только некоторые убеждают себя, что без них жизни нет

>А у X есть огромное преимущество - она уже работает.

это не причина для игнорирования недостатков

>Причем тут xcb?

да не при чем, просто очередной костыль

>> Играю я под виндой :)

>Прикинь, а кое-кто работет под Линуксом

Ну да, и я тоже. Но намек вроде не на это был, да?

>и им нужна сетевая оконная система.

Кому это - "им"? Админам, которых 1% от общего числа пользователей? Никогда линукс не станет мейнстримом, пока он равняется на нужды этих админов.

> Это два типичных заблуждения. Ими, к сожалению, страдают многие.

Хорошо, что ты знаешь о них. Фразу "Врач, исцели себя сам" слышал?

> Первое - "я крут, все дураки", второе - "ничего не надо делать, всё и так хорошо".

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

> /quit

Пока.

>> Причем тут xcb?

> да не при чем

ну то есть что такое XCB - ты не знаешь.

>>и им нужна сетевая оконная система.

>Кому это - "им"?

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

> которых 1% от общего числа пользователей?

Давай ты скажешь, кому нужна реакция мышки <5мс, и сколько процентов они составляют?

> Никогда линукс не станет мейнстримом, пока он равняется на нужды этих админов.

Будет равняться на геймеров - тоже не станет.

>ну то есть что такое XCB - ты не знаешь.

X C bindings - костыль, придуманный для того, чтобы скрывать задержки, возникающие при послыке множества запросов т.е. просто обязывающий программиста делать лишние движения, а xcb/xlib - ремикс на уже известную песню

>Я пишу программы, для которых очень удобна сетевая прозрачность X

"программам удобно..." я даже боюсь спросить, что это за программы, но надеюсь, что это пройдет )))

>Давай ты скажешь, кому нужна реакция мышки <5мс, и сколько процентов они составляют?

Как минимум десятая часть всех геймеров (что наверное гораздо больше всех пользователей линукса на данный момент)

>Будет равняться на геймеров - тоже не станет.

Вот из-за подобных умозаключений удовлетворенного абсолютного меньшинства - точно не станет

> десятая часть всех геймеров (что наверное гораздо больше всех пользователей линукса на данный момент)

Ога, и после реализации безлаговой мышки они все валом повалят в Линукс. Ну-ну.

>> Я пишу программы, для которых очень удобна сетевая прозрачность X

> "программам удобно..." я даже боюсь спросить, что это за программы

Боишься представить мои - представь себе школьный терминальный класс.

> но надеюсь, что это пройдет )))

Что страх пройдет? Это тебе виднее.

>>Будет равняться на геймеров - тоже не станет.

>Вот из-за подобных умозаключений удовлетворенного абсолютного меньшинства - точно не станет

А вот здесь - полностью согласен. Я ничего не делаю, потому что меня вполне устраивает текущая ситуация. А вот тебя она вроде как не устраивает, но ты только треплешься на форуме :D

>Ога, и после реализации безлаговой мышки они все валом повалят в Линукс. Ну-ну.

Нет, это будет значить, что игры в линуксе лагать не будут. Это одно из множества условий.

>Боишься представить мои - представь себе школьный терминальный класс.

Да уж, в наше время купить машины без винтов и заставить детишек терпеть сетевые лаги - нужно быть очень суровым и бородатым =)

>Я ничего не делаю, потому что меня вполне устраивает текущая ситуация.

Ну дык, ты ж Ъ-старый пердун =)

>А вот тебя она вроде как не устраивает, но ты только треплешься на форуме :D

Да, не устраивает и поэтому я тут высказываюсь. Но занят я в другой области и прекрасно понимаю, что везде не успею. И треплюсь наравне с тобой :)

> Почитай о проекте Berlin, о [KG]GI.

KGI это только драйвер, окнами оно управлять не умеет, для этого нужно использовать XGGI, что есть всего навсего очередной Х-сервер. Как выяснилось Х с самим железом работает нормально (ioperm, iopl и все такое), так что смысла в этом нет.

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

Berlin а что это? Они что, Х водрузили по верх CORBA?

> В никуда. Почему?

Ну, не мудрено с таким подходом...

> Потому что X показал отличную приспосабливаемость к современным условиям.

Конечно, на фоне всего этого барахла Х оказался лучшим! Поправьте если где ошибся.

А вот теперь покажи мне такую штуку что-бы:

1) основная часть работала в ядре (2д 3д графика, устройства ввода, оконная система)

2) всё что можно было вынесено в userspace библиотеку, работающую в контексте самой программы

3) всё это дело предоставляло Xlib совместимый интерфейс на уровне ABI

4) легкое портирование или вообще полная совместимость драйверов

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

> Ну, не мудрено с таким подходом...

Они сделали хоть что-то.

> Berlin а что это? Они что, Х водрузили по верх CORBA?

Нет. Они избавились от X-протокола в пользу CORBA.

> А вот теперь покажи мне такую штуку что-бы:

> 1) основная часть работала в ядре (2д 3д графика, устройства ввода, оконная система)

Вообще-то после "оконная система" можно не продолжать, но...

> 4) легкое портирование или вообще полная совместимость драйверов

Откуда портирование, с чем совместимость? С вендой? Предлагаешь реализовать Windows-совместимый API для драйверов?

>Предлагаешь реализовать Windows-совместимый API для драйверов?

Верующим ведь не свойственно прогибаться - так зачем спрашиваешь, если заранее знаешь свою реакцию на ответ? Жирненько, вообщем =)