Многопоточная работа с OpenGL (комментарии) (4 стр)

evirus
> А точно ли Finish происходит? Флуш да, должен быть обязательно, но ожидание их
> завершения - это весьма странно, т.к. так не будет работать буферизация команд
> на несколько кадров вперед

Согласно документации SwapBuffer реализует только функционал Flush (по крайне мере аналогичный) но не Finish, все просто.

evirus
> А точно ли Finish происходит? Флуш да, должен быть обязательно, но ожидание их
> завершения - это весьма странно, т.к. так не будет работать буферизация команд
> на несколько кадров вперед
Как говорит Крендель, и как указано в приводимых мной ранее доках свап гарантирует флушь. И только.
Поэтому я решил покопаться в интернетах дабы найти более конкретные факты связанные с экспериментальным подтверждением факта того что SwapBuffers делает stall.

Поиски показали что все очень сильно драйвер депендед, и есть случаи когда у людей он реально ожидает, есть когда сразу же возвращает управление
и впадает в ожидание только на повторном SwapBuffers, если первый SwapBuffers еще не завершился (как evirus и говорил насчет DX).
(Если интересно, могу накидать линков на обсуждения где я это нашел)

В драйверах где есть подержка трипл буфера там SwapBuffers должен точно возвращать управление сразу (если эта опция активирована).

При В-Синке, stall понятное дело имеется.

Признаю, что излишне грешил на SwapBuffers простоями, давно не заморачивался этим вопросом - а когда заморачивался, тогда видать драйвер\железо по факту делали stall при свапе.

Как вариант, можно проэкспериментировать, добавив вызов glFinish перед SwapBuffers, и сравнить фпс с ним и без него.

-----
И по теме. Если пошла такая пьянка до при много поточном рендере нельзя делать glFinish, дабы не понизить быстродействие, ведь тогда не будет работать трипл бафферинг!

false3d
> Как вариант, можно проэкспериментировать, добавив вызов glFinish перед SwapBuffers, и сравнить фпс с ним и без него.
думаю glFinish нужно вызывать поле SwapBuffers

> Если пошла такая пьянка до при много поточном рендере нельзя делать glFinish,
> дабы не понизить быстродействие, ведь тогда не будет работать трипл бафферинг!
glFinish используется только для синхронизации с ГПУ, отказаться от glFinish то же самае что отказаться от использования событий, крит. секций и других объектов синхронизации. Вместо glFinish можно попробовать использовать glFenceSync после изменения данных объекта GL в одном потоке и glWaitSync перед использованием этого объекта в другом потоке, тогда синхранизироваться будет в ГПУ, но надо проверить расшариваются ли sync объекты.
А причем здесь трипл буферинг?

/A\
> думаю glFinish нужно вызывать поле SwapBuffers
glFinish вообще звать не надо. Также как и делать рендер в несколько потоков, грузить ресурсы - да, рендерить - нет, потому что все равно никакого смысла это не имеет.

> glFinish используется только для синхронизации с ГПУ
Вовсе нет! Можно прекрасно обходиться без него.

> А причем здесь трипл буферинг?
Мы нивелируем все его свойства при использовании glFinish, т.к. мы после каждого кадра ждем видеокарту (sigh).

В идеале надо не видеокарту ждать а загрузку ресурсов, ибо слабое звено в том же стриминге это не видеокарта и не процессор это жесткий диск, я там писал выше свои мысли по этому поводу как это сделать в OpenGL, но к сожалению времени на реализацию я пока так и не нашел.

PS. Вообще сам по себе "многопоточный" рендер штука бесполезная, в отличии от стриминга.

KpeHDeJIb
> glFinish вообще звать не надо.
Знаю, но false3d хотел поэкспериментировать...

> Вовсе нет! Можно прекрасно обходиться без него.
Как еще узнать что предача данных текстуры в параллельном потоке завершилась и ее можно использовать?

> Вообще сам по себе "многопоточный" рендер штука бесполезная
Если рендер оптимизирован то да, но как я показал в одном тесте в некоторых случаях профит есть. Тем более в BF3 использовали параллельный рендеринг непонятно только как и для чего.

/A\
> > glFinish вообще звать не надо.
> Знаю, но false3d хотел поэкспериментировать...
Как закончу с рефакторингом чисто поэкспериментировать хочу, что бы узнать насколько разный прирост будет если будет на конкретных драйверах и видеокарте. Также пощелкаю опцию трипл бафера.

