#77

Game Ready Driver
Версия: 581.57 — Дата выпуска: 14 октября 2025 (Список изменений)
Windows 11/10

GeForce Hot Fix Driver
Версия: 581.47 — Дата выпуска: 30 сентября 2025 (Список изменений)
Windows 11/10

Linux Display Driver
Версия: 580.95.05 — Дата выпуска: 30 сентября 2025 (Список изменений)
Linux

Legacy

• Часто задаваемые вопросы
• Как и куда писать об ошибках в драйверах?
• Официальный форум Nvidia
• База знаний

Смежные темы:
• NVIDIA Resizable BAR
• RTX Video Super Resolution
• NVIDIA App. Обсуждение и настройка
• Игры с поддержкой RT и DLSS / FSR / XeSS
• DLSS, FSR, XeSS - производительность и качество

тоже играю с локом в 62 кадра + фастсинком с 3 заранее подготовлеными кадрами на 120гцевом монике тиринг отсутсвует, в новых играх типа квантумбрейка и так и так меньше 60 падает, а с всинком я бы получал 30, а в старых\не нагружающих чип зря не молотит видяшка холодная

Фаст, в отличие от всинка, не режет фпс на частоте развёртки. У нас же спор идёт несколько о другом: Всё о GeForce для Windows Vista/7/8/8.1/10 [WHQL: 375.70 от 28 октября] #14219419

Alex TOPMAN я как раз к этому и говорю - при всинке просело в игре до 59 фпс на мгновенье, хлоп получи на выходе 30, с фаст синком так и будет 59 и как только вернется до 60 устаканится локом, как я выше написал пока тиринг на глаза ни одной игре не попадался

deimos_mdg, у тебя срабатывает простая крестьянская логика. Монитор 60Гц, всинх ограничивает до 60Гц, всё... зачем, мол, типа, еще и ограничение на 60 кадров ставить?..
Но не все так просто) всинх не просто ограничивает частоту кадров до частоты развертки монитора, но и синхронизирует каждый кадр, вследствие чего возрастает комически задержка ввода-вывода. Т.е. по простому, ты мышкой влево повернулся в BF4, например, пока синхра там кадры лишние пропустит, возьмёт только то, что ей надо, ты этого поворота своего, которого ты в риал-тайме сделал мышкой - НЕ УВИДИШЬ!
так и в Ведьмаке есть прикол такой, всинх включен 60гц, но ФРЕЙМТАЙМ скачает от 16.6мс до 23мс, видно как фризит изображение, как только делаешь принудительный лок фпс на 60 кадров, фреймтайм стопорится на 16.6мс и всё плавно без рывков. ВОТ О ЧЁМ Я)))

Добавлено спустя 2 минуты 22 секунды:

Вот, вот, хлоп и до 30 режет. А когда делаешь ограничение FPS в RTSS или в дровах через инспектор - нет никаких скачков вниз до 30 кадров. Я не понимаю в чем прикол, но это так!

Подскажите, Shadow Play в последнем драйвере 375.70 убрали? Всё облазил-не нашёл. Можно ли как-то вернуть?

Cooper можно отдельно скачать, если что.
http://www.nvidia.ru/object/geforce-experience-ru.html
Но вообще вроде бы он там был.

Новый режим появился электропитания "Оптимальное энергопотребление", в довесок к адаптивному и максимальной производительности, настолько новый, что даже нет его описания в подсказке. Никто не в курсе, что за зверь, с чем едят?

чо там на 375.70 с инпут лагом?

Retvizan он там уже сто лет как бы

C tweakguides инфа: Optimal Power As of the 368.22 GeForce drivers, a new Optimal Power mode is available and set as the default. As yet I can't find an official Nvidia source to reference what this option does, but it was apparently alluded to at some point in the GTX 1080 launch conference. Basically, when Optimal Power is selected, while the PC is idle and nothing is changing on the screen, the GPU will not render any new frames; the driver will simply re-use the last rendered frame in the framebuffer. This should further reduce power consumption without any negative performance impacts.

Нет у всинха такого параметра, это вообще отдельный параметр - количество заранее подготовленных на цпу кадров для отправки их видеокарте, при дефолтном значении "контролируется 3D приложением" этот параметр может быть абсолютно разным в разных играх - его выбирают сами разрабы в зависимости от процесорозависимости ихней игры, ручное же увеличение этого параметра не заставляет молотить карту больше фпс а просто цпу выдаёт видеокарте кадры с опозданием в несколько кадров которые он "придерживает в очереди" таким образом достигается более равномерные промежутки времени между кадрами так как у цпу есть небольшой запас по времени что бы их выровнять но при таком подходе увеличивается задержка ввода ибо нажатие клавиш будет отображено на экране только через те самые несколько кадров. Для всинх же есть несколько другая похожая опция - тройная буферизация - к двум дефолтным кадровым буферам добавляется ещё третий - для облегчения видеокарте в синхронизации с частотой обновления монитора, если например в дефолтном режиме с всинх карта отправляет на монитор кадр из второго (последнего по дефолту) буфера а в первый буфер гпу ещё не закинул следующий (тупо не успел, не справился) то на следующий "тик" обновления монитора видеокарта ещё раз отправляет тот же самый кадр из второго буфера, то есть мы увидим на мониторе два абсолютно идентичных кадра подряд что на глаз воспринимается как очень кратковременное замирание картинки на месте или попросту "фриз", так вот при тройной буферизации видеокарта отправляет кадры на монитор из третьего (опционно дополнительного) буфера а во втором всегда уже будет на очереди ждать готовый следующий кадр (если вдруг не произошло уж очень сильного и резкого падения производительности, например на экране всё спокойно и вдруг происходит взрыв на весь экран с разлетанием всякой хрени и обсчётом физики), при этом третий буфер так же как и в случае с цпу увеличивает задержку вывода( при 60фпс 16мкс).

