Войти
ПрограммированиеФорумГрафика

[OpenGL] Создание текстуры в одном процессе, а рендеринг в другом

Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 Следующая »
#0
21:15, 17 дек. 2018

Всем привет.

В свободное время работаю над добавлением аппаратного декодирования в фаерфокс через vaapi в линуксы.

Как оно работает у меня сейчас
Как известно фаерфокс на данный момент запускается в нескольких процессах: хост процесс (для рендеринга), контент процесс (здесь как раз и декодируется видео) и прочие. У меня есть рабочий прототип, который работает следующим образом. В контент процессе я декодирую и получаю dma буффер декодированного кадра. Он состоит из файлового дескриптора и еще нескольких числовых параметров. Эти данные легко шарятся между процессами я собственно их и отправляю на хост процесс. На хост процессе я импортирую кадр в EGLImage посредством EXT_image_dma_buf_import, а далее в GL текстуру. К несчастью фаерфокс имеет такую архитектуру, что с таким подходом к декодированию приходится КАЖДЫЙ КАДР шарить очередной dma буффер между хост и контент процессами, а на стороне хоста еще и создавать (а в после отрисовки еще и удалять) GL текстуру. Что в совокупности дает огроменный оверхед.

Как оно в других декодерах
Конечно же другие декодеры не создают каждый кадр текстуры, они заранее создают пул текстур, один раз шарят текстуры между хост и контент процессом и далее переиспользуют эти текстуры. Например на винде могут использоваться DirectX текстуры. В контент процессе создается расшаренная DX текстура (я не знаком с D3D так что все описанное здесь лишь результат изучения исходников и чтения коментов фаерфокса. ну и мои термины могут отличаться от общепринятых), на хост процесс передается ее handle. Таким образом мы можем обновлять текстуру в контент процессе, а рендерить на хосте.

Чего хотелось бы добиться
В контент процессе создать egl контекст без привязки к оконной системы (это называется headless если я не ошибаюсь). Аналогично DX создать GL текстуру (или EGLImage) в контент процессе, расшарить ее с хост процессом. Далее в контент процессе я ее буду обновлять, а на хосте рендерить. Вот с расшариванием у меня и возникли проблемы. Я буду рад любой идее или хотябы в какую сторону мне копать.

Стек технологий для которого все пилится
Linux, wayland, egl, opengl (десктопный или es).

З.Ы. сорри за много букаф


#1
21:58, 17 дек. 2018

G@sh!sh
>К несчастью фаерфокс имеет такую архитектуру
забавное совпадение, на днях смотрел реализацию WebGL в файрфоксе, ужас и кошмар, могу только удачи пожелать если надо с ним работать(внетренняя структура GL ведь аналогична)

> что с таким подходом к декодированию приходится КАЖДЫЙ КАДР шарить очередной
> dma буффер между хост и контент процессами, а на стороне хоста еще и создавать
> (а в после отрисовки еще и удалять) GL текстуру. Что в совокупности дает
> огроменный оверхед.
DX делает также( в смысле под каждый кадр удались->создать, без DMA буфера конечно), оверхед стандартный для OpenGL(не думаю что есть сильная разница с обычным проигрыванием видео через OpenGL), разве что Вулкан подключать(но его нет в файрфоксе)

> В контент процессе создать egl контекст без привязки к оконной системы
думаю ты сам понимаешь что это проработает в течении одной версии файрфокса и до следущего обновления иксов... *GL в файрфоксе ломают каждую версию(на Генте файрфокс просто собирается без *GL ускорения вообще, им наверно надоело фиксить сотни флагов сборки)

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

#2
7:29, 18 дек. 2018

G@sh!sh

https://stackoverflow.com/questions/11726650/egl-can-context-be-s… tween-threads

#3
19:37, 18 дек. 2018

Danilw
> DX делает также( в смысле под каждый кадр удались->создать, без DMA буфера
> конечно), оверхед стандартный для OpenGL
Я наверное плохо объяснил как работает DX бекенд. для DX бекенда в самом начале декодирования создается DX текстура (на самом деле пул текстур, но сейчас это не важно) в контент процессе, handle текстуры передается на хост процесс и на основе этого хендла создается (на хосте) обеъект текстуры. Создание и расшаривание текстуры происходит ровно один раз, когда декодеру нужно обновить значение текстуры он ее просто обновляет, хост автоматически видит эти изменения, т.к. хост и контент процессы работают физически с одной текстурой.
На данный момент у меня не получается применить похожий подход к моему прототипу ибо dma буффер приходит от драйвера (вроде бы нету возможности заранее создать этот буфер приложением, а потом сказать декодеру "декодируй в этот буфер"), а как расшарить  GL текстуру между процессами я так и не узнал.
> разве что Вулкан подключать(но его нет в файрфоксе)
я с вулканом не знаком, но если я правильно все понял, то там как раз есть то что мне нужно: VK_KHR_external_memory_fd. в GL есть похожее расширение, но оно только для импорта, но не экспорта :( и да в фаерфоксе нет вулкана и планов по его добавлению я не видел.
> думаю ты сам понимаешь что это проработает в течении одной версии файрфокса и до следущего обновления иксов... *GL в файрфоксе ломают каждую версию
Во-первых, я ориентируюсь на вейланд (точней мне нужен egl), а не иксы. Во-вторых, год не срок, но за это время вроде бы не было проблем со сборкой из исходников и запуском GL композитора.
> сложная задача, очень много времени надо потратить для получения рабочего решения, удачи братан :)
Пасиб. Ковыряние в фаерфоксе стало моим хобби в последний год и я никуда не спешу)

