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

TrionProg
Постоялец

#0
20:07, 27 сен 2013

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

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

gkv311
Постоялец

#1
21:23, 27 сен 2013

под Xlib

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

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

$Андрей (/A\)$

/A\
Постоялец

#2
21:50, 27 сен 2013

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

+ Показать

− Скрыть

atomic_bool  loopRenderThread = true;

void Render (void *)
{
  CreateRenderContext();

  while ( loopRenderThread )
  {
    RenderFrame();
  }

  DestroyRenderContext();
}

void Support (void *)
{
  CreateWindow();
  
  Thread thread = NewThread( &Render, nullptr );

  bool looping = true;

  while ( looping )
  {
    ProcessMessages();
  }

  loopRenderThread = false;

  thread.Wait();
  DestroyWindow();
}

void main ()
{
  NewThread( &Support, nullptr );
  Sleep(-1);  // засыпает
}

TrionProg
Постоялец

#3
22:33, 27 сен 2013

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

Спасибо,/ A \

nes
Постоялец

#4
22:38, 27 сен 2013

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

TrionProg
Постоялец

#5
22:45, 27 сен 2013

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

RPGman
Удалён

#6
23:55, 27 сен 2013

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

cNoNim
Постоялец

#7
0:54, 28 сен 2013

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

Gorunuch
Постоялец

#8
1:34, 28 сен 2013

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

TrionProg
Постоялец

#9
2:23, 28 сен 2013

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

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

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

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

Mikey
Постоялец

#10
2:45, 28 сен 2013

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

dedm0zaj
Постоялец

#11
9:21, 28 сен 2013

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

c_timer.h

+ Показать

− Скрыть

#ifndef C_TIMER_H_INCLUDED
#define C_TIMER_H_INCLUDED

#include <time.h>
#include <pthread.h>

class c_timer
{
private:
    int step_t;
    void (*timer_make)();
    void thread_make();
    static void* thread_func(void *);
public:
    c_timer(int, void ());
    //~c_timer();
    //inline int get_sec() {return req.tv_sec;}
};

#endif // C_TIMER_H_INCLUDED

c_timer.cpp

+ Показать

− Скрыть

#include "c_timer.h"

c_timer::c_timer(int msek, void (*ati)())
{
    if (msek<1) msek = 1;
    step_t = msek*10;
    pthread_t thread1;
    timer_make = ati;
    pthread_create(&thread1, NULL, thread_func, this);
}

void* c_timer::thread_func(void *arg)
{
    c_timer* p = reinterpret_cast<c_timer*>(arg);
    p->thread_make();
    return NULL;
}

void c_timer::thread_make()
{
    timespec req;
    req.tv_sec = 0;
    req.tv_nsec = 1000000L;

    int t1, tt;
    timespec req2;
    clockid_t clid = CLOCK_MONOTONIC;

    clock_gettime(clid, &req2);
    tt = req2.tv_sec*10000 + req2.tv_nsec/100000 + step_t;

    while (true){
        clock_gettime(clid, &req2);
        t1 = req2.tv_sec*10000 + req2.tv_nsec/100000;
        if (t1>tt) {
            tt = tt + step_t;
            timer_make();
        }
        nanosleep(&req, (struct timespec *)NULL);
    }
}

main.cpp

+ Показать

− Скрыть

#include <iostream>
#include "c_timer.h"

using namespace std;

int a,b;

void a1()
{
    a++;
}

void a2()
{
    cout << a << endl;
    a = 0;
}

int main()
{
    c_timer tim(10,a1);
    c_timer tim2(1000,a2);
    cin >> b;  //нужно, чтобы основной поток не завершился, а то завершится вся программа

    return 0;
}

dedm0zaj
Постоялец

#12
9:26, 28 сен 2013

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

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

gkv311
Постоялец

#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

Anika
Постоялец

#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 Следующая »

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