16 мс

А такую опцию как "адаптивная вертикальная синхронизация" вы за два года так и не заметили ?

GeForce 375.76 hotfix

" Occasional flicker on high refresh rate monitors
Artifacts in GIFs|
"

http://nvidia.custhelp.com/app/answers/detail/a_id/4250

Да это понятно всё. Я образно выразился. Потому как без всинка карта получит и использует все кадры от цпу, хоть ты выставь 1, хоть 11, а поэтому без ограничивающих частоту синков он и не работает, хоть и включеннным может стоять. Про специально задерживать кадры до накопления равно выставленному значению, а потом отдавать их карте - это же бред полный. Никакому выравниванию это не способствует, т.к. сложность сцены резко меняется ну крайне редко, а это значит, что если цпу не успел 1 кадр, то и 2 и 3 и 11 он скорее всего так же не успеет и лага не миновать.
И я не писал что карта станет рисовать больше. Я это как раз про цпу. И парню я тут и объясняю, что лок нужен чтобы в первую очередь именно цпу отдыхал. А он мне объясняет, что отдых цпу сам всинк вполне делает. Читайте нашу болтовню с самого её начала.
И ещё:
1. Постарайтесь не совать везде объяснения через тройную буферизацию. Более 95% игр идут на директе, а тройная есть только в опенгл (rtfm, please).
2. На жк мониторы не нужно отправлять повторно точно такой же кадр. Он не потухнет, а продолжит гореть. Это не ЭЛТ мониторы. И дрова об этом прекрасно знают. Так что тут, вместо "повторно отправит" лучше подойдёт термин "дождется следующего кадра и только тогда продолжит отправку на монитор".

Добавлено спустя 48 минут 56 секунд:

"Я тебя полюбил, я тебя - и научу" (С) известное кино
Без лока, цпу загружен под завязку - всегда. И ситуация, когда тик синка монитора (условно: "запрос от монитора на выдачу кадра", если так понятнее ) приходит раньше готовности последнего кадра довольно часта. ЦПУ тут некуда деваться, кроме как (внимание!) полностью закончить работу над уже начатым кадром (т.е. дорисовать всю геометрию). Итог: теряем 1 синк и автоматом падаем с 60 до 30 фпс (по мониторингу) в ожидании следующего синка. Когда же при локе цпу недогружен, то он может выбрать и сделать 2 вещи:
1. сразу нарисовать следующий кадр и далее курить бамбук.
2. сначала покурить, а уже потом нарисовать следующий кадр, причём ровно к тому моменту, когда (с учётом времени на работу ГПУ) потребуется его выдать на экран.
Понятно, что умные люди выбирают второй вариант, т.к. за прокуренное время можно словить ещё несколько инпутов от клавы и мыши и нарисовать юзеру именно последнее его состояние (раз все состояния его всё равно не интересуют - он же лок поставил), а не первое состояние (которое гораздо дальше в прошлом), после только что показанного на экране. Согласитесь - это разные вещи. В первом случае, образно, юзер видит почти такой же предыдущий кадр, а не своё обновлённое состояние, что и называется в народе как: "показывает вроде 60, а на глаз как 30 (ил любое меньше 60 число) фпс".
Про Риву: я не буду утверждать , что господин Николайчук (он же мистер Unwinder) сделал ровно как я тут и расписал, но то, что он очень умный товарищ - это однозначно.

Alex TOPMAN

https://graphics.stanford.edu/~mdfisher/GPUView.html
https://habrahabr.ru/post/308980/
http://http.developer.nvidia.com/GPUGem ... _ch28.html



На примере d3d,можно установить произвольное количество back буферов(0-3),на этапе инициализации контекста рендеринга (d3dpresent_parameters) и реализовать тройную буферизацию(2 бэк буфера+1 основной) -реализуется разработчиками через настройки игры/движка,или сторонние утилиты. По всинк и конвеер рендера цпу-гпу почитайте-в ссылках много полезного.

RTFM! Это только через драйверную панель оно со времен висты не включается, когда они видеоподсистему полностью переделали. А сам директ хоть 8 буферов может создать, просто делать это должен сам разработчик. Поэтому есть игры где все нормально и плавно, а есть где резкие провалы с 60 до 30, 20 и 15, это значит что индусокодеры забыли организовать 3-й буфер при синхронизации. А возможно и сделали так намеренно, рассчитав игру под онлайн-задрота - ведь в этом случае лишний буфер смерти подобен, инпут-лаг и все такое.. да, да, это был камень в сторону онлайн-задротов третий буфер из-за вас не сделали, нормальные геймеры страдают

это давно не так, много игр используют эту настройку, например титан квест еще в 2007 году имел ее в опциях игры, сейчас играю в шадоу вориор 1-2, там она так же есть.

а что тогда делает этот параметр в настройках игры - например overwatch?