The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Проблемы X11 и их решения в Wayland "
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Заметили полезную информацию ? Пожалуйста добавьте в FAQ на WIKI.
. "Проблемы X11 и их решения в Wayland " –1 +/
Сообщение от Аноним (-), 13-Июн-13, 17:56 
> поставить realtime приоритет.

Тогда будет интереснее. Но это может только привилегированный пользователь и это должен быть отдельный явный выстрел в пятку. Иксы же никаких привилегий и приоритетов не предусматривают, в отличие от возможности завалить их запросами которые выполняются медленно. После чего "whole shebang hangs".

> например такая - вполне завесила (проверялось в FC6 в VmWare):

Обратите внимание,
1) Вам потребовалось очень явно возжелать прострелить себе пятку нестандартным маневром.
2) Уж не знаю как там в FC6, а в современных линях выставление реалтаймного приоритета требует рутовых прав. Рут может убить систему массой иных, более интересных способов.

Проблема в том что в моем случае непривилегированный пользователь (я еще не упал запускать софт для рисования карт под рутом) может вызвать нехилый клинч графики, по сути сорвав нормальное использование ОС.

> причем даже при всё той-же вытесняющей многозадачности.

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

> ну так Вы вроде сказали, что да, у Вас X-ы тормозили, но не упали,

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

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

Я прямо даже боюсь себе представить, что будет если программа начнет генерить медленные операции Xов оптом на многоюзеровском серваке в злонамеренном стиле, как вы в вашей программе. Подозреваю что N юзеров радостно курнут бамбук.

> в том числе и с X-ами. X-ы тоже не отказали, да - тормозили жестоко,

Они
1) Тормозили в виде при котором системой пользоваться проблематично.
2) Это состояние было вызвано непривилегированным пользователем.

Чего ради непривилегированный юзер должен мочь так сделать - мне вообще не очевидно. Это криво.

> даже продолжает работать - прерывания обрабатывает и т.д. но весь userspace - стоит).

Только если написать его злонамеренно и пустить с рутовыми правами. Иначе реалтайм приоритет просто не дадут. А рут может убить систему и массой иных способов.

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

GPU это расскажите, где вычислительных ядер - немеряно. И нвидия вон что-то пилит threading в своем драйвере для улучшения производительности. И чего это они все?

> вон в том-же DirectX говорят та-же проблема,

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

> у Вас в данном случае третья координата всегда 0, чем это сложнее?

Тем что как минимум 3 координаты вместо 2. Это потенциально увеличивает объем вычислений.
Кроме того,
программа -> X -> DDX driver -> DRI
и
программа -> Mesa -> DRI

в конечном итоге сбагривают запросы одной и той же подсистеме - DRI, которое и пихает все операции в видеокарту. Поэтому можно просто сравнить как эффективнее. И то что работа с 2D через GL получается лучше, хоть оно и не для того - это вообще эпикфэйл иксов.

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

Вот поэтому я за то чтобы обработчик был простым, тупым и быстрым. Способным работать с физическими лимитами железа - полной частотой рефреша монитора и каждый раз разный кадр. Быстрее этого графику рендерить не имеет никакого физического смысла. При этом не получится тормознуть графику по чисто физическим причинам.

Как альтернатива - можно наворотить многоэтажную систему приоритетов операций.  

> 100 * 100 * 3 - 30000 байт + плюс ещё 4
> байта координат откуда его рисовать.

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

> как Вы думаете, какой объём проще переслать и обработать X-ам?

Я то как раз думаю. И понимаю что именно поэтому и появились костыли типа xshm где на сетевую прозрачность забит болт, зато используется относительно быстрый и эффективный механизм. Проблема только в том что это - опция, по дефолту это не юзается. И если апликушник явно не изогнулся буквой зю - это работать не будет вообще!

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Проблемы X11 и их решения в Wayland , opennews, 10-Июн-13, 14:22  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру