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

Занимался подобной проблемой, результат неутешительный. Непосредственно сам расчет FFT на GPU выполняется очень быстро по сравнению с CPU (выигрыш может составлять сотни раз), но главной проблемой, таким себе «бутылочным горлышком» остается обмен данными между хостом и девайсом, который «жрет» 99% времени, особенно это касается передачи данных с девайса на хост, это процедура намного медленнее, чем загрузка данных на GPU. Если данные не забирать после расчета, то смысл в этом есть, а так все печально, конечно. Карточка, с которой игрался - бюджетный GeForce GTX750ti/128 bit/1 Gb GDDR5

длинные поточные FFT удобно делать на ПЛИСах.
под них заточен алгоритм Cooley-Tukey. вполне можно в реалтайме обрабатывать 64Msps 16bit размером в 32M точек в целочисленке.

Вы можете сказать, чем определяется производительность обмена данными?

Перейду к конкретике. Допустим, есть 2 квадратурных канала сбора данных по 16 бит, частота 100 МГц (в перспективе больше, до 500 МГц и выше). Квадратурные каналы - аналоговые, нужно предварительно подкорректировать смещение нуля, фазы и амплитуды. Потом - FFT с заданным количеством точек (для конкретики - 64К), матобработка между каналами, накопление. На выходе - поток не большой, возможно в разы меньше входного. Насколько легко современные GPU способны "переваривать" такие задачи? В первую очередь конечно интересует скорость FFT, в идеале - с 50% перекрытием, в худшем случае - с минимальными разрывами в обработке.


Да, в части FPGA мне все более-менее понятно, по гибкости и ширине полосы памяти (внутренней) возможностей значительно больше.

ещё новые шарки SC58x у AD c FFT ускорителями обещают ~5нс на отсчёт, (1к ФФТ за 5 мкс)
то есть 100МГц с 50% перекрытием пережевать вроде должны.

На DSP закладываться опасно, основная проблема - в гибкости проектирования. Скажем, захочу перейти на radix-16, radix-32 ... Что делать в этом случае? Не позволяет DSP разменивать память на вычислительные ресурсы. С GPU чувствую такая же проблема будет.

Прогнал тест, при таких нач.условиях ( i/q 16 bit, FFT Size = 64K) получилась скорость входного потока порядка 3 Gbit/s, т.е. практически Ваши 100 МГц. если взять более топовую карту, то думаю будет по-веселее

за/против GPU ещё наверное зависит от того есть ли эти 3, а в перспективе до 15 Гбит/с уже в ПК или их ещё туда засунуть надо?

В моем случае данных в хосте изначально нет, сначала плата оцифровки должна передать их по шине PCIe, и возможно, если она умеет быть мастером, то напрямую в GPU. Вопрос, что является узким звеном в этом обмене?


Откуда берется эта цифра?

2 квадратурных канала сбора данных по 16 бит, частота 100 МГц (в перспективе больше, до 500 МГц и выше)
2*16*100 = 3.2ГБит/с
2*16*500 = 16ГБит/с

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


Если Вам надо закапчить пару гигабайт данных и потом пережевывать FFT и считать хитрую математику то можно попыхтеть и на GPU. Если же надо работать непрерывно с потоком то лучше потратить время с FPGA - лет 7-10 назад делал похоже на 4 Virtex - 2 канала 16 бит/250MHz, 16K FFT с перекрытием 50%, с кросс-кореляцией и с накоплением. Сейчас такое можно собрать на готовом модуле с Artix/Kintex/Zynq от $300 будет заодно и интерфейс к ADC и выдача результата через Ethernet.

Успехов! Rob.

Решил, что ограничение в 3 Гбит/c (в конкретном примере) было больше связано с интерфейсом, по первым ответам.

По моим расчетам, узким местом в GPU может быть ограниченная полоса памяти и возможность ее эффективного использования в случае рандомного доступа. Насколько эффективно компиляторы могут оптимизировать алгоритм - для меня темный лес, что и хотелось выяснить, с экстраполяцией результатов на Pascal GP100/Radeon RX Vega с памятью HBM2 2048 бит.


С удовольствием посмотрел бы на рабочий образец в действии ) Продолжение было?

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


А че на него смотреть - сначала был PCIX модуль на базе Virtex4SX35 от Московской ISYS.
Потом сделали свой на базе модуля на Spartan6 и Artix7. Причем FFT обработка была на Spartan6!
а Artix7 использовался для интерфейсов 1G Ethernet и либо PCIe x4 либо Ethernet 10G.

Ну а продолжение потом было на Virtex5 - в realtime считался поток 6.6 GByte/s (12 бит/2.2GHz), правда FFT всего 512 точек но зато обработка каждого спектра геморройная.
Ну а на сегодняшнем железе ( UltaScale, UltaScale+ ... ) такие чудеса можно наворотить....

Успехов! Rob.

БукоФФки не хватает. Знаком с компанией ни один десяток лет. Как раз недавно ведущий разработчик делал доклад в тему:

https://www.youtube.com/watch?v=pmLUZ8hFoa0

