Устраняет ли функция opengl замораживание основной нити?

Question

Итак, когда вы вызываете функции opengl, такие как glDraw или gLBufferData, вызывает ли поток программы останавливаться и ждать завершения GL-вызовов?

Если нет, то как GL обрабатывает важные функции, такие как glDraw, а затем сразу же после изменения параметра, который влияет на призывы рисования?

Answer 1

Нет, они (в основном) нет. Большинство функций GL буферизуются при их использовании и фактически выполняются позже. Это означает, что вы не можете думать о процессоре и графическом процессоре, поскольку одновременно работают два процессора. Обычно CPU выполняет кучу функций GL, которые получают буферизацию, и, как только они доставляются на графический процессор, они выполняют их. Это означает, что вы не можете надежно контролировать, сколько времени потребовалось для выполнения конкретной функции GL, просто сравнивая время до и после его выполнения.

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

С другой стороны, я сказал «в основном». Это связано с тем, что функции чтения фактически НЕОБХОДИМО синхронизировать с графическим процессором, чтобы показать реальные результаты, и поэтому в этом случае они ждут и замораживают основной поток.

Редактировать: Я думаю, что само объяснение отвечает на заданный вами второй вопрос, но на всякий случай: тот факт, что все вызовы буферизованы, позволяет выполнить ничью, а затем изменить настройку для успешных вызовов

Answer 2

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

Объекты OpenGL (текстуры, буферные объекты и т. Д.) Являются чисто абстрактными и по спецификации дескриптор объекта в клиентской программе всегда относятся к данным, у объекта есть время вызова функций OpenGL, относящихся к этому объекту. Так возьмите, например, эту последовательность:

glBindTexture(GL_TEXTURE_2D, texID); 

glTexImage2D(..., image_1); 
draw_textured_quad(); 

glTexImage2D(..., image_2); 
draw_textured_quad(); 

Первый draw_textured_quad может вернуться даже задолго до того, что-то было обращено. Однако, делая вызовы, OpenGL создает внутреннюю ссылку на данные, которые в настоящее время удерживаются текстурой. Поэтому, когда glTexImage2D вызывается во второй раз, что может произойти до того, как был сделан первый квадрат, OpenGL должен внутренне создать вторичный объект текстуры, который должен стать текстурой texID и использоваться вторым вызовом draw_textured_quad. Если было вызвано glTexSubImage2D, ему даже пришлось бы сделать модифицированную копию.

Звонки OpenGL будут блокироваться только в том случае, если результат вызова изменяет память на стороне клиента и зависит от данных, сгенерированных предыдущими вызовами OpenGL. Другими словами, при выполнении вызовов OpenGL реализация OpenGL внутренне генерирует дерево зависимостей, чтобы отслеживать, что от этого зависит. И когда точка синхронизации должна блокировать, она будет по крайней мере блокироваться до тех пор, пока не будут выполнены все зависимости.