LINUX.ORG.RU

UXA - новая архитектура акселерация для Х

 , , , , xaa,


0

0

XFree86 Acceleration Architecture досталась X.org по наследству от XFree86. В 2005 году на смену XAA пришла EXA, улучшив поддержку XRender. Сейчас Keith Packard, разработчик Intel, анонсировал новую архитектуру акселерации - UMA Acceleration Architecture (UXA). Создание новой архитектуры в первую очередь связано с вынужденным переходом свободного видеодрайвера xf86-video-intel с TTM на GEM. Более подробные детали и причины создания UXA можно подчерпнуть из блога Keith Packard'a - создателя UXA, XRender и многого другого.

UXA родилась, когда Keith Packard был вынужден модифицировать EXA, выкинув очень много лишнего кода и добавив поддержку GEM. Также следует отметить, что Intel собирается удалить поддержку XAA из драйвера в одном из ближайших релизов.

>>> Подробности

★★★★★

Проверено: Shaman007 ()

Ответ на: комментарий от tailgunner

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

Ну почему же? В оффтопике "окна" (windowing and graphics system, как-то так, если точно) в ядро запихнули и не чё все живы-здоровы.

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

Не... я имел в виду портирование, например, nouveau на предложенную мной систему.

SSZB
()
Ответ на: комментарий от tailgunner

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

А смысл? Теже яйца, вид с боку...

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

Идея тоже не плохая :) Гы-гы

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

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

> А смысл? Теже яйца, вид с боку...

CORBA, в отличие от X, умеет работать в рамках одного процесса.

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

> Идея тоже не плохая :) Гы-гы

Это ответ "да, предлагаю"?

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

> CORBA, в отличие от X, умеет работать в рамках одного процесса.

На сколько я зная, при условии, что клиент и сервер находятся в одном процессе. Так? Тогда объясните, как они умудрились распихать единый Х-сервер по целой куче процессов-клиентов? Иначе, мы приходим опят к пониманию IPC, перегонкой туда-сюда толпы байт, тормозам и нагреванию процессором воздуха в комнате!

> Это ответ "да, предлагаю"?

Господин frame тебе уже ответил, цитирую: "Верующим ведь не свойственно прогибаться - так зачем спрашиваешь, если заранее знаешь свою реакцию на ответ?".

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

>> CORBA, в отличие от X, умеет работать в рамках одного процесса.

>На сколько я зная, при условии, что клиент и сервер находятся в одном процессе. Так?

Да.

> Когда объясните, как они умудрились распихать единый Х-сервер по целой куче процессов-клиентов?

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

>> Это ответ "да, предлагаю"?

> Господин frame тебе уже ответил

Тогда я отвечу тебе то же, что и господину frame: ты понял, что ляпнул глупость, вот и славно.

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

> Только они, IIRC, собирались хранить общие данные в разделяемой памяти (а не в ядре).

И на сколько это получиться надёжно? Программ может случайно или умышленно пройтись по разделяемой памяти (а что, адресное пространство то одно) и... win95 будет просто отдыхать. Кроме того если сервер будет работать в процессе клиента, это означает получение процессом прав на доступ к портам, что тоже ни есть Ъ.

А в моем варианте все это контролируется кодом в ядре, и работает быстрее чем IPC.

> Тогда я отвечу тебе то же, что и господину frame: ты понял, что ляпнул глупость, вот и славно.

Это была шутка, а ты этого непонял, вот и плохо... Но, не будем об этом.

SSZB
()
Ответ на: комментарий от anonymous

