> Для этого придумали VSync, чтобы refresh rate приложения был равен refresh rate-у экрана.А что делать, если обсчет эффекта или декодирование кадра видео заняло больше времени чем ожидалось? На выбор вроде или РЕЗКО обрушить FPS или тирингануть. Freesync в таком случае как я понимаю может просто задержать вывод кадра в провод пока он не будет по факту готов.
> И, кстати, дело не только в тормозах, РАЗРЫВЫ появляются даже
> когда refresh rate в приложении выше герцовки монитора.
А не должны были? Если представить как программа заполняет VRAM и как хардвар сканит VRAM в провод, можно осознать что есть минимум 2 РАЗНЫХ варианта как продолбаться:
1) Софт рисует "медленно", хардвар сканит "быстро". В этом случае может настать момент когда scanoout догонит точку рисовки софта, на экране будет часть нового и часть старого фрейма.
2) Софт рисует настолько быстро что обгоняет scanout. В этом случае перезапись кадра софтом обгонит scanout железки и будет - то же самое, но чуть по иной причине.
В этом месте мы понимаем в чем прикол с page flipping, double buffer и всем таким: можно рисовать софтом в неактивный буфер и переключать 2 буфера по мере готовности. Теоретически, при этом не может быть половинок кадра. Железо всегда выдает либо старый либо новый кадр, и под железкой кадр никто не меняет.
Практически, это требует экспорт ОЧЕНЬ ТОЧНОЙ инфо о тайминге из драйвера и готовность софта с этим столкнуться (DRM/KMS в том числе и про это). Иксы с прицелом на это так то тоже не создавались. А те мегакостылищи которые туда вбили для этого - работают очень так себе. И что там де-факто получается, да еще с учетом композитинга, приделаного на сопли и скотч, это такой сильно отдельный вопрос. Реально оно в некоторых конфигурациях все равно ухитряется тиринговать. И за цать лет борьбы с тирингом полностью и на 100% его так и не загасили. И это буллшит, господа. В этом месте возниакют вполне логичные вопросы: почему после такого слива времени кодеров в унитаз все равно такой результат?!
> Freesync - это по сути улучшенный VSync, но когда монитор подстраивается под
> refresh rate приложения, а не наоборот.
Freesync это IIRC динамический фреймрейт, когда кадр можно в принципе задержать, дав софту его дорендерить и только тогда пулять в провод. В принципе это логичное расширение логики scanout, плевать кадр в провод тогда когда он по факту готов, а не что-то еще. При этом минимальная задержка из возможных и нет причин для тиринга.
В чем принципиальная проблема для иксов и т.п.? При этом больше нет FPS как такового. Он не есть константа - и такое изменение сильно вылезает за допущения дофейхоа кода. И как я понял кодеры вообще не считают реальным отрефакторить иксы на ТАКИЕ реалии.
> Это даёт более плавную смену кадров. Вот только на десктопе это бесполезно практически,
Почему бы это бесполезно? В полной реализации может
1) Убить тиринг на корню, пуляя кадр когда он совершенно точно готов, целиком.
2) Снизить латенси и дергания, ведь если мы не успели в текущий scanout совсем чуть чуть, придется туповэйтить почти целое время между кадрами до следуюшего шанса. А тут, вот, scanout немного придержат и запустят его когда со стороны софта все готово.
Само по себе требование именно постоянного FPS в принципе высосано из пальца. Никаких объективных причин делать это так и только так в общем то нет. И по мере улучшения железа GPU и мониторов это дотумкало.
> тем более когда может быть так, что у разных приложений разный refresh-rate,
Ну вот тут уже пардон. Либо кто-то типа композитора это агрегирует, найдя общий знаменатель и точки синхронизации, либо вы пролетаете.
> 30 кадров в секунду, то весь десктоп обязан лагать? В играх
> всего один фреймбуфер на весь экран, тут понятно.
А зачем лагать? Если FPS = 60, то казать кадр того с 30 FPS по 2 раза. В более фундаментальном решении - привязывать точки синхронизации и отправки фреймов в провод по мере готовности, деферять немного апдейт региона для программы которая не успела и scanout уже запущен, например тем же даблбуферингом.
В общем то чтобы тиринга не было на самом деле надо лишь обеспечить принцип "all or nothing", чтобы рендер от программы не мог вклиниться в хардварный scanout. У иксов с этим гигантские проблемы. Так, по жизни.
