Войти
ПрограммированиеФорумГрафика

Unlimited Detail (221 стр)

Страницы: 1218 219 220 221 222 223 Следующая »
#3300
13:54, 8 мар. 2019

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


#3301
(Правка: 17:15) 17:14, 8 мар. 2019

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

#3302
20:05, 8 мар. 2019

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

#3303
20:41, 8 мар. 2019

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

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

#3304
(Правка: 21:24) 21:23, 8 мар. 2019

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

#3305
21:27, 8 мар. 2019

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

#3306
(Правка: 12:36) 12:35, 10 мар. 2019

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

#3307
13:55, 10 мар. 2019

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

#3308
13:59, 10 мар. 2019

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

#3309
19:38, 20 апр. 2019

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

#3310
0:35, 21 апр. 2019

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

#3311
13:41, 21 апр. 2019

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

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

#3312
14:00, 21 апр. 2019

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

#3313
(Правка: 14:08) 14:01, 21 апр. 2019

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

#3314
14:05, 21 апр. 2019

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

Страницы: 1218 219 220 221 222 223 Следующая »
ПрограммированиеФорумГрафика