>> Дошли они до этого или нет - не помню :(

> Тогда я напомню: http://www.fresco.org/docs/refresco/01-corba.txt

Я знаю, что использование CORBA признано ошибкой, и вообще они наделали много ошибок ("And now I think that exposing scene graph over CORBA was a mistake :)" (с) N.Smith).

> Our project has been renamed Fresco from the old "Berlin"

По-моему, от смерти это не спасло...

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

> Это была шутка, а ты этого непонял

То есть про перенос драйверов ты пошутил. Про оконную систему в ядре - тоже, надеюсь, шутка? Тогда что в твоих 4-х пунктах серьезно? :D

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

> Я знаю, что использование CORBA признано ошибкой, и вообще они наделали много ошибок

Вот видишь сам ляпнул сам себя опроверг. :D

> Про оконную систему в ядре - тоже, надеюсь, шутка?

Я аппсолютно серьёзно! Обоснуй что в этом плохого. В оффтопике работает это на ура.

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

>> Я знаю, что использование CORBA признано ошибкой, и вообще они наделали много ошибок

> Вот видишь сам ляпнул сам себя опроверг. :D

Не приведешь ли мне мою фразу, которую я опроверг?

>> Про оконную систему в ядре - тоже, надеюсь, шутка?

>Я аппсолютно серьёзно!

Жаль.

> Обоснуй что в этом плохого.

Слова layering violation тебе знакомы? И, учитывая это, _ты_ должен обосновать, чем оконная система в ядре лучше оной в юзерспейсе. То есть - цифры, а не прожекты.

> В оффтопике работает это на ура.

Это можно заставить работать, не вопрос. Вопрос - зачем? В Windows7 оконную систему из ядра вынесут, дальше что?

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

> Не приведешь ли мне мою фразу, которую я опроверг?

Так легко... Цитирую "... Почему? Потому что X показал отличную приспосабливаемость к современным условиям." т.е. получается что Х сейчас широко используется не потому, что "показал отличную приспосабливаемость", а потому что все остальное (Berlin) редкостное УГ, и просто на сегодня нет альтернативы. Но нет оснований полагать, что нельзя сделать лучше...

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

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

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

Такое объяснение устроит?

SSZB
()
Ответ на: комментарий от tailgunner

Ха-ха-ха! 8-D

>Ты не беспокойся о вере, ты на прямой вопрос прямо ответь - откуда будут переноситься драйверы и с чем они должны быть совместимо?

Ну, к примеру, драйверы будут переноситься с винды в линукс и наоборот, в пределах одной аппаратной платформы/разрядности ОС

>Никто тебя за язык не тянул.

Это ж ты здесь мастер троллинга и я на это как бы намекнул...

>Ну то есть ты сам понял, что ляпнул глупость? Вот и славненько.

...но до тебя не дошло =D

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

> Цитирую "... Почему? Потому что X показал отличную приспосабливаемость к современным условиям." т.е. получается что Х сейчас широко используется не потому, что "показал отличную приспосабливаемость", а потому что все остальное (Berlin) редкостное УГ, и просто на сегодня нет альтернативы.

Странный вывод. Имелась в виду простая вещь: если бы X не приспосабливался к изменяющимся условиям, он бы просто канул в Лету, потому что претендентов на трон хватало. Но X остался, потому что его было проще доработать, чем разработать заново что-то лучшее.

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

Ты что, ты правда считаешь, что главная проблема X - лаги? И приведешь ли хоть какие-нибудь цифры? А то оптимизируешь что-то, что еще не мерял, причем насчет результата ясно одно - он не будет обладать свойством сетевой прозрачности.

В общем, куча работы - очевидна, куча выигрышей - не очевидна. И не надо про венду, в ней куча неудачных технических решений.

> Такое объяснение устроит?

Нет. Как минимум, потому что не рассмотрен выход 3 - сделать нормальное наследование приоритетов (если лаги жить не дают).

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

>> Ты не беспокойся о вере, ты на прямой вопрос прямо ответь - откуда будут переноситься драйверы и с чем они должны быть совместимо?

> Ну, к примеру, драйверы будут переноситься с винды в линукс и наоборот, в пределах одной аппаратной платформы/разрядности ОС

Как? Опиши процедуру переноса ядерного драйвера венды на Линукс.

>>Никто тебя за язык не тянул.

>Это ж ты здесь мастер троллинга и я на это как бы намекнул...

"If you can't stand the heat, get out of kitchen" (c)

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

> Странный вывод.

Нормальный вывод. Вот именно что "претендентов на трон" нету, по крайне мере сейчас... Все что ты привел в качестве альтернативы либо УГ (Berlin), либо предназначены для другого (GGI), либо теже "Иксы" вид сбоку (KGI+XGGI). Где "претенденты на трон"? Вот и приходиться пользовать то, что есть.

> если бы X не приспосабливался к изменяющимся условиям, он бы просто канул в Лету

Доооо, мы видим как он приспосабливается, все новые и новые костыли. Скоро он перевалит за 2 млн. строк кода.

> Ты что, ты правда считаешь, что главная проблема X - лаги?

Не только... А вообще интересно услышать твоё мнение по поводу проблем Х. "Оглассите вессь списск, пожалусста" (с)

> он не будет обладать свойством сетевой прозрачности.

99% пользователей заплатят эту плату за кучу выигрышей ...

> куча выигрышей - не очевидна.

Над этим я работаю... работаю... прямо сдесь и сейчас. :)))