#4
19:40, 18 дек. 2018

nonamezerox
Я тоже думал раз в линухе треды это процессы, то может сработать, но после изучения мат части, есть подозрения, что работать не будет. Если я не прав поправьте.

#5
20:55, 18 дек. 2018

G@sh!sh
> а как расшарить  GL текстуру между процессами я так и не узнал.
из первого сообщения я предположил что ты делаешь решение на основе firefoxAPI
не вмешиваясь в исходники файрфокса
если так, то помоему ты сам еще в первом посте ответил-"никак" потому что внутри файрфокса так сделано

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

>>я ориентируюсь на вейланд (точней мне нужен egl), а не иксы

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

G@sh!sh
> Пасиб. Ковыряние в фаерфоксе стало моим хобби в последний год и я никуда не
> спешу)

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

#6
21:24, 18 дек. 2018

G@sh!sh
> КАЖДЫЙ КАДР шарить очередной dma буффер между хост и контент процессами
кажется я понял что ты хочешь
файрфокс(первый процесс) пихает текстуры в dma(буфер) и клиент(второй процесс) берет оттуда текстуру

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

можно так:
сделать третий процесс
и в этом третем процессе сделать свое АПИ по которому будут обращаться первый и второй
тоесть перенести функционал "загрузки текстуры в egl"(из первого процесса) в этот "третий"+перенести рендеринг из второго процесса в третий
(это избавит от оверхеда создания буфера в первом процессе)

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

так точно делали уже тыщу раз для файрфокса, те самые "mplayer оверлеи" и другие видеоплееры вставляли подобным образом(флеш также оверлеем рисовался)

#7
4:49, 19 дек. 2018

А разве в GL нельзя через PBO по DMA лить данные с ручной синхронизацией?

#8
7:46, 19 дек. 2018

Dimich
> А разве в GL нельзя через PBO по DMA лить данные с ручной синхронизацией?
Автор хочет "GL_TEXTURE текстуру созданную в одном потоке перекинуть во второй"
в GL так точно нельзя(он однопотчный(да есть костыли нвидии для многопоточного OpenGL но я не знаю что там можно нельзя))

вопрос в том "могут ли так делать иксы/вайланд" если в них текстуру пихать, тут я не знаю ответа
(через третий поток под свой оверлей помоему намного проще и "независимо от иксов/вайланда")

#9
11:02, 19 дек. 2018

Danilw
> в GL так точно нельзя(он однопотчный(да есть костыли нвидии для многопоточного
> OpenGL но я не знаю что там можно нельзя))
прям совсем однопоточный?

#10
11:12, 19 дек. 2018

Тебе нужно создать indirect контекст в контент-процессе и расшарить его с контекстом рендер-процесса.

#11
11:29, 19 дек. 2018

MAMOHT-92
Само API - да. У Nvidia драйвер под капотом реализуют  OpenGL как многопоточное приложение. Но внешне однопоточность сохраняется. Даже справка по shared context afair говорит что забинден как makeCurrent контекст может быть только в одном потоке.

Есть выкрутасы с memory mapped buffers, где возможно делать загрузку в буффер в отдельном потоке, но имхо это не DMA, а просто загрузка во внутренний буффер драйвера. Откуда он ещё должен это перекопировать в память GPU

#12
12:26, 19 дек. 2018

Deamon
> забинден как makeCurrent контекст может быть только в одном потоке.
а несколько контекстов одновременно в разных потоках, но они шаред при этом друг для друга.

#13
8:46, 22 дек. 2018

Ghost2
> Тебе нужно создать indirect контекст в контент-процессе и расшарить его с
> контекстом рендер-процесса.
это иксовоспецифичное решение, а мне как раз нужный не иксы

#14
21:44, 22 дек. 2018

текстуры и VBO можно загружать в отдельном потоке если создать отдельный контекст GL и при создании указать что он шаред с основным. но создавать оба контекста нужно до создания любых ресурсов.
Потом выбрать его в потоке и вперед.
Работает на ATI и NVIDIA под виндами, но никаких преимуществ не дает. И то и другое просто копирование памяти, вызвать его можно и из основного потока. Тормоза все равно не уйдут.
Я даже паралельное рисование в несколько потоков пробовал, и даже работало, хоть и падало в дровах на некоторых картах. Но получалось медленней, что логично.

Страницы: 1 2 Следующая »
ПрограммированиеФорумГрафика

Тема в архиве.