/A\
> > Вовсе нет! Можно прекрасно обходиться без него.
> Как еще узнать что предача данных текстуры в параллельном потоке завершилась и
> ее можно использовать?
Можно как вариант, на кадр позже апдейтить текстуры. Так как при втором вызове SwapBuffers полюбому будет ожидание выполнения первого кадра если он еще не завершен, в этот момент текстуры будет обновлены.
(при условии что каждый кадр свапить указатели в какую текстуру делаем RT)

/A\
> Тем более в BF3 использовали параллельный рендеринг непонятно только как и для
> чего.
Откуда дровишки?
И кстати - там же DX?

false3d
> Можно как вариант, на кадр позже апдейтить текстуры.
Так очередь команд у второго потока своя и ни как не связана со SwapBuffers первого потока. Если у нас 1000 ФПС, то обновление будет занимать 1мс, а передача данных текстуры займет 5мс, как тогда быть?
И вообще почему всем так не нравится вызывать glFinish в параллельном потоке?

> Откуда дровишки?
В презентации видел.

> И кстати - там же DX?
Да DX, я хотел переписать свои тесты на DX, чтобы сравнить, но сейчас как-то не до этого.

/A\
> Да DX, я хотел переписать свои тесты на DX, чтобы сравнить, но сейчас как-то не до этого.
В DX11 есть отличная штука - display list (не путать с OpenGL display list), так вот, их составление отлично параллелится, скорее всего так и было сделано, вот есть презенташка которая зрит в корень проблемы и подробно рассматривает как сделать такое на DX9-железе http://www.gamebryo.com/Global/Downloads/GameFest2008-ParallelRendering.pdf (еще раз обращаю внимание, рендер идет в один поток, только подготовка данных параллелится).

ЗЫ. Там еще сорцы есть http://www.gamebryo.com/Global/Downloads/DirectXCommandBufferLib-v1.zip

Меня тут уже поправили, в DX11 это называется command list.

/A\
> Так очередь команд у второго потока своя и ни как не связана со SwapBuffers
> первого потока.
Ну вот получается как в ДХ комманд лист - так при твоем параллельном рендеринге и будет готовиться в асинхронном контексте свой посути команд лист.
Но ведь все равно по сути это и есть подготовка данных, а рендеринг начнется непосредственно после вызова флушь в том или ином случае. (сейчас про финишь не говорю)

/A\
> И вообще почему всем так не нравится вызывать glFinish в параллельном потоке?
Ну просто получается - зачем второй поток заставлять ждать финишь если можно сделать флушь и продолжить готовить данные для следующего кадра, а свапить рендер таргеты после свап бафферс. То есть как бы можно и вызывать - но зачем заставлять этот второй поток простаивать - какой в этом профит?

KpeHDeJIb
> Также как и делать рендер в несколько потоков, грузить ресурсы - да, рендерить
> - нет, потому что все равно никакого смысла это не имеет.
Согласен с этим. Вот в DX такое на одном девайсе даже и сделать нельзя. Но есть случаи когда это нужно. Например, 2 монитора с разной герцовкой и надо делать v-sync.

> > А причем здесь трипл буферинг?
> Мы нивелируем все его свойства при использовании glFinish, т.к. мы после каждого кадра ждем видеокарту (sigh).
Более того, нивелируем двойную буферизацию.

Спасибо за статью.
Как то пытался разделить контексты, но в итоге ничего толкового не получилось. Было лень разбираться. В итоге просто сделал в параллельном потоке загрузку данных с диска. Огловые объекты уже в рендер потоке создавал. Ещё пилить и пилить... но в целом норм, оставлю.

false3d
> Как вариант, можно проэкспериментировать, добавив вызов glFinish перед
> SwapBuffers, и сравнить фпс с ним и без него
У меня в думе так:
glFinish();
SDL_GL_SwapBuffers();

Если убрать glFinish(), то fps на тестовом уровне по таймдемо вырастает с 182 до 223. Но вроде как без него могут появляться артефакты.

Вот комментарий с svn  ревизии с дружественного порта:

entryway
> Но вроде как без него могут появляться артефакты.
О каких артефактах речь?

Я тоже раньше юзал glFinish(); перед свап бафферс, и фпс дико падал. Щас я его не юзаю нигде никогда и никаких проблем и артефактов нет! =)