> Нет. Как минимум, потому что не рассмотрен выход 3 - сделать нормальное наследование приоритетов (если лаги жить не дают).

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

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

> Все что ты привел в качестве альтернативы либо УГ (Berlin), либо предназначены для другого (GGI), либо теже "Иксы" вид сбоку (KGI+XGGI)

Berlin ты назовешь УГ, когда сам напишешь хоть что-нибудь подобное. KGI - это то, чтем X является сейчас, когда драйверы графики отчасти находятся в ядре, а DRM уже давно весь там.

>> он не будет обладать свойством сетевой прозрачности.

> 99% пользователей заплатят эту плату за кучу выигрышей ...

Ну ты перечисли эту кучу, перечисли.

>> Нет. Как минимум, потому что не рассмотрен выход 3 - сделать нормальное наследование приоритетов (если лаги жить не дают).

>А что для этого надо поменять? Код ядра?

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

> Боже упаси, менять поведение ядра.

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

> Х будут работать нормально, зато в соседней ветке будут изобретать "новую архитектуру ускорения вывода звука". :D Копчиком чую где-нибудь обязательно вылезет какая-нибудь лажа от таких нововведений.

В этом перевод управления окнами в ядро ничего не изменит, так что даже непонятно, к чему ты это.

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

Уххх заколебался я чесслово буковки набирать... Пойду лучше что-нибудь полезное сделаю что ли... :) Только 2 вопроса:

1) Я вижу ты профессионал (я серьёзно!), тогда объясни мне почему графика в проклятом виндоусе 2000 (да и ХП тоже) летает как ошпаренная, а линуксе раздражающие тормоза перерисовки когда разворачиваешь окно, переключаешься с одного развернутого на весь экран окна на другое, когда при ресайзинге содержимое окна перерисовывается значительно медленней чем меняется размер оного и тд. и тп??? Можно это замаскировать эффектами аля Виста, но как выяснилось, они ещё больше раздражают...

2) Как сделать, что бы было быстро как виндоусе?

SSZB
()
Ответ на: комментарий от madcore

> Сменить vesa-драйвер на соответствующий.

Так уже, всё равно тормозит. Пробовал от nvidia и nouveau, с последнем тормозит меньше, но всё же не совсем то...

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

> объясни мне почему графика в проклятом виндоусе 2000 (да и ХП тоже) летает как ошпаренная,

Недавно пришлось посидеть за вендовой тачкой, там можно было окном как ластиком пользоваться - быстро таскаешь окно по экрану, и другие окна не успевают перерисовываться. Сейчас смеха ради попробовал на Линуксе - всё успевает.

> а линуксе раздражающие тормоза перерисовки

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

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

> Недавно пришлось посидеть за вендовой тачкой, там можно было окном как ластиком пользоваться - быстро таскаешь окно по экрану, и другие окна не успевают перерисовываться. Сейчас смеха ради попробовал на Линуксе - всё успевает.

Хммм... Вот сижу сейчас под ХП (это у меня торрент/емул качалка, лень ставить линукс, работает и фиг с ней). Учитывая реальную не хватку оперативки графика просто летает. Нет никакого "пластика".

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

> Вот сижу сейчас под ХП [...] Нет никакого "пластика".

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

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

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

Эхххх, видать не судьба мне в линуксе с быстрым гуи поработать...

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

Нда, судьба - фактор немаловажный :-D

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