a_z_z_y:
Судя по Вашей логике пока проц считает 1,2,3, то видеокарта простаивает, а во время п4 скучает процессор.
На самом деле видяхе можно скармливать данные на следующий кадр в то время как она дорендеривает предыдущий. А проц может начать считать слудующий кадр, пока видяха рендерит текущий
п1 и п2 споконо и уже давно паралелится и задействует многопоток. Симуляция мира/физики вообще может жить своей отдельной (многопоточной?) жизнью с фиксированным апдейтом, а данные из него для отображения будут братся по необходимости.
п3 паралелится не умеет, по крайней мере в ДХ11. А вот при грамотной реализации и использовании ДХ12 профит можно получить и в п3.
Обзор нормальный, а не сделаный впопыхах. Полноценный игровой обзор будет чуть позже.
Если видеокарта не успевает нарисовать первый кадр, а мы посылаем ей второй, а потом третий итд, то это означает, что мы gpu bound и наш конечный фпс будет во многом упираться именно в видеокарту. Разве это допустимо в сравнительном обзоре процессоров?
Да и вообще я не понимаю причем тут синихронность работы цп и видеокарты если автор статьи считает КАДРЫ, а не АПДЕЙТЫ.
Время Кадра - это совокупность времени необходимое для процессора и видеокарты. Если кто-то не успевает, то особой разницы нет, насколько быстрее второй. От того и существуют понятия gpu bound и cpu bound. И обычно в обзорах процессоров стараются исключить ситуацию gpu bound.
Пускай процессор будет считать 3500 кадров в секунду и все их запихивать в неимоверный буфер медленной видеокарты. Сколько вы увидите FPS ?
Допустим мы посчитали кадр и параллельно скормили его видеокарте. Пока она отрисовывала кадр, мы на цп посчитали следующий. Отдали ей в буфер еще один. Потом обсчитали третий, а она еще и первый не нарисовала. Будет расти UPS, а FPS будет расти незначительно, совсем незначительно.
Такое впечатление, что вы решили по умничать просто. Ведь вопрос: "стоит ли в сравнительном обзоре процессоров использовать наиболее быструю видеокарту" имеет очевидный ответ.
По-поводу физики, которая "может жить своей жизнью" и fixed update ( далее FU). FU не живет отдельной жизнью и всегда включен в общий апйдет. Если с прошлого общего апдейта прошло менее fixed time, то мы пропускаем выполнение FU в данном общем апдейте. Если прошло больше fixed time, то мы выполняем FU и смотрим сколько остается у таймера. Если опять больше, то выполняем FU опять. И так до тех пор пока не выполним необходимое количество раз исходя из дельты времени и fixed time.
Вот три разных случая:
для fixd update minimal time = 16
1) total frame time = 20ms. -> fixed update X 1 -> 4 ms next frame timer
2) total frame time = 40ms. -> fixed update X 2 -> 8 ms next frame timer
3) total frame time = 10ms. -> fixed update X 0 -> 10 ms next frame timer
