Показать сообщение отдельно
Старый 13.02.2015, 17:06   #6
Samodelkin
Мастер
 
Регистрация: 12.01.2009
Сообщений: 979
Написано 388 полезных сообщений
(для 631 пользователей)
Ответ: dword to float4 и обратно

Сообщение от mr.DIMAS Посмотреть сообщение
А не проще ли забить на используемую память? Хранить сразу 4 флоата вместо dword? По памяти всего в 4 раза возрастает расход, но убирается ебля с преобразованиями.
Технически конечно проще. Такой вариант тоже рассматривается, пока нету больших проблем с занимаемой текстурами памяти и их можно увеличить. Но это также нагрузит и шину памяти, у неё тоже есть предел, ведь кол-во данных для чтения/записи увеличится в 4 раза. Хотя я раньше проводил тесты с выборкой одной текстуры, но сейчас в проекте используется больше чем одна и нагрузка может быть в разы больше. А в современных системах именно память самый медленный элемент. Так что все усилия по simd оптимизации и многопоточности могут упереться в скорость памяти.

К слову даже на видеокартах, где память в разы быстрее, пытаются ужать и текстуры и гбуфер, там даже за счёт сжатия текстур можно сгенерировать часть данных на ходу, не читая их вообще.

Ещё, большие текстуры хуже умещаются в кеше. На самом деле с текстурами вообще такая проблема, что их выборка часто идёт хаотично, поэтому случаются кеш-промахи, здесь я буду пробовать создавать алгоритм наподобие mip-maping'а -- он не только улучшает визуализацию текстур (хотя в моём случае нужно применять и другие методы) но суть мип-мэпинга это подобрать разрешение текстуры таким образом чтобы оно совпадало с разрешением экрана, а это означает что выборка (при сканлайн-рендере) будет более упорядочена и префетчер лучше справится с кешированием данных текстуры. Однако в моём случае (речь о рейкастинге) рендер происходит вертикальными слайсами (столбцами) и это тоже негативно влияет на кеширование, как вариант можно сохранять данные текстур (и буферов) не построчно, а столбцами.

Ну короче тут много о чём можно рассуждать, но лучше подождать когда будут объективные данные с производительностью разных тестов.

Сообщение от Mr_F_
преобразование обычных регистров в XMM и обратно операция столь долгая, что может потеряться профит от самих SSE вычислений.
Ну то есть через кеш L1 это передается? Ну не то чтоб очень дорогая, например по сравнению с чтением из памяти без префетча это много быстрее. Чтение из L1 - около 3 циклов, из L2 около 20 циклов, из памяти - 200 циклов.
Сейчас я делаю инлайн целого ассемблерного блока в несколько страниц длиной, один раз загружаю в начале и записываю в конце, в целом удаётся уместить вычисления в 8 xmm регистров. В SSE есть ручное управление префетчем, так что можно и его попробовать если что.
(Offline)
 
Ответить с цитированием
Эти 2 пользователя(ей) сказали Спасибо Samodelkin за это полезное сообщение:
Mr_F_ (13.02.2015), St_AnGer (13.02.2015)