Blog #cpu

Начнем с того, что это регистры. По сути отличие между ними в том, что xmm (128 bits) хранит меньше данных, чем ymm (256 bits).

Вы можете встретить такое в burst-generated коде, когда разглядываете бесконечные регистры в инспекторе берста.

Пример:

struct MyStruct { 
     public float a1; 
     public float a2; 
     public float a3; 
     public float a4; 
}

myStruct1 = myStruct2 будет использовать xmm (4 флота в 128 битах).

Если же добавить полей:

struct MyStruct { 
     public float a1; 
     public float a2; 
     public float a3; 
     public float a4; 
     public float a5; 
     public float a6; 
     public float a7; 
     public float a8; 
}

то теперь myStruct1 = myStruct2 будет использовать ymm (8 флотов в 256 битах).

Таким образом, мы считаем за одну операцию больше данных.

Но если же мы оставим 6 полей, то будет использован один vmovups xmm, а остальные два поля будут считываться mov rdx.

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

WaitForTargetFPS: Время, потраченное на ожидание целевого значения FPS, указанного в Application.targetFrameRate. Редактор не использует VSync на GPU, а вместо этого использует WaitForTargetFPS для имитации задержки VSync.

Gfx.ProcessCommands: Поток рендеринга охватывает всю обработку команд рендеринга. Часть этого времени может быть потрачена на ожидание VSync или новых команд из основного потока, что можно увидеть в Gfx.WaitForPresent.

Gfx.WaitForCommands: Поток рендеринга готов к новым командам, и может указывать на узкое место в основном потоке.

Gfx.PresentFrame: Поток рендеринга представляет собой время, затраченное на ожидание рендеринга и представления кадра графическим процессором, что может включать ожидание VSync.

Gfx.WaitForPresent: Когда основной поток готов начать рендеринг следующего кадра, но поток рендеринга еще не завершил ожидание представления кадра GPU. Это может указывать на то, что узкое место в GPU. Посмотрите на представление временной шкалы, чтобы узнать, проводит ли поток рендеринга одновременно время в Gfx.PresentFrame. Если поток рендеринга все еще проводит время в Camera.Render, узкое место в CPU, т.е. тратит слишком много времени на отправку вызовов отрисовки/текстур на GPU.

Мы знаем, что производительность - это метрика, которую можно оценить по fps или frames per second, т.е. сколько раз мы можем за секунду выполнить всю логику в кадре и отрисовать все, что мы посчитали.

Логика - это все то, что мы пишем в наших методах Update, которые являются частью основного цикла кадра и это обрабатывается на cpu, а вот рендер - это то, что обрабатывает видяха.

В целом эти два процесса никак не связаны, то есть в какой-то момент времени cpu посчитал что-то и готов передать на gpu некие данные, которые будут обрабатываться уже там и как результат - будет картинка. Существуют еще compute shaders, которые по сути используют проц на видяхе, чтобы посчитать результат.

И вот тут нам нужно синхронизировать данные. То есть при использовании синхронизации нам нужно задать фиксированное количество времени, которое мы готовы потратить на кадр, например, 30 кадров в секунду или 33мс на кадр. И при синхронизации существует время ожидания, когда cpu ждет gpu или наоборот. В профайлере такие ожидания обозначаются как WaitForPresentOnGfxThread. А вот WaitForTargetFps - это время, которое нужно, чтобы поддержать заданный frame rate.