Member
Статус: Не в сети Регистрация: 28.02.2008 Откуда: Калининград Фото: 99
ZltCity писал(а):
Ну полную бессмыслицу же написал. Каким образом "кадровый буфер очищается сразу, как только готов новый кадр" гарантирует "что самый свежий кадр будет выведен максимально быстро"? Что это вообще должно значить? Давай оригинальную цитату.
Учи матчасть и перечитывай цитату до полного просветления. Никакой оригинальной цитаты в природе не существует т.к. у этой опции нет развернутого "официального" описания. Есть результаты измерений и у части людей есть достаточно ясное понимание того как работает вся цепочка рендеринга. Коротко суть такова, в кадровом буфере может находиться несколько готовых кадров, которые и представляют из себя очередь заранее подготовленных кадров. Средствами драйвера раньше можно было запретить буферизовать кадры, выставив значение "макс.кол-во заранее подготовленных кадров" = 0. Но на сегодня такая возможность отсутствует и в драйверах Нвидии и АМД и минимальное значение составляет 1. А Reduce buffering делает именно то что я описал, очищает любые накопленные драйвером во фреймбуфере старые кадры не давая драйверу их вывести, и вынуждая его выводить только самый последний (самый свежий) кадр. Немного измерений есть тут https://www.youtube.com/watch?v=sITJ3V_fyv4
Добавлено спустя 16 минут 9 секунд: Похоже я немного ошибся с терминологией, правильно должно быть не "кадровый буфер очищается сразу как только готов новый кадр", а "цепочка рендеринга очищается сразу как только готов новый кадр". Официальной цитаты по этой опции в Overwatch нет. Есть некоторый аналог d3d_antilag для DX9 и у него есть официальная цитата. Впрочем, я думаю что в DX11 нет необходимости полностью чистить цепочку рендеринга для достижения того эффекта что дает Reduce buffering, как раз потому что в кадровом буфере может быть несколько готовых кадров.
Цитата:
The render queue is flushed immediately when a frame is ready. This provides minimal latency, but can cause a significant performance drop.
Никакой оригинальной цитаты в природе не существует т.к. у этой опции нет развернутого "официального" описания.
Ну, вообще-то есть, хотя пускай и не развёрнутое. SetMaximumFrameLatency, если мне не изменяет память, существует ещё со времён Direct3D9. Валидные значения от 1 до 16, 0 сбрасывает в дефолт - 3 кадра. Что делал 0 в драйверах хз, но вряд ли то, что ты думаешь.
k2viper писал(а):
Коротко суть такова, в кадровом буфере может находиться несколько готовых кадров, которые и представляют из себя очередь заранее подготовленных кадров.
Не может. Кадровый буфер - область памяти, где лежит готовый кадр - растровове изображение(на самом деле есть нюансы, и определение framebuffer'а зависит от контекста). Но в любом случае, это никакая не очередь. И когда говорят про очистку буфера кадра, обычно имееют ввиду заливку всех пикселей каким-то одним значением. Поэтому твоё изначальное
k2viper писал(а):
Кадровый буфер очищается сразу, как только готов новый кадр, таким образом гарантируется что самый свежий кадр будет выведен максимально быстро
невозможно понять правильно. Каким образом очистка буфера кадра поможет вывести свежий кадр максимально быстро? Скорее уж наоборот.
k2viper писал(а):
Средствами драйвера раньше можно было запретить буферизовать кадры, выставив значение "макс.кол-во заранее подготовленных кадров" = 0.
Этот момент сомнителен. Как я уже писал выше, скорее всего, 0 делал не то что ты думаешь. Вот есть цитатка с форума nvidia
Цитата:
The option for 0 pre-rendered frames was removed because it is impossible to produce graphics with a setting of 0; a setting of 0 did not reduce the number of pre-rendered frames from 1. If you noticed a difference between either setting, it was not because there were 0 frames being prepared with one setting (again, that's impossible with the current graphics pipeline).
To reiterate: There can be no graphics without at least 1 pre-rendered frame. The 0 option was removed because it is nonsensical.
k2viper писал(а):
Похоже я немного ошибся с терминологией, правильно должно быть не "кадровый буфер очищается сразу как только готов новый кадр", а "цепочка рендеринга очищается сразу как только готов новый кадр".
Твоё "немного ошибся" переворачивает всё с ног на голову. Особенно забавно что ты пошёл что-либо гуглить и попытался исправить ошибку уже после того как послал меня учить матчасть
k2viper писал(а):
Официальной цитаты по этой опции в Overwatch нет. Есть некоторый аналог d3d_antilag для DX9 и у него есть официальная цитата. Впрочем, я думаю что в DX11 нет необходимости полностью чистить цепочку рендеринга для достижения того эффекта что дает Reduce buffering, как раз потому что в кадровом буфере может быть несколько готовых кадров.
Опять бессмыслица, что это должно значить? Как наличие нескольких кадров в очереди поможет нам достигнуть эффекта "reduce buffering"?
Member
Статус: Не в сети Регистрация: 12.03.2003 Откуда: Калининград
ZltCity писал(а):
По факту, k2viper написал ерунду и пока не ответил на конкретный вопрос. Ты же вообще ничего не написал по сути вопроса, просто выкрик из толпы не по теме. Это если говорить по факту, а не разводить тупой флуд. Я же не виноват что вы не в состоянии чётко формулировать свои мысли.
Тебе тут объяснили и намекнули. Но никто не обязан бороться с твоей неграмотностью.
_________________ Lorichic писал(а):Память покупается на весь срок жизни. АМ4 - Сокет свободных людей (с)XRR
Member
Статус: Не в сети Регистрация: 12.03.2003 Откуда: Калининград
ZltCity писал(а):
Да? А где? Мне лишь объяснили что объяснятели сами не понимают что объясняют
В данном случае твоя неграмотность - это то, что ты ищешь знакомые слова и пытаешься подогнать их значение под своё понимание мира. При этом выворачивая смысл того, что тебе говорят - "мясом наружу" Это называется "демагогия" - и ты - демагог. Если не знаешь, что это такое - ознакомься хотя бы со статьёй на вики.
_________________ Lorichic писал(а):Память покупается на весь срок жизни. АМ4 - Сокет свободных людей (с)XRR
В данном случае твоя неграмотность - это то, что ты ищешь знакомые слова и пытаешься подогнать их значение под своё понимание мира. При этом выворачивая смысл того, что тебе говорят - "мясом наружу" Это называется "демагогия" - и ты - демагог. Если не знаешь, что это такое - ознакомься хотя бы со статьёй на вики.
Как ты лихо назвал меня демагогом, при этом не написав ни одного сообщения по теме нашего с k2viper обсуждения. Ну так давай по делу, где я не прав? По пунктам, со ссылками на тех. документацию и официальную терминологию.
Твоё "немного ошибся" переворачивает всё с ног на голову. Особенно забавно что ты пошёл что-либо гуглить и попытался исправить ошибку уже после того как послал меня учить матчасть
Согласен, ошибка всё меняет. Я погуглил, убедился в том что допустил неточность и не стесняюсь об этом сказать Похоже я зря ассоциировал принцип работы Reduce buffering с прежним принципом работы DX9 antilag который работал на уровне рендерера, Reduce buffering более вероятно работает на самом первом этапе - игры. Кадровый буфер ему напрямую не должен быть доступен, однако буферы есть на каждом этапе и опция запрещает буферизацию 2 кадров на этапе позволяя буферизовать лишь 1 кадр gamestate.
Rendeding pipeline: Game -> Renderer -> Video card hardware -> Display (framebuffer)
Member
Статус: Не в сети Регистрация: 28.02.2008 Откуда: Калининград Фото: 99
ZltCity писал(а):
Как я уже писал выше, скорее всего, 0 делал не то что ты думаешь. Вот есть цитатка с форума nvidia
По поводу pre-rendedred frames 0 топик на форуме Нвидии очень большой и это далеко не единственная точка зрения которая там высказывалась. Я в свое время этот топик полностью прочел. Мне в целом понятно почему эту опцию убрали из драйвера, но факт остается фактом и люди приводили сравнения и измерения в том же самом топике: инпутлаг с 0 получался ниже чем с 1. Сравнивали в некой условной "старой" игре устанавливая старую версию драйвера 29х.хх и в сравнении с новой версией драйвера 30х.хх Вероятно, pre-rendered 0 на уровне рендерера запрещал дополнительную буферизацию, как Reduce buffering запрещает её на уровне игры.
И хотя мне понятны мотивы почему Нвидия убрала этот 0, но я жалею что возможность использовать 0 не оставлена даже для продвинутых пользователей понимающих что идут на риск. Очевидно что в старых играх вроде Quake live или CS 1.6 фпс на современных машинах не будет проблемой, а вот инпутлаг снизить желательно.
Я сам некогда оказался заложником, хотя и играл в старую игру (TF2), но "новый" на тот момент монитор VG278H с поддержкой Lightboost не хотел включать строб на старых версиях драйвера и мне приходилось ставить новые и лишаться pre-rendered 0.
Reduce buffering более вероятно работает на самом первом этапе - игры. Кадровый буфер ему напрямую не должен быть доступен, однако буферы есть на каждом этапе и опция запрещает буферизацию 2 кадров на этапе позволяя буферизовать лишь 1 кадр gamestate.
Да, только cами игры не вносят никаких задержек и не "буферизируют" кадры. Input lag появляется в виде обратной связи на цепочке api -> driver -> hardware. К примеру, если включён vsync, видеоадаптер ждёт момента, когда дисплей закончит вывод старого кадра, для swap'a(обмена) front и back buffer'ов, драйвер ждёт когда произойдёт swap буферов и back buffer будет доступен для рендеринга в него нового кадра, а приложение, в свою очередь, ждёт когда api вернёт управление из вызова present и после этого начинает готовить новый кадр. Или, если взять pre-rendered frames, где-то на стороне драйвера просто добавляется некая очередь кадров, куда кладутся подготовленные cpu кадры, а вызов present сразу возвращает управление, если в очереди есть свободное место. Соответственно, если gpu framerime больше чем cpu frametime, кадры накапливаются в очереди, состояние игрового мира(и пользовательский ввод) "убегает" вперёд от визуального отображения, пользователь ощущает input lag. В общем, суть в том, что игры сами по себе имеют довольно ограниченное влияние на всякого рода задержки, в конечном итоге всё зависит от возможностей графического api и общей "архитектуры" системы. Видимо dxgi позволяет каким-то образом снизить всевозможные задержки на пути кадра из приложения на монитор.
Member
Статус: Не в сети Регистрация: 28.02.2008 Откуда: Калининград Фото: 99
ZltCity писал(а):
Видимо dxgi позволяет каким-то образом снизить всевозможные задержки на пути кадра из приложения на монитор.
Определенно да, раз такие штуки как Reduce buffering становятся возможны.
Добавлено спустя 1 минуту 56 секунд: Кстати почему до сих пор нет "новости" и её обсуждения, что сразу следом за слухом о припое, китайские фанаты АМД на одном из форумов запустили слух что Зен2 будут уже не с 12, а аж с 16 ядрами в АМ4
Member
Статус: Не в сети Регистрация: 08.03.2009 Откуда: Лагань
ламеры смотрю ещё долго не вымрут. вроде и не плохой был ресурс, но стал просто отходным местом.
_________________ IOSS Weltron\ Терпеть не могу Mac и прочий хлам! EEPROM жил, жив и будет жить. Поставил первое окно в 2005г. До этого был Тонель и шляпа.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 4
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения