Unlimited Detail (221 стр)

Вий
Кэш бывает разных уровней.

EyeGem

In core i7 the line sizes in L1 , L2 and L3 are the same: that is 64 Bytes. I guess this simplifies maintaining the inclusive property, and coherence.

See page 28 of : https://www.scss.tcd.ie/Jeremy.Jones/CS3021/5%20caches.pdf

Вий
> И дальше забавный эффект: чем выше FPS тем больше кадры похожи друг на друга,
> тем меньше нужно обновлять и тем выше FPS
Репроекция вообще крутая штука, и в современных рендерах сильно недооценённая на мой взгляд.

Вий
> In core i7 the line sizes in L1 , L2 and L3 are the same: that is 64 Bytes.

Но размер одномоментно подгружаемых блоков-то разный? Просто выбивание потом частичное? Или прямо вот так по 64 байта из основной медленной памяти и читает? Вроде бы всякие DMA позволяют копировать сразу много и странно было бы если бы кэши не использовали эту особенность.

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

If the memory bus is 64 bits wide this means 8 transfers per cache line. DDR supports this transport mode efficiently. When memory content is needed by the processor the entire cache line is loaded into the L1d

Вий
В любом случае, в среднем, если данные лежат линейно, то проход по ним будет быстрее, чем если они разбросаны по сотням мегабайт. Локализация данных, используемых в отрисовке ортокубика — важная вещь. Когда кубик нужно разделить на чилдов (потому что загружены данные следующего уровня детализации), то данные кубика разрезаются на от 1 до 8 блоков, чтобы данные получившихся ортокубиков тоже были локализованы. Аналогично схлопываем чилдов в парента при уменьшении детализации. При этом также нужен кэш неиспользуемых данных, чтобы каждый раз не загружать их с диска при повышении детализации. В основном на экране рисуются именно ортокубики.

Вий
А если весь экран будет заполнен динамичной анимированной геометрией, ФПС утонет?

Жора Монтировка
Нет, ведь динамическая анимированная геометрия это облако точек

Вий
А откуда берешь нормали корлика?
Я подумал, расстояние можно брать из трехмерного массива небольшого размера, трилинейно интерполируя между 8 узлами
У тебя так сделано?

Aslan
Кажется я брал больше 8 узлов для нормалей, а потом хотел сжимать их до 1 байта по таблице

Вий
> сжимать
Корлик такой огромный?

Я помню, ты еще писал что у тебя есть алгоритм, намного лучше репроекции. Покажешь?

Aslan
Кролик не очень большой, но чем он лучше попадает в кеш тем быстрее работает.

Алгоритм лучше - это инверсное октальное дерево с предпосчитанной видимостью. Все пространство где может быть камера делим на вокселы. Из каждого получаем список всех видимых вокселов модели в видимых лодах. Для 8 соседей вокселов пространства мира строим родительский узел и выносим туда все общие для большинства из 8 узлов видимые вокселы модели. Повторяем пока не получим корень этого дерева.

Вий
Есть демка и описание?