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

Многопоточность:как вынести отдельно рендер OpenGL и обработчик событий окон

Страницы: 1 2 3 4 Следующая »
#0
20:07, 27 сен. 2013

Приветствую.
Толком сабж.
Я уже замучился с методом проб и ошибок,поэтому можете скинуть примитивный код,как осуществить многопоточность:
C++,OpenGL
1 поток -main() -он запускает другие 2 потока и засыпает
2 поток - support -он создаёт окно и входит в цикл обработки сообщений
3 поток - render -он рендерит OpenGL

Нужен код и под WinApi и под  Xlib


#1
21:23, 27 сен. 2013
под  Xlib

На Linux не советую - с некоторыми OpenGL драйверами могут быть фатальные проблемы.
На Windows проблем особо нет (вис только драйвер под VirtualBox).

Примеров не дам, могу только дать ссылку на open-source проект.

#2
21:50, 27 сен. 2013

Это должно выглядеть примерно так

+ Показать

#3
22:33, 27 сен. 2013

gkv311
Да,знаю. Но я никогда не собираюсь поддерживать только винду. Это зло всё же. Ну у меня на убунту легко встали дрова под GeForce550 Ti, OpenGL 4.3 ,в Wine встал DirectX 9,так что в сталкера можно играть-правда там как-то не очищается обновляется фон,и только,а бенчмарк через Wine показал FPS выше,чем винда(на винду дрова старше правда).
Ну кидайте ссылку

Спасибо,/ A \

#4
22:38, 27 сен. 2013

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

#5
22:45, 27 сен. 2013

nes
нет. это ужасно. мне удавалось ну и сейчас работает рендер в одном,обработка в другом,как / A \ говорил
в моем двиге и консоль в отдельном потоке-дабы она могла работать когда все зациклилось

#6
23:55, 27 сен. 2013

TrionProg
> под Xlib
Ты же в курсе, что Xlib не потокобезопасна, и нельзя проcто так в одном треде делать glxSwapBuffers, а в другом XNextEvent?

#7
0:54, 28 сен. 2013

TrionProg
> нет. это ужасно
что в этом ужасного?
нафига разделять рендер и обработку событий? у тебя там события чего миллионами генерируются?
в отдельный поток можно update вынести

#8
1:34, 28 сен. 2013

Пример с двумя потоками для Win
http://stackoverflow.com/questions/5521131/multithreading-opengl-… -child-window

#9
2:23, 28 сен. 2013

RPGman
Я уже убедился. Какое-то внезапное нарушение сегментации. Но как-то же люди этого избегают? Xlib же вроде основная самая низкоуровневая библиотека.

cNoNim
Все равно будет замедленная реакция на действия юзверя,особенно при обработке больших сцен,загрузки текстур(кстати,можно ли glLoadTexture вынести ищ потока рендера?),загрузке моделей. И часто будет мигать не отвечает. Плюс при этом окошко может скакать

Gorunuch
Спс,посмотрю

Итак,с винапи как-то разобрались. теперь как быть с линуксом,ведь в нем иные подводные камни?

#10
2:45, 28 сен. 2013

как вариант взять SDL, и сделать как /A\ написал

#11
9:21, 28 сен. 2013

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

c_timer.h

+ Показать

c_timer.cpp

+ Показать

main.cpp

+ Показать

#12
9:26, 28 сен. 2013

TrionProg
> 2 поток - support -он создаёт окно и входит в цикл обработки сообщений
> 3 поток - render -он рендерит OpenGL

рендер OpenGL и цикл обработки сообщений должны находиться в одном потоке, на сколько я помню

#13
10:03, 28 сен. 2013

dedm0zaj

рендер OpenGL и цикл обработки сообщений должны находиться в одном потоке, на сколько я помню

Если вы про WinAPI, то нет, не должны - GL контекст прекрасно рисует в независимом потоке в простом бесконечном цикле.
Но перетаскивать сообщения в поток отрисовки всё равно как-то надо, если приложение интерактивное ;).TrionProg

TrionProg

Да,знаю. Но я никогда не собираюсь поддерживать только винду. Это зло всё же.

Я не про многоплатформенность в целом, а в том, что с многопоточным GL на линухах были некрасивые баги, из-за ошибок в самих драйверах (например, Catalyst).
1 поток -main() -он запускает другие 2 потока и засыпает
2 поток - support -он создаёт окно и входит в цикл обработки сообщений
3 поток - render -он рендерит OpenGL

В этой схеме есть как минимум одно слабое звено - Cocoa на Mac OS X гвоздями прибито к главному потоку (тому, в котором main стартует).
Рисовать в GL контекст в левом потоке можно (есть только проблемка с мусором в окне при ресайзе),
но каждый чих к самому окну надо делать в основном потоке, благо для этого в Cocoa есть готовые средства.

В результате моё приложение сейчас работает по разному на разных системах:
1) В Windows - main создаёт отдельный поток для окна (обработки событий WinAPI), а в главном потоке происходит отрисовка в GL (можно и не в главном - в случае с NPAPI плагином создаётся ещё один поток).
2) В Linux - обработка событий окна и GL рендеринг в одном потоке (main - для простого приложения, отдельный поток в NPAPI плагине - что приводит к рандомным падениям с кривыми GL драйверами).
3) В Mac OS X - наоборот, в main создаётся поток для GL рендеринга, обработка событий происходит в основном потоке (+ опционально режим, когда GL также в основном потоке работает).

Ну кидайте ссылку

Ссылок на примеры уже накидали, но всё же - класс StWindowImpl и его реализация для разных систем (правда в случае с Mac OS X достаточно приличный кусок кода уходит в main.cpp из-за дурацкого Cocoa):
https://github.com/gkv311/sview/blob/master/StCore/StWindowImpl.h
#14
11:11, 28 сен. 2013

TrionProg
> 1 поток -main() -он запускает другие 2 потока и засыпает
> 2 поток - support -он создаёт окно и входит в цикл обработки сообщений
> 3 поток - render -он рендерит OpenGL
Это хрень полная. Поток, который создает 2 потока и засыпает не нужен. На обработку сообщений тратится очень мало процессорного времени. Если рендер реалтайм 30+ fps, то отдельный поток на обработку ввода в принципе не нужен и без него всё будет быстро и своевременно обрабатываться.

TrionProg
> кстати,можно ли glLoadTexture вынести ищ потока рендера?
А это кто?
Ее нету ни в gl.h ни в glext.h !
Например, VAO нельзя создавать в другом потоке, иначе OGL откинет коньки.

gkv311
> Я не про многоплатформенность в целом, а в том, что с многопоточным GL на
> линухах были некрасивые баги, из-за ошибок в самих драйверах (например,
> Catalyst).
На винде у ATI тоже самое...

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

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