LINUX.ORG.RU

API для нормального DRI

 ,


0

2

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

Для начала что у нас есть. Общая архитектура такова:

приложение->opengl/openvl/foo->usermode_driver->(kernel)->новое DRI->kernelmode_driver->hardware.

«новое DRI» - это то, что я пилю в данный момент. планируется для начала сделать «новое DRI», фейковый kernelmode_driver для вывода в приложение и далее в иксы :), usermode_driver из llvmа, делающий IR, и «железо» из LLVMа, компилящего IR на своей стороне. тормозить будет адски :)

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

DRI будет показывать наружу 4 устройства. /dev/gpu - для работы с gpu вида создай текстуру-рисуй треугольник-запусти шейдер-opencl. можно будет открыть только один /dev/gpu на процесс(придется хакать что-то в структурах ведра ибо приоритеты нам тоже понадобятся)

как быть с композитором? я не хочу вводить ограничение «один композитор на 1 тачку». ведь можно отсылать скриншоты еще и панели задач(как в 7ке), другому приложению и т.д.).

возмонжно, можно будет открыть еще один /dev/gpu, сделать на него ioctl и отправить через unix socket композитору. этот fd будет урезан в правах до «только читать текстуру или юзать ее в шейдере». минусы - надо будет делать poll+read вместо одного ioctl или read

ах да. если текстурка помечена как конфиденциальная, то ни её, ни результаты обсчета шейдером получить обратно уже будет низя. чтоб не скриншотили номера кредиток

/dev/gpu_features - ну вот есть у amd uvd и pcom. их можно будет дергать, а загружаться они будут из огороженного в целях безопасности демона. т.е. шейдер можно будет взять готовый. почему отгорожено будет? чтоб не сломали вас дебажа каталист. катаглист огораживаете аппармором, и этот девайс тоже. оттуда же можно будет рулить питанием.

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

/dev/gpu_ctl - для отладки и контроля доступа.

apparmor приведен для примера.

какие-нибудь предложения есть по поводу вышенаписанного?

☆☆☆

может сначала /dev/eth1 добавим?

anonymous
()

я не хочу вводить ограничение «один композитор на 1 тачку»

если не жалко памяти выделить под композитор дополнительный фреймбуфер (со swap chain'ом), ограничения не будет. во всяком случае, я не вижу проблемы с композицией на GPU

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

Не всё так радостно.

1. Проблема апи. Если «композиторов» больше одного - надо разносить приложения по менеджерам, выяснять хуизху на этапе работы текстурами. Ну и в сочетании с пунктом про «конфиденциальность текстурки» всё начинает играть еще более яркими красками.

2. Эффективность использования памяти. Когда менеджер один - чётко известно, что выводиться на экран, что нет, можно решать, чего держать в видеопамяти, чего можно вытеснить в общую. Если же «композитор» будет держать в видеопамяти только конченый буфер, а всё остальное - в общей, он как бы нахрен такой не нужен.

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

выяснять хуизху на этапе работы текстурами

это однозначно определяется контекстом

Когда менеджер один - чётко известно, что выводиться на экран, что нет

и что меняется, когда их становится больше?

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

это однозначно определяется контекстом

Контекстом чего?

и что меняется, когда их становится больше?

Известное перестаёт быть известным. Всегда ваш, К.О.

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

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

ckotinko ☆☆☆
() автор топика
Ответ на: комментарий от LamerOk

1. композитором может выступать какой нибудь open office calc, в который вставили 3д из другого приложения. сейчас это надо делать через xembed, который большинство приложений не поддерживают потому что нафига им это.

2. для большинства задач нет нужды в решании что держать в видеопамяти. ну максимум фреймбуфер для окна + еще мегабайт 8-16 на всякий пожарный случай только на время отрисовки. видяхи отлично видят системную память, нехватающие страницы можно будет лочить без отображения в адресное пространство на время операции.

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

ckotinko ☆☆☆
() автор топика
Ответ на: комментарий от ckotinko

композитором может выступать какой нибудь open office calc,

А! Ну тогда, видимо, ты под композитором ты понимаешь что-то иное, чем, скажем, Weston или компиз.

для большинства задач нет нужды в решании что держать в видеопамяти.

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

Если я правильно понимаю, сейчас этим занимается связка DRI модуль в иксах + DRI модуль в ядре. И, опять же, если я правильно понимаю, эту же функцию выполняют композиторы типа Weston'а.

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

уменьшенная копия окна

собираешь композицию для окна на отдельном фреймбуфере и пускаешь через write back канал обратно в тот же композитор с масштабированием и соответствующей геометрией

встраивания окон одного приложения в другое

опять же, это вполне решается реализацией без усложнения интерфейса

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

драйверу особе неведомо будет кто там композитор

не понял. ему и так неведомо - он композитору только интерфейс предоставляет

jtootf ★★★★★
()

ах да. если текстурка помечена как конфиденциальная, то ни её, ни результаты обсчета шейдером получить обратно уже будет низя. чтоб не скриншотили номера кредиток

Суперфича. Серьёзно.

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