false3d
> Как на счет свап бафферс, он ведь внутри себя glFinish и зовет.
Кто тебе такое сказал? Во-первых он делает аналогичную glFlush операцию, во-вторых до того как ты его сделал у тебя есть еще куча времени на обновление логики программы.
> И анбинд FBO... Разве нет?
О_о
> Или не стоит свап бафферс звать?
Ну если мы затронули такую щепетильную тему, то можно и без него при должно умении все делать :)
KpeHDeJIb
> Кто тебе такое сказал? Во-первых он делает аналогичную glFlush операцию,
> во-вторых до того как ты его сделал у тебя есть еще куча времени на обновление
> логики программы.
К сожалениею ты не понял моего вопроса.
Естественно необязательно что свап бафферс делает именно финишь. Но смысл в том что он не возвращает управление а вешает текущий поток пока команды не будут выполнены видеокартой.
На счет финиша при анбинде FBO я не уверен, но что будет если в одном потоке идет запись в этот FBO а в другом собственно идет рендеринг и FBO этот используется как текстура... Уточняю, что под понятием рендеринга я имею ввиду непосредственно процесс выполнения команд отрисовки видеокартой (НЕ их буферизация а уже исполнение)
>Ну если мы затронули такую щепетильную тему, то можно и без него при должно умении все делать :)
Интересно как? Писать напрямую во фронтбуффер? Или с помощью фбо делать по сути тот же свап бафферс?
Тогда мне интересно как можно узнать, что все команды текущего кадра были выполенны? (без использования glFinish или swapBuffers)
false3d
> но что будет если в одном потоке идет запись в этот FBO а в другом собственно
> идет рендеринг и FBO этот используется как текстура...
Я же в статье написал: "После изменения данных и перед использованием в другом потоке нужно вызывать glFinish, чтобы драйвер завершил все изменения данных", рендеринг в текстуру это тоже изменение данных.
У меня на nVidia в таком случае отображается черная текстура.
> Тогда мне интересно как можно узнать, что все команды текущего кадра были
> выполенны? (без использования glFinish или swapBuffers)
есть еще объекты синхронизации, но в результате получится тот же glFinish
false3d
> На счет финиша при анбинде FBO я не уверен, но что будет если в одном потоке
> идет запись в этот FBO а в другом собственно идет рендеринг и FBO этот
> используется как текстура... Уточняю, что под понятием рендеринга я имею ввиду
> непосредственно процесс выполнения команд отрисовки видеокартой (НЕ их
> буферизация а уже исполнение)
Перечитал еще раз статью. Впринципе автор упомнянул:
>Буферы, текстуры, шейдеры
>Они без проблем работают на нескольких контекстах если не делать одновременное чтение и запись. После изменения данных (заливка вершин/изображения/исходника, генерация мип уровней, установка параметров, >компиляция) и перед использованием в другом потоке нужно вызывать glFinish, чтобы драйвер завершил все изменения данных.
То есть по сути синхронизация потоков как раз таким образом и делается, что бы одновременно swapBuffers (первого потока) и glFinish (второго потока) не могли вызваться одновременно, иначе будет плохо. =)
Таким образом с этим вопросом мне прояснилось все более менее. А следовательно возвращаемся к базовому вопросу, в чем собственно профит от двух контекстов в разных потоках? (кроме тех что я написал в посте #5)
Может кто-то точно знает, может ли видеокарта параллельно выполнять команды разных контекстов когда они пошли на непосредственное исполнение?
Правка: (Имею ввиду случай когда данные не меняются в одном контексте а читаются в другом. А просто читаются и исполняются двумя контекстами асинхронно)
false3d
> Может кто-то точно знает, может ли видеокарта параллельно выполнять команды
> разных контекстов когда они пошли на непосредственное исполнение?
Не может. Поэтому звать параллельно две команды из разных потоков профита никакого. Параллелить имеет смысл подготовку ROP-ов/собирание команд-буфера, в остальном смысла мало.
KpeHDeJIb
> Не может. Поэтому звать параллельно две команды из разных потоков профита
> никакого. Параллелить имеет смысл подготовку ROP-ов/собирание команд-буфера, в
> остальном смысла мало.
Ну собственно как я и предполагал изначально. Буста нет только удобнее подгружать ресурсы асинхронно.
Вобщем вы меня задели за живое, в выходные накидаю демку с тем как я себе представляю "многопоточный рендер", основные идеи такие:
1. Весь рендер происходит в одном потоке, в других потоках готовится очередь команд для рендера (список ROP-ов).
2. Поток рендера делает две вещи - перегоняет данные из RAM в VRAM когда они готовы и выполняет сам рендер, возможно сделаю второй контекст, для загрузки готовых данных в VRAM, исключительно для удобства.
3. У нас два списка команд, рендер всегда обрабатывает первый, все остальные потоки работают со вторым, когда он готов - свитч списков.
4. Принимаем за априори что первый лод/мип-уровень грузится достаточно быстро, для остальных я вставлю Sleep-ы, чтобы было наглядно видно асинхронную загрузку.
5. Для синхронизации рендера будем использовать исключительно примитивы которые дает OpenGL (не будем привязываться к glFinish/glFlush, думаю QO вполне с задачей справятся).
6. За основу возьмем OpenGL 3.2 там в ядре уже есть все что надо, ну может сразу OpenGL 3.3, поглядим.
Надеюсь подобный сурвей будет интересен еще кому-нибудь кроме меня, лично я для себя другого "многопоточного рендера" и не представляю.
KpeHDeJIb
С удовольствием бы пощупал такую демку, так как многопоточность это очень интересная тема в которой для меня еще очень много открытых вопросов. =)
KpeHDeJIb
>3. У нас два списка команд, рендер всегда обрабатывает первый, все остальные потоки работают со вторым, когда он готов - свитч списков
Речь идет о свиче контекстов как я понимаю?
И что если команды находящиеся во втором списке его заполнят и пойдут на исполнение раньше чем мы сделаем свич?
То есть насколько я понимаю у нас ведь нет гарантий что к моменту завершения создания списка он еще не пошел на обработку видеокартой?
false3d
> Речь идет о свиче контекстов как я понимаю?
Нет, не контексты, именно программные списки с RPO-ами. Контест рендера тут не при чем.
> То есть насколько я понимаю у нас ведь нет гарантий что к моменту завершения
> создания списка он еще не пошел на обработку видеокартой?
Смысл такой, мы обрабатываем список - вызываем функции GAPI, бегаем по первому списку пока готовится второй, как только второй готов он ждет когда мы закончим работу с первым списком и происходит свитч. Но это еще теория, я погляжу как на практике будет это выглядеть, может имеет смысл использовать только один список, посмотрим.
KpeHDeJIb
>Нет, не контексты, именно программные списки с RPO-ами. Контест рендера тут не при чем.
А все понял, не сразу вкурил что под ROP понимается
KpeHDeJIb
> 3. У нас два списка команд, рендер всегда обрабатывает первый, все остальные
> потоки работают со вторым, когда он готов - свитч списков.
То есть в этом случае список команд готовится для следующего кадра?
false3d
Ты уверен что не возвращает управление? Вот в dx он будет возвращать управление до тех пор пока есть свободный буфер. То есть свап не ждет текущий кадр, а в худшем случае ждет - предыдущий. Сомнительно что в огл все иначе. Это вроде как популярная концепция, используется везде чтобы с дропами бороться.
evirus
> Ты уверен что не возвращает управление? Вот в dx он будет возвращать управление
> до тех пор пока есть свободный буфер. То есть свап не ждет текущий кадр, а в
> худшем случае ждет - предыдущий. Сомнительно что в огл все иначе. Это вроде как
> популярная концепция, используется везде чтобы с дропами бороться.
уверен
false3d
В документации это сказано? Синхронизация с мониторной частотой есть?
Как проверял что ждет именно текущий, а не предыдущий кадр?
Тема в архиве.