Поддерживаю

Материал придется перечитать еще раз, сходу не все улеглось (особенно про теоретический фпс-вывода на монитор)
Чертыхание кадров на старой нвидии перепроверить на новой линейке было бы очень ценно.
По поводу радеонпро имеет ли смысл для одиночной карты?
Вообще больше интересует не sli/cf, а попытка разработать методику которая максимально приближала бы к измерению реальных к/с и плавности к/с; и кстати, можно хотя бы теоретически оценить задержку вывода относительно игрового процесса?

а на каком мониторе проводился тест?

Все гениальное просто! Средствами собранными на коленке ткнуть носом главных производителей железа, - это круто!

Отличная статья, остаётся только на современных картах проверить и сравнить с результатами FCAT.

Вано, ты думаешь кто-то даст Сержу себя раскатать как каток раскатывает асфальт?

Forzay
Я об этом тоже подумал.
Хотя, если бы не хотели, уже после первой статьи в лабораторию бы обратились заинтересованные.
Но раз вышла вторая часть, а я оч.надеюсь, что будет и третья, то нет, наверное они катка не боятся или лаборатория им отказала.

Жаль не оказалось актуальных карт НВ. Мне кажется в выводах "увы" было бы использовано в отношении АМД.

Серж,мой вопрос скорее глупый, но всё же. Возможно ли что чехарда кадров на нвидиа вызвана латентностью по пересылке кадра в оперативку и последующей перегонке в кадровый буфер (если совсем уж упрощать), чем и обусловлена большая процессорозависимость карт нвидиа?

Вот вам обязательно нужно начать холивар? В статьях попытка докопаться до сути работы(реализованных решений) в железках/дровах, даже автор как я понимаю не до конца переварил полученные данные

Немного не понял, для cлучая FPS больше частоты развертки монитора и выключенном vsync , разве в этом случае не следует ожидать пропуска кадров ? Или всеже за 1-о обновление будет выводится 2 "полкадра", а в случае vsync вкл ?
И да , многопоточная обработка 1-го видеопотока (не знаю как правильно написать) может приводить к путаннице , только помоему эту путанницу вполне можно заблокировать , просто нумеровать кадры и пропускать меньший номер если старший уже на экране
А статья - действительно статья , правда требует напряч мозги

Дельное исследование, хотя и очень сухо написана теоретическая часть, но направление автором выбрано нужное и несомненно интересное.
Вот уж не думал, что нвидия так "оптимизировала" свои драйвера. Хорошо бы ещё протестировать не только с актуальным железом Нвидии, но и с включением-отключением опции "Потоковая оптимизация" в драйвере.

зы. Кто интересуется детальными оценками задержки вывода (инпут лага), крайне рекомендую англоязычную статью с Ананда http://www.anandtech.com/show/2803

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


Один из кадров отрисуется дважды, а какой-то может оказаться выброшен.



Можно, но это потребует дополнительного и достаточно длинного буфера вывода перед framebuffer'ом, как минимум кратного кол-ву потоков, что в результате приведёт к неприемлемому росту инпут лага.

вот это странно...
после переустановки Windows делали обновление? может библиотеки DirectX?
А вообще в очередной раз подтверждается бесполезность CF\SLI...

Почему не думал? "Кукурузная" производительность то у них всегда была просто великолепная, это косвенно намекает на результат исследования.

А не думал потому, что Нвидия продвигает 3D vision, который требует самого что ни на есть "честного" отрисовывания кадров с высокой частотой, с чередованием для левого и правого глаза. Легко понять, что в 3д режиме мухлёж с выбрасыванием и неверным чередованием кадров не пройдёт.
Впрочем, очень похоже что при активированной вертикальной синхронизации никакого мухлежа нет и кадры будут выводиться в правильном порядке. В 3Д режиме vsync также принудительно активируется. Так что не исключаю, что нвидия действительно мухлюет с многопоточной обработкой и фактической эмуляцией мульти-гпу конфигурации драйвером, даже на одиночных гпу.

Добавлено спустя 29 минут 44 секунды:
Данный вопрос меня очень интересует потому, что эмуляция мульти-гпу конфигурации предполагает что у каждого потока есть "свой" буфер вывода, и буфера всех потоков потом сливаются в backbuffer, и уже затем в front buffer и выводятся монитором. А дополнительная буферизация это не только расход памяти, но и дополнительный инпут лаг.

Я играю в быстрый шутер, и минимизация инпут-лага для меня имеет значение. Хотелось бы подробно понимать, что можно сделать для минимизации инпут-лага в "современных" условиях предположительной эмуляции мульти-гпу. Поэтому, как минимум очень бы хотелось, чтобы автор в дальнейших исследованиях проверил это предположение

Статью смело можно вносить в лучшее за последние несколько лет!
Очень жду продолжения с 7 серией Ати в тандеме и отдельно, то же с Нвидией. Не обязательно Кеплер, 670/680 вполне. Неужели не найти карт на тестирование?
Хотелось бы так же сравнить все эти варианты на платформе Интел и АМД. Понимаю, что такие желания это безумная куча гемора, но может хоть что то из этого точно сможете!?
Спасибо!
ЗЫ Только драйвера пожалуйста не используйте Бета.

Всю линейку проверять ИМХО нет необходимости - достаточно по 1 видеокарте Кеплер и Ферми, 6/7 серия АМД - тенденции будут понятны сразу.
Моя мечта ещё и детальное исследование инпут-лага, но и без этого уже очень острая тематика затронута.

Интересно было бы и про нВидиа почитать современные, исследовательскую статью этого вопроса. И исследования, возможные варианты решения этой проблемы.

Да, промазал, извиняюсь. Дело в том, что на "рабочем" компьютере установлена ХР (х64) и перестанавливать OS никто не позволит.

Rimsky, речь шла о компании AMD.


Если дико утрировать, причем предельно дико, то именно так работает самодельный "балансировщик". Чем ниже производительность процессора, тем больше шансов у видеокарты вылезти из "штопора" спаривания кадров (в статье этот момент отмечался). Вполне очевидно, что сильное снижение скорости процессора, тем менее шумная будет последовательность кадров. В первом приближении, это действие эквивалентно включению Vsync, только этот порог декларируется не кадровой разверткой, а производительностью процессора.


1 - Статьи оформляются не один день. Я не помню точную дату передачи статьи на публикацию и выход этой bet'ы, где-то примерно в этот день. Возвращать статью и проводить повторное тестирование под очередную бету? Смысл? Будет релиз, тогда и стоит что-то делать.
2 - этого я не делал. Я лишь проверил характер поведения драйвера под эту редакцию DirectX и получил тот результат, что драйвер ведет себя "безобразно". Это говорит о том, что драйвер под Dx9 будет переделываться. Есть шанс, что в 13.8b2 его подлечили, но - см. п1.


IMHO, несомненно. Например, ради динамического Vsync (а лучше двойного Vsync). При снижении ниже 60 к/с не происходит потери производительности, а выше 60 к/с - монитор все равно выше 60 изображений в секунду сформировать не может. От того, что выводится больше 60 растет только дефектность картинки, но количество видимых кадров все равно будет 60. )) (про лаг отдельный разговор)

DELL U2713 (2560*1440). Да, наверно это надо было отразить в статье, извиняюсь.
В обзорах на данный монитор отмечалось не слишком высокая задержка вывода, что не должно сказаться на процессе фотографирования и я не стал обращать внимание на него. При съемке захватывается изображение с 4-8 кадров и общая задержка вывода не является существенной.

Если перефразировать вопрос, заменив слово "кадр" на "примитив" (vertex, shader &etc), то вопрос становится очень даже интересным. К сожалению, ответа у меня нет. В древние времена существовал такой "вопрос" - 'неужели вы думаете, что ВСЕ операции DirectX видеокарта обрабатывает АППАРАТНО?' ... Что подразумевает единственный ответ - "нет, конечно". Так что, вопрос Forzay очень даже актуален.

Обычно, я делаю одно и то-же и потом никогда в это не лезу. Ставится windows, ставятся драйверы на железо и последний патч Dx9. Всё, больше никаких "улучшайзеров" не устанавливается.
Windows один и тот-же, компьютер не подключен к и-нет и (самопроизвольное) обновление невозможно.

Спасибо за отзывы.