evirus
> В документации это сказано?
Ну во первых - это общеизвестный факт. =)
У тебя на экран ничего не попадет пока SwapBuffers не сделаешь.
Во вторых:
http://www.opengl.org/wiki/Platform_specifics:_Windows
When do I render my scene?
SwapBuffers( ... ) // Swap buffers to make geometry visible on screen
В третьих:
http://www.opengl.org/wiki/Common_Mistakes
"glFinish and glFlush"
The SwapBuffer command takes care of flushing and command processing.
Здесь не сказано явно, что свап буфера должен ожидать выполнения команд, но по факту так реализуется wglSwapBuffers во всех драйверах.
(Это не гарантируется хотя бы по тому, что в современных драйверах реализован Triple Buffering, который через настройки драйвера можно включать\выключать,
поэтому теоретически иногда это может быть и не текущий кадр. Но эта функция используется при V-Sync. )
В четвертых:
http://msdn.microsoft.com/en-us/library/dd369060(v=vs.85).aspx
The SwapBuffers function exchanges the front and back buffers if the current pixel format for the window referenced by the specified device context includes a back buffer.
Здесь вообще не говорится о том, что SwapBuffers должен ожидать выполнения команд.
Тогда в этом случае вообще стоит делать так что бы увидеть текущий кадр на экране:
glFinish(); // а вот здесь гарантировано есть ожидание выполнения
SwapBuffers();
> Синхронизация с мониторной частотой есть?
В SwapBuffers - нет.
Для достижения вертикальной синхронизации используется другая функция.
> Как проверял что ждет именно текущий, а не предыдущий кадр?
Пошагово - в дебаггере, ок?
На счет дропов незнаю, помойму их нельзя обычнимы OGL средствами отловить (Возможно я ошибаюсь и знающие люди подскажут),
я например вручную ограничиваю фпс до 60, и свободное время трачу на другие задачи.
false3d
> Пошагово - в дебаггере, ок?
^_^
KpeHDeJIb
> false3d
> > Пошагово - в дебаггере, ок?
> ^_^
=)
false3d
> Ну во первых - это общеизвестный факт. =)
Или общеизвестное заблуждение =)
> SwapBuffers( ... ) // Swap buffers to make geometry visible on screen
> The SwapBuffer command takes care of flushing and command processing.
> The SwapBuffers function exchanges the front and back buffers if the current
Это команда для гпу, которая попадает в очередь команд. Flush отдает команду гпу. Противоречий нету. Никто не мешает гпу выполнить команду асинхронно позже. Даже если ты поставишь query, то не поймаешь момент, в который драйвер переключит указатели.
> glFinish(); // а вот здесь гарантировано есть ожидание выполнения
> SwapBuffers();
Это ожидание выполнения команды, т.е. момента когда гпу отработает команду, но не момента когда буфер будет показан на экран.
> > Как проверял что ждет именно текущий, а не предыдущий кадр?
> Пошагово - в дебаггере, ок?
Асинхронный дебагер? Квантовый компьютер, не? =)
> На счет дропов незнаю, помойму их нельзя обычнимы OGL средствами отловить
> (Возможно я ошибаюсь и знающие люди подскажут),
> я например вручную ограничиваю фпс до 60, и свободное время трачу на другие
> задачи.
Это по временной диаграмме исполнения можно видеть при v-sync. Сделай раз в N кадров Sleep на 16 ms, например. Если последующий кадр занимает меньше времени, чем предыдущие - это как раз дроп зажевало. Т.е. схема какая получается. Девайс быстро забивает буфер кадров и начинает спать на Swap (ждать места в буфере), поскольку нету места куда сложить кадр для вывода на экран. Если ты сделаешь Sleep(16 ms), то плата успеет переключить один-два кадра (v-blank). Поэтому следующий кадр не уснет на Swap (буфер свободен).
В общем, на сколько мне известно, буфер кадра лежит на плате в двух местах: в обычной видеопамяти и в спец памяти, откуда показывается на монитор (для упоминания далее, назову dvm - точное название не помню). Поэтому swap, как я понимаю, это просто копирование туда. Если используется двойная буферизация, то буфера два в обоих местах. В итоге, девайс застревает когда он не может скопировать mem->gpu. Когда это происходит? - когда текущий кадр еще на экране и v-blank не произошел. Как только v-blank происходит, указатели переключаются и активный ранее dvm-буфер освобождается. Тогда GPU копирует туда данные и команда Swap считается выполненной. Поэтому при двойной буферизации swap ждет именно v-sync предыдущего кадра - интернет утверждает, что на большинстве платформ так. Лично сам проверял на PC из под dx11.
evirus
http://opengl.gamedev.ru/doc/?func=glFinish - тут на русском написано. Может так понятней будет. =)
false3d
Выполнить команду swap != показать картинку. В тот момент, когда swap вернуло управление, никто не гарантирует, что пользователь уже видит этот кадр.
glFinish дожидается выполнения команд, но результат swap "падает в буфер, а не на экран" (в случае двойной буферизации). Хотя то, что кадр готов уже, верно. Swap ждет момент, когда предыдущий кадр появится на экране, если этого еще не произошло.
ладно, не суть, мы уже говорим о разных вещах :)
обновил статью
evirus
> Выполнить команду swap != показать картинку.
При включенной вертикальной синхронизации согласен.
Но когда она отключена (режим по умолчанию), swap == показать картинку. Функция свап возвращает управление после того как пользователь уже видит картинку.
Я не знаю как у вас там в DX, но у меня в OGL просто:
1. Создал контекст
2. Проинициализировал дефолтовые стейты ОГЛ
3. Вызвал DIP (с одним треугольником)
4. SwapBuffers
5. Следующая команда
Иду пошагово по каждому из этих шагов. Как только управление вернулось из SwapBuffers, окно тут же обновилось и я вижу картинку.
Вертикальная синхронизация выключена, а буфер явно больше чем на один треугольник...
Ты хоть когда нибудь писал что нить на огл? Или сэмплы хоть запускал какие? Или это все домыслы?
ЗЫ: Ты не одного пруф линка по своим доводам не предоставил даже
false3d
> Иду пошагово по каждому из этих шагов. Как только управление вернулось из
> SwapBuffers, окно тут же обновилось и я вижу картинку.
Хм. Куда интересно делась буферизация команд для гпу на несколько кадров вперед.
> Ты хоть когда нибудь писал что нить на огл? Или сэмплы хоть запускал какие?
Да.
> Или это все домыслы?
Это не домыслы, а изначально был вопрос к тебе - как это устроено в OGL?
> Ты не одного пруф линка по своим доводам не предоставил даже
Про память - я пока не нашел его, читал давно. Про ожидание по swap - это от драйвера зависит и я не видел документа где бы черным по белому это было сказано. В интернете есть посты в блогах на эту тему. Тут в соседней теме ссылка была, но там касательно dx9. Я тоже самое вижу на dx11. Про огл - не знаю, но сомневаюсь, что одна железяка работает по-разному. Вот и выясняю у тебя.
Как проверить чья правда, я написал - добавить sleep раз в N кадров и посмотреть статистику времени. Для vsync.
Без vsync - просто посмотреть статистику времени. Есть ли выброс раз в N кадров. И понятно что он может быть только без Flush и Finish. Их вызов ломает буферизацию команд для гпу на несколько кадров вперед. Хотя, для ровного фпс она и не нужна.
evirus
> Про огл - не знаю, но сомневаюсь, что одна железяка работает по-разному. Вот и
> выясняю у тебя.
Я думаю вопрос буферизации команд больше относится к драйверу чем непосредственно к железке.
Для огл в драйвере свой path для дх свой.
А то что свап бафферс ожидает завершения выполнения команд, то это просто факт. Хоть это не регламентируется стандартом (или я не нашел где это указано), но всегда было так.
Вообще свап бафферс это очень важная функция, например в gDebugger, она выступает как один из брейкпоинтов или правильней сказатьразделителей кадров, позволяя просматривать текущие рендер таргеты и состояние конвеера, текстуры и тд. То есть все ресурсы которые изменились за промежуток времени между двумя вызовами SwapBuffers.
Если бы команды не исполнялись при свапе, тогда в этом бы не было особого смысла.
Кстати, как подобное организовано в перв'худе? Там мы просматриваем предыдущие кадры во время свап бафферс?
false3d
> Если бы команды не исполнялись при свапе, тогда в этом бы не было особого
> смысла.
Никто не мешает дебагеру просто дожидаться момента, когда команды исполнятся (по query).
> Кстати, как подобное организовано в перв'худе? Там мы просматриваем предыдущие кадры во время свап бафферс?
Давно использовал, не знаю. Использую PIX. Он делит кадры по Present (аналог swap).
evirus
> Никто не мешает дебагеру просто дожидаться момента, когда команды исполнятся
> (по query).
В г дебаггере возможно, но что насчет простого дебаггера, там никто квери не ждет.
evirus
> делит кадры по Present (аналог swap).
То есть по квери ожидает конца кадра?
false3d
То, что ты видишь в дебагере после исполнения строки сразу картинку возможно от того, что время кадра маленькое - ты просто не замечаешь ожидание.
Драйвер должен буферизировать кадры (число указано в NVPanel, например). glFlush - принудительно заставляет отправить их гпу. glFinish - дождаться, пока они не выполнятся. Так?
Если выполнился swap, то это лишь значит, что кадр был скопирован в спец память и будет показан позже - как только железка посчитает нужным. Без vsync это будет происходить почти сразу. Железка переключит указатель на видеостраницу и на экране будут рисоваться данные уже с готового кадра. Правда, на счет вот этого момента у меня нет точной информации - в блогах читал.
Как работает внутри PIX нигде не сказано. Никто не мешает ожидать. Скорей всего он просто подменяет функции (передаваемые данные) и добавляет в каждую на вход и выход query_timestamp+query_joint. Потом, в каждом Present, проверяет какие query готовы и записывает статистику времени исполнения.
evirus
> То, что ты видишь в дебагере после исполнения строки сразу картинку возможно от
> того, что время кадра маленькое - ты просто не замечаешь ожидание.
Непонял, какое время маленькое?
Ты не много меня запутал.
Я говорю что когда вызывается Swap, то по факту происходит флуш команд, ожидание их завершения, и только потом возвращается управление.
Про в синк и про то когда именно кадр показывается - я про это не говорю. Понятно что при всинке видюха будет ждать развертки, при отсутствии - сразу выводиться.
Но изначально речь шла именно о том что управление из свапа не возвращается пока команды не будут исполнены а не сразу... А если так и нет синхронизации, то понятное дело кадр сразу покажется - чего ему ждать...
false3d
> только потом возвращается управление.
да это так
> понятное дело кадр сразу покажется - чего ему ждать...
вероятнее всего именно так - это уже детали реализации видюхи. Плата это сделает как можно быстрее и задержка даже если и будет, то не существенная (мизерная).
Я и писал выше мы уже говорим о разных вещах
> когда вызывается Swap, то по факту происходит флуш команд, ожидание их завершения
А точно ли Finish происходит? Флуш да, должен быть обязательно, но ожидание их завершения - это весьма странно, т.к. так не будет работать буферизация команд на несколько кадров вперед
ЗЫ Сожалею, что развели тут офтоп.
Тема в архиве.