Производительность современных GPU при вычислении FFT Опции

[rloc]

Коллеги, подскажите, какой максимальной производительности можно достичь на современных GPU при вычислении FFT 64К комплексных точек, 24 бит, radix-4 или более, с одинарной и двойной точностью? Среда разработки не имеет значения, нужно понять потолок производительности, с учетом полосы памяти. Если GPU умеет вычислять в потоке (streaming), то интересует минимальное время между загрузкой новых данных и выгрузкой обработанных.

[faa]

Вот тут английский самоделкин на GPU от Raspberry Pi БПФ-ит.
Можно прикинуть производительность для "толстых" GPU.
Разбивает на мелкие с доворотом между ними.
Мы таким способом делали в ПЛИС БПФ на 16М. 8 реальных каналов на XC6V240, 4 потока, разбор.
Частота семплирования 80МГц, на выходе 8 комплексных спектров в 8М бинов по ~5Гц с перекрытием 50%.
Сейчас на Kintex Ultrascale 16 реальных каналов (семплирование ~118МГц) получилось на 4М бинов по ~7Гц с перекрытием 25%.
На GPU в потоке не получилось - думали-смотрели, но не влезло (а может не осилили). Пришлось плисоводить .

[rloc]

На GPU в потоке не получилось - думали-смотрели, но не влезло (а может не осилили). Пришлось плисоводить .

Подсознательно кажется с GPU больше "подводных камней" и на начальном этапе они могут быть не видны. Нет прозрачности в пути ADC->PCIe->GPU->PCIe->Host.

Сейчас на Kintex Ultrascale 16 реальных каналов (семплирование ~118МГц) получилось на 4М бинов по ~7Гц с перекрытием 25%.

Пробежимся по структуре? RobFPGA, подключайтесь. Набросал по-быстрому схему, могу ошибаться, поправляйте:



Подумал, действительно, закладываться на один "жирный" FPGA смысла не имеет. В модульной структуре легче обеспечить большую ширину памяти, ПО модулей может быть одинаковым, соответственно меньше времени на компиляцию и верификацию, выше частота работы. Последовательная структура мне показалась более удобной с точки зрения передачи данных (pipeline). Есть два вопроса:

1. Ширина полосы памяти на один модуль.
По самым оптимистичным оценкам достаточно обеспечить тройную (запись, чтение, коэффициенты) ширину входной полосы с ADC, приведенную к ширине внутренней арифметики.

2. Перектрытие.
За счет чего обеспечить? За счет увеличения кол-ва модулей или гарантии более высокой скорости обработки?

[RobFPGA]

Приветствую!

Подсознательно кажется с GPU больше "подводных камней" и на начальном этапе они могут быть не видны.
Нет прозрачности в пути ADC->PCIe->GPU->PCIe->Host.

Вот вот ...

Пробежимся по структуре? RobFPGA, подключайтесь. Набросал по-быстрому схему, могу ошибаться, поправляйте:

Нее - я предпочитаю медленно спустится с горы и ...

Подумал, действительно, закладываться на один "жирный" FPGA смысла не имеет. В модульной структуре легче обеспечить большую ширину памяти, ПО модулей может быть одинаковым, соответственно меньше времени на компиляцию и верификацию, выше частота работы. Последовательная структура мне показалась более удобной с точки зрения передачи данных (pipeline). Есть два вопроса:

Еще не знаем что делать но будем делать универсально и модульно !

1. Ширина полосы памяти на один модуль.
По самым оптимистичным оценкам достаточно обеспечить тройную (запись, чтение, коэффициенты) ширину входной полосы с ADC, приведенную к ширине внутренней арифметики.

2. Перектрытие.
За счет чего обеспечить? За счет увеличения кол-ва модулей или гарантии более высокой скорости обработки?

Смотрим что есть на входе FFT=64K, I,Q=16 6ит, для таких N коэффициенты нужны не меньше 20 бит.
Начинаем кумекать как можно это считать - например смотрим структуру FFT R22.
Если не забыл то для N точек нужно N слов (I,Q) памяти для данных и N/4 слов коэффициентов.
Грубо - надо 64K * 4 * 1.5 + 16K * 5 = 384 + 80 KByte, + 64 KByte + таблица для окна. ~ 528 KByte.
Влезет даже в средний чип. Если нужно перекрытие %50 + еще 256K на входной буфер.
Если немного по оптимизировать то часть памяти для коэффициентов и таблицу окна можно сэкономить считая на логике все на лету. Самые большие (входных и для первых stage) можно и во внешнюю память вынести (если полосы хватить).

Структура FFT R22 считает семпл за такт - на заморачиваясь можно получить 300 MHz - если "котика выжать" можно получить еще 5 капе.. и 400 MHz тактовой.

Ну а дальше как игра в наперстки - как крутить вертеть данными либо по очереди в один FFT - если успеваем по частоте.
Либо распределяем на несколько FFT по очереди, либо и то и другое.

Вот когда для конкретной системы будут такие квадратики структуры с цифрами ресурсов и со стрелочками описывающими основные потоки данных - тогда можно будет выбирать "тощий" чип и строить универсальный конвейер.

Ах да - а что с данными после FFT делать не забудьте прикинуть и посчитать. Там ведь тоже будет сюрпризов.

Удачи! Rob.

[rloc]

будем делать универсально и модульно

Да, раз есть готовое и вкусное.

смотрим структуру FFT R22.

Спасибо, посмотрим. Насколько сложно в алгоритме сделать переменную длину?

Структура FFT R22 считает семпл за такт

Выравнивающие задержки есть? Какой длины? Зависят от длины преобразования?

ПЛИС одна.
Память: 4 контроллера DDR3-1600 - 32х, 64х, 64х, 32х; HMC - полтора линка (х8 - слева, х16 - справа ПЛИС).
Наружу: PCIe Gen3 ext x8, PCIe Gen3 ext x4, HMC - два линка х16, serdes - два линка х4 (один слева, другой справа ПЛИС).

Очень тяжелый проект, и физически и морально.

[faa]

Очень тяжелый проект, и физически и морально.

Ваши слова да начальству бы в уши

По делу:
поищите статейку "FPGA implementation of a 32k accumulating FFT with 2-Gs/s throughput".
Она от 2005 года, но, ИМХО, актуальна. Там на V2Pro и V4.
А сейчас ПЛИС намного "веселее", есть где развернуться