GPU предусматривают 2 режима обмена данными - синхронный и асинхронный. Скорость копирования в асинхронном режиме ограничивается только скоростью памяти хоста и карточки и скоростью PCIe, со скоростью 15 Гбит/с на мощном железе не должно возникнуть проблем, такую скорость дает PCIe Gen 2 x4, для DDR 1600 МГц/64 бита это вообще ни о чем. В задаче ТС больше вопросов может возникнуть к карточке, скорость вычислений сильно зависит, например, от разрядности шины. Вообще информация по FLOP для разных карточек есть в интернете, для БПФ сделать оценку требуемой производительности не составляет труда.

Так нужны не расчеты, а примеры реализации с конкретными цифрами, с оптимизированным кодом под определенную задачу. Зачем GPU тестируют на каждой игре отдельно?

Сначала я тоже так думал, но практика, а также профайлеры показали, что проблема именно в копировании между устройствами.

Любая инженерно-техническая задача начинается с расчета (оценки), исходя из расчета выбираются пути реализации. Если вам подходит стандартный БПФ, то он есть в примерах CUDA, можете скачать, поставить, запустить и посмотреть на цифры.



В вашем конкретном случае может это и так, не зная подробностей задачи и железа и не посмотрев в код ничего внятного сказать нельзя. Но меня жизнь научила, что в 90% случаев "дело не в бобине". Раз производители делают PCIe на много линий, значит железо в состоянии их утилизировать, т.е. для современной видеокарты скорости обмена в десятки гигабит в секунду - нормальный режим работы.

В этом тесте ничего сложного нет, 3 строчки кода: копирование на карту, FFT и копирование с карты на хост, все библиотечные оптимизированные функции, хотя свой код FFT тоже пробовал. В результате получам 2,5 Гбит/с на том железе, что у меня есть. если убрать копирование с карты на хост, то получаем 3 Гбит/с,т.е. 15 % ресурсов «жрет» тривиальная функция копирования!!! Не много ли?

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

Странные показатели у вас.

gtx1060 complex fft 64k

dp ~573 us
из них
21% выполнение
43% копирование туда
37% копирование обратно

sp ~297 us
из них
7% выполнение
55% копирование туда
38% копирование обратно

Собственно, дуплексная пропускная способность шины составляет ~15 - 18гбит/с

зы
т stealth-coder прав на 110%. Сначала оценка, потом выбор пути решения. Иначе получим изучение проблем шаманизма на начальном этапе разработки и проблем опорно-двигательного аппарата на последующих. Оно вам надо? Ну и pci-e 16x - это неспроста, как говорил в. пух.

Выходит, gtx1060 при входном потоке 500 MHz сделать complex fft 64k не успевает?

Время заполнения буфера семплами с выхода АЦП: 64к*2ns = 128 us.

Соответственно, если считать FFT с перекрытием 50%, то время вычисления FFT должно быть меньше 64 us.

А в реале получается, что время вычисления FFT на GPU с учетом загрузки и выгрузки данных в разы больше времени заполнения буфера семплами с выхода АЦП.

Очевидно, что не успевает.
Честно говоря, обработать полосу в 500мгц - нетривиальная задача, требующая индивидуального подхода. Универсальные решения тут не годятся.

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


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

Нажмите для просмотра прикрепленного файла

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

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

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

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

Как-то так.

Контроллеры DDR3 - физика из MIG, логика своя. За 6,5 мкс пишет/читает 256 отсчетов по всем каналам, регенерация, калибровка VT.
Перекрытие 25%, в первый буфер пишем 192 отсчета, читаем 256.

Из шишек: замирание PCIe, при пиковой (расчетной) для Gen3 x8 более 6ГБ/сек (даже при TLP128) для 4.8ГБ/сек имели некоторые неудобства.
Пришлось городить эластик-буфер и резать лишнее .

Скорость DDR3 можно поднять (ПЛИС позволяет), тогда проходит и децимация на 3,5.

ЗЫ: На общие вопросы могу здесь ответить, подробности - лучше в личку.

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

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


Смотрим что есть на входе 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.

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


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


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


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

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

Вкусы у все разные - бывает такое иногда подадут ...

В алгоритме то? - да запросто А вот в реальности не всегда.

Ээээ ... телепатическая манна закончилась - Вы это о чем?

Тяжесть выбора - груз ответственности - мужайтесь! - щас мы Вам насоветуем ...

Удачи! Rob.

У всех своё представление о том, что есть "жирный" FPGA..

Pipeline FFT Radix-4 на 64k комплексных точек влазит в XC7K410T и ещё остается ~30% свободной BRAM памяти.

Ближе к этапу проектирования станет понятно, как проще и дешевле. 64К и 500МГц - это не конечная цель, можно и больше, важнее иметь масштабируемую структуру, чтобы начать с простого преобразования на 1К и дальше развить до 16M (как пример). На текущий момент необходимо понять, что лучше подходит для потоковой обработки:

1. Можно ли сэкономить на промежуточном хранении данных, чтобы остаться в рамках 1К-16М внутри одного кристалла? Разумная ширина внешней памяти допускается. Понятие разумности определяется количеством выводов BGA. Мне кажется, нужно ограничить размерность FPGA количеством выводов не более 900. Если выше - существенно растет время компиляции и верификации, да и разработка самой платы может оказаться не простой задачей, тогда лучше перейти ко второму варианту.

2. Сократить сроки разработки и отладки за счет некоторой избыточности железа по объему и производительности, но применению простых унифицированных модулей и простых алгоритмов обработки, пусть с большим количеством операций сложения и умножения. Возможно это и есть золотая середина между GPU и FPGA.

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

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