Udostępnianie bufora ramki/bufora renderowania OpenGL między dwiema aplikacjami

Question

Załóżmy, że mam aplikację A, która jest odpowiedzialna za malowanie rzeczy na ekranie za pośrednictwem biblioteki OpenGL. Aby zapewnić ścisłą integrację, chciałbym, aby ta aplikacja mogła wykonywać swoje zadanie, ale renderować ją w FBO lub bezpośrednio w buforze renderowania i zezwalać aplikacji B na dostęp do tego bufora tylko do odczytu, aby obsłużyć ekran na ekranie (zasadniczo renderowanie go jako tekstury 2D).

Wygląda na to, że pliki FBO należą do kontekstów OpenGL, a konteksty nie są współdzielone między procesami. Zdecydowanie rozumiem, że zezwalanie na kilka procesów dwóch nieporządków w tym samym kontekście jest złe. Ale w moim konkretnym przypadku myślę, że to jest całkiem bezpieczne.

UWAGA:

Zastosowanie A jest QApplication oraz zastosowanie B jest native win32 jeden

Edycja:

renderowania rozmiar jest prawie pełnym ekranie, to myśli buforu 2048x2048 32bits (I don na razie używaj kanału alfa, ale dlaczego nie drugi).

Answer 1

Obiekty bufora ramki Obiekty nie mogą być współużytkowane między kontekstami OpenGL, niezależnie od tego, czy należą do tego samego procesu, czy nie. Tekstury mogą być jednak udostępniane jako tekstury bufora koloru do obiektów bufora ramki.

Udostępnianie kontekstów OpenGL między procesami, które jest faktycznie możliwe, jeśli system graficzny udostępnia interfejs API dla tego zadania. W przypadku X11/GLX możliwe jest współdzielenie pośrednich kontekstów renderowania między wieloma procesami. Być może jest to możliwe w Windowsie poprzez empirowanie kilku naprawdę, naprawdę prymitywnych hacków. MacOS X, nie mam pojęcia, jak to zrobić.

Najprawdopodobniej najłatwiej jest użyć obiektu bufora pikseli, aby uzyskać dostęp do renderowanego obrazu. Następnie wyślij go do innej aplikacji poprzez pamięć współdzieloną i umieść ją w tamtejszej strukturze (ponownie poprzez obiekt bufora pikseli).

Answer 2

W moim rozumieniu nie można udostępniać obiektów między procesem w systemie Windows, chyba że jest to obiekt trybu jądra. Nawet współużytkowane tekstury i konteksty mogą tworzyć trafienia wydajnościowe, ale to ona dodatkowo obciąża synchronizację wywołań SwapBuffer(). Zwłaszcza pod platformą Windows implementacja OpenGL jest znana.

Moim zdaniem, możesz przekazywać między-procesowe mechanizmy komunikacyjne, takie jak Zdarzenia, muteks, komunikaty okna, potoki, aby zsynchronizować renderowanie. ale po prostu zdaj sobie sprawę z tego, że podchodzi się w ten sposób do kwestii wydajności. Obiekty trybu jądra są dobre, ale przejście do jądra za każdym razem kosztuje 100 ms. Co jest kosztowne w przypadku wysokowydajnej aplikacji do renderowania. Moim zdaniem trzeba ponownie rozważyć projekt renderingu wieloprocesowego.