krv2k, Наоборот — Adaptive Sync основан на FreeSync. Нет, не описывает. Только требует, чтобы каждый кадр был выведен. Проверяется это специальной прогой и обычной зеркалкой на штативе.
Вообще стандарт G-Sync/FreeSync не обязан описывать, что делать монитору в этой ситуации. И только G-Sync, который главная микросхема, общая для всех одноимённых мониторов, известно, что пытается обойти.
krv2k, Куда ни кинь, всё клин. G-Sync постоянно прикидывает, что лучше: обновить наперёд или ждать до последнего. И источник говорит, что на синтетическом тесте это вышло лучше, чем у FreeSync-монитора.
krv2k, Проблема в том, что игровая система в виде игрового движка, процессора и видяхи тоже плохо знает, когда будет кадр. Только появившийся в 2020 году nVidia Reflex, объединяющий в одну систему движок и видяху, используется именно для этого — правда, не чтобы обходить такое вот редкое явление, когда тормозят и без того тормозную игру, а чтобы ещё уменьшить задержку от кнопки до изображения.
krv2k, Монитор не знает и не может знать, откуда взялся конкретный пиксель кадра. Главное ему знать, что реально видно на матрице, чтобы продолжать улучшать картинку.
Ну конечно, с запозданием. Но, поверьте, это не слишком частая ситуация: игра выдала один кадр грубо за 1/40 секунды, следующий за ним — за 1/140. Как ведёт себя монитор в такой ситуации, когда один кадр-заика привёл к столкновению, а дальнейшие быстрые кадры заблокировали игру в таким режиме,— неизвестно.
krv2k, Улучшайзеру главное знать, что видно на мониторе сейчас. А для этого надо записать, куда мы бахнули овердрайв, сколько времени прошло и как ведут себя ЖК-ячейки на конкретной панели.
Я тряхнул имевшиеся (давно найденные) источники, и написал вот что в Википедии.
Если в этот момент придёт новый кадр, случится столкновение или коллизия кадров, и простейшее (замеченное на раннем FreeSync-мониторе) решение — переждать обновление и вывести кадр с запозданием, что означает замедление и без того медленной игры
Улучшайзеру хотя бы нужно знать, постоянное изображение или нет.
Сунувшись в статью Википедии про G-Sync (частично мою), я так и не нашёл, откуда я взял, что коллизия кадров — это разрыв. Сейчас я бы предположил, что оба решения — начать развёртку с начала и придержать кадр — так себе. Первое — это разница в цветах на только что обновлённом и давно не обновлявшемся куске кадра. Второе — опять-таки, плевок в лицо системе, призванной снизить задержку.
krv2k,
1. У всех современных мониторов есть полный кадр просто для работы улучшайзеров. Чтобы приблизительно понимать, что творится на экране. А в модуле G-Sync™️ вообще едва ли не гиг памяти.
2. Мы делаем систему, призванную снизить задержку от кнопки до изображения. Модет, лучше разрыв?
1. Да.
2. Да.
3. Не в курсе, но подозреваю рабочую частоту — так меньше глюков из-за странного монитора, 10-метрового кабеля и прочего. К тому же скоростные мониторные кабели содержат больше пар.
4. Монитор сам делает обновление матрицы имеющимся кадром, когда совсем уж невтерпёж, понимая, что если в этот момент придут данные с видяхи, будет разрыв. На настольном. В мобильных системах многое что идёт прямо на вычислительном ядре видяхи.
krv2k, Да, совершенно верно. Мало чем отличается от кинескопов, и сам факт, что задержки между строками и кадрами можно сильно уменьшить по сравнению со стандартными, и позволяет разогнать монитор.
Разрыв случается, если кто-то обновит данные в буфере или переключит его (сделает передним другой буфер), пока идёт передача кадра.
При вертикальной синхронизации переключение буферов (реже перезапись) происходит между кадрами.
Протоколы были разработаны на заре ЖК с оглядкой на кинескопы, но оказались достаточно удачными и для ЖК.
krv2k,
Идеал — передавать данные ровно тогда, когда монитор их захочет. И современный протокол — при условии, что матрица одна и нет G-Sync — достаточно близок к этому.
Мобильные устройства действительно имеют дело с видяшным буфером. Но это имеет один минус: у них с апскейлерами швах. А может, и не швах, а фича — определённые разрешения показываются в окошке, а не на весь экран.