[x]
Вход
Amazon
AMD
ATI
brute force
bruteforce
cloud
CUDA
GPGPU
gpgpu.ru
GPU Gems
Intel
Larrabee
Linpack
MapReduce
MD5 crack
Nexus
NVidia
NVidia 8800
NVidia CUDA
NVidia G200
NVidia GTX280
NVidia Nexus
OpenCL
Parallel Nsight
signal processing
sparse matrices
Stream SDK
VISPL
VMWare
web
ВМиК МГУ
МГУ
Москва
Т-Платформы
Физфак МГУ
бенчмарки
блогосфера
вычисления
конкурсы
курсы
новости сайта
обработка изображений
подбор паролей
поиск
программирование GPU
работа
разное
сортировка
фильтрация трафика
численные методы
Navigation
Cвежие комментарии
-
1 week 1 day ago
-
1 week 2 days ago
-
1 week 2 days ago
-
1 week 2 days ago
-
1 week 2 days ago
-
1 week 2 days ago
-
1 week 2 days ago
-
1 week 5 days ago
-
3 weeks 4 days ago
-
3 weeks 6 days ago
Новое на форуме
Популярно
- Как начать с самого начала работу с CUDA (33,849)
- Форумы NVidia CUDA: обзор за май (31,831)
- GPGPU и видеокарты AMD (18,187)
- NVidia GTX 280, Tesla T10P (15,759)
- SGEMM на видеокарте и CPU, серия 6 (14,895)
Да я вроде не предлагал увеличивать количество чтений :) Вы читали блоками 16х16 нитей матрицу 16х16, или, если учитывать пересекающиеся края, 18x18. Я предлагал блоком 16x16 нитей читать матрицу 30x30 с пересекающимися краями, то есть 32x32. Число чтений меньше, чем в Вашем исходном варианте.
Единственное что непонятно при этом, важно ли Вашему алгоритму, что блок обрабатывает блок именно 16х16. По косвенным признакам похоже, что все-таки блок 16x16 памяти это важно. Если это действительно так, и нельзя никак изменить обработку блока 16x16 на обработку блока 30x30, то тогда имеет смысл все пересекающиеся края блоков вынести в отдельные массивы.