Цикл рендеринга — максимальное распараллеливание

Ниже приведена диаграмма последовательности UML, показывающая время обработки при моем понимании игрового цикла в библиотеке libGDX. Я думаю, что это должна быть одна и та же архитектура для любой другой игровой библиотеки. Я не уверен, правильно ли я понял. sequence chart CP and GPU serial Теоретически CPU и GPU работают параллельно. Когда ЦП ждет, пока ГП закончит изменение буфера, это делает его последовательным процессом. Как заставить мой игровой цикл работать параллельно или я неправильно понимаю?

Теперь image мы хотим иметь распараллеливание и чтобы GPU работал медленнее, чем CPU, а CPU продолжал со следующим кадром, пока GPU выполняет рендеринг. У нас есть второй поток, ожидающий завершения GPU. После того, как GPU закончит работу, вычисляется следующее изображение. Куда теперь идут изменения состояния OpenGL и команды рисования? GPU сейчас занят. Это приводит меня к выводу, что я что-то упускаю. диаграмма последовательности параллельных ЦП и ГП

РЕДАКТИРОВАТЬ:

Предложено Россом Вандером: предложено Вандером


rendering parallel-processing libgdx game-loop
person Benedikt S. Vogler    schedule 18.06.2017    source источник
comment
Почему на второй диаграмме вызов рендеринга возвращается к потоку ЦП 2, а не к потоку ЦП 1?   -  person Ryan Stout    schedule 18.06.2017
comment
потому что ЦП должен поменять местами передний и задний буфер. поток 1 рендерит следующий кадр, поэтому поток 2 ожидает изменения буферов.   -  person Benedikt S. Vogler    schedule 18.06.2017
comment
Извините, мне не ясно, что ваша диаграмма UML пытается сообщить тогда. Являются ли потоки на вашей диаграмме потоками управления или чем-то другим? Независимо от того, поменяете ли вы два указателя (или ссылки, поскольку LibGDX — это java) или нет, это все равно не изменит поток управления, заблокированный на графическом процессоре. Я что-то упускаю?   -  person Ryan Stout    schedule 18.06.2017

Ответы (1)


arrow_upward
1
arrow_downward

Одна проблема, которую я вижу со второй диаграммой, которая может быть причиной того, что вы ошибаетесь, заключается в том, что графический процессор, кажется, возвращается к потоку ЦП 2, хотя именно поток ЦП 1 отправлял данные в графический процессор и начал блокировать его. Замена двух ссылок на передний и задний буфер не меняет того, какой поток блокируется на GPU. Я думаю, что порядок событий должен быть примерно таким: поток ЦП 1 отправляет данные из переднего буфера в ГП для рендеринга. Одновременно поток 2 выполняет запись в задний буфер. Когда графический процессор завершает работу, поток 1 может поменять местами передний и задний буферы (при условии, что поток 2 завершен), а затем отправить данные в графический процессор. Поток 2 снова записывает в задний буфер, пока работает GPU.

Обновление: взято из https://github.com/libgdx/libgdx/wiki/Threading

Любые графические операции, напрямую связанные с OpenGL, должны выполняться в потоке рендеринга. Выполнение этого в другом потоке приводит к неопределенному поведению. Это связано с тем, что контекст OpenGL активен только в потоке рендеринга. Создание текущего контекста в другом потоке имеет свои проблемы на многих устройствах Android, поэтому оно не поддерживается.

person Ryan Stout    schedule 18.06.2017
comment
Это имеет смысл, однако это не отвечает на мой вопрос, куда идут изменения состояния gl при рендеринге графического процессора. Стоят ли они в очереди? Тем не менее принял ваш ответ. - person Benedikt S. Vogler; 18.06.2017
comment
изменения состояния gl происходят только в потоке 1. Я обновлю свой ответ - person Ryan Stout; 18.06.2017
comment
Я ожидаю возможного продолжения, тогда какая польза от второго потока?. Этот поток можно использовать, например, чтобы решить, где рисовать ваши игровые объекты. Если у вас сложная игровая физика или другие вычисления с интенсивным использованием процессора, их можно выполнить во втором потоке. Затем, как только вы поняли, где все рисовать, вы можете сделать вызовы open gl из первого потока. - person Ryan Stout; 18.06.2017
comment
Надеюсь, я понял правильно: моя первая диаграмма показывает поведение libGDX по умолчанию, а последняя возможна с использованием другого потока. - person Benedikt S. Vogler; 18.06.2017