CUDA или FPGA для 3D-вычислений специального назначения? - PullRequest
53 голосов
/ 25 ноября 2008

Я занимаюсь разработкой продукта с тяжелыми вычислениями в 3D-графике, в значительной степени, ближайший пункт и поиск по диапазонам . Некоторая аппаратная оптимизация была бы полезна. Хотя я мало что знаю об этом, мой начальник (у которого нет опыта работы с программным обеспечением) выступает за FPGA (потому что он может быть адаптирован), в то время как наш младший разработчик выступает за GPGPU с CUDA, потому что он дешевый, горячий и открытый. Хотя я чувствую, что мне не хватает осмысленности в этом вопросе, я считаю, что CUDA - это то же самое, потому что я беспокоюсь о гибкости, наш продукт все еще находится в стадии активной разработки.

Итак, перефразируя вопрос, есть ли какие-либо причины для перехода на FPGA? Или есть третий вариант?

Ответы [ 16 ]

48 голосов
/ 02 декабря 2008

Мы провели некоторое сравнение между FPGA и CUDA. Одна вещь, где CUDA сияет, если вы действительно можете сформулировать свою проблему в SIMD-стиле И можете получить доступ к объединившейся памяти. Если доступ к памяти не объединен (1) или если у вас разные потоки управления в разных потоках, графический процессор может значительно потерять свою производительность, а FPGA может превзойти его. Другое дело, когда ваша операция очень мала, но у вас ее огромное количество. Но вы не можете (например, из-за синхронизации) не запускать его в цикле в одном ядре, тогда время вашего вызова для ядра GPU превышает время вычислений.

Кроме того, мощность FPGA могла бы быть лучше (зависит от сценария вашего приложения, т. Е. Графический процессор дешевле только (в ваттах / флопе) при его постоянной работе).

Конечно, FPGA также имеет некоторые недостатки: IO может быть одним (у нас было приложение, где нам было нужно 70 ГБ / с, нет проблем для GPU, но для того, чтобы получить такой объем данных в FPGA, который вам нужен для обычного проектирования, больше булавки чем доступны). Еще один недостаток - время и деньги. FPGA намного дороже, чем лучший GPU, и время разработки очень велико.

(1) Одновременный доступ из разных потоков к памяти должен осуществляться по последовательным адресам. Это иногда очень трудно достичь.

46 голосов
/ 25 ноября 2008

Я исследовал тот же вопрос некоторое время назад. После общения с людьми, которые работали над FPGA, вот что я получаю:

  • ПЛИС отлично подходят для систем реального времени, где задержка даже в 1 мс может быть слишком большой. Это не относится к вашему делу;
  • ПЛИС могут быть очень быстрыми, особенно для четко определенного использования цифровой обработки сигналов (например, радиолокационных данных), но хорошие намного дороже и специализированы, чем даже профессиональные GPGPU;
  • ПЛИС довольно громоздки для программирования. Поскольку для компиляции есть компонент конфигурации оборудования, это может занять несколько часов. Кажется, он больше подходит для инженеров-электронщиков (которые обычно работают над ПЛИС), чем для разработчиков программного обеспечения.

Если вы можете заставить CUDA работать на вас, это, вероятно, лучший вариант на данный момент. Это, безусловно, будет более гибким, чем ПЛИС.

Другие варианты включают Brook от ATI, но пока не произойдет что-то грандиозное, он просто не так хорошо принят, как CUDA. После этого есть все традиционные опции HPC (кластеры x86 / PowerPC / Cell), но все они довольно дорогие.

Надеюсь, это поможет.

15 голосов
/ 25 ноября 2008

Я бы пошел с CUDA.
Я работаю в области обработки изображений и уже много лет пробую дополнения к оборудованию. Сначала у нас был i860, затем Transputer, затем DSP, затем FPGA и аппаратная прямая компиляция.
То, что неизбежно произошло, состояло в том, что к тому времени, когда аппаратные платы были действительно отлажены и надежны, и код был перенесен на них - обычные ЦП продвинулись вперед, или архитектура хост-машины изменилась, и мы не могли использовать старые платы, или создатели доски обанкротились.

Придерживаясь чего-то вроде CUDA, вы не привязаны ни к одному небольшому специалисту по производству плат FPGA. Производительность графических процессоров улучшается быстрее, чем процессоров, и финансируется геймерами. Это основная технология, поэтому в будущем она, вероятно, объединится с многоядерными процессорами и защитит ваши инвестиции.

8 голосов
/ 21 февраля 2015

1001 * ПВМ * Что вам нужно: Изучи VHDL / Verilog (и поверь мне, что не будешь) Купить hw для тестирования, лицензии на инструменты синтеза Если вы выберете несколько хороших фреймворков (например: RSoC ) Разработка дизайна (и это может занять годы) Если вы этого не сделаете: DMA, драйвер hw, сверхдорогие инструменты синтеза тонны знаний о шинах, отображении памяти, синтезе hw сборка hw, покупка ip ядер Разработка дизайна Например, средняя PCGA-карта FPGA с чипом Xilinx virtex-6 стоит более 3000 $ Результат: Если вам не платит правительство, у вас недостаточно средств. GPGPU (CUDA / OpenCL)

  • У вас уже есть hw для тестирования.
  • Сравните с FPGA:
    • Все хорошо документировано.
    • Все дешево
    • Все работает
    • Все хорошо интегрировано в языки программирования
  • Существует также облако GPU.
  • Результат:
    • Вам нужно просто скачать SDK, и вы можете начать.
4 голосов
/ 05 мая 2017

Это старый поток, начатый в 2008 году, но было бы хорошо рассказать о том, что случилось с программированием на ПЛИС с тех пор: 1. C to gates в FPGA является основной разработкой для многих компаний с ОГРОМНОЙ экономией времени по сравнению с Verilog / SystemVerilog HDL. В C до ворот дизайн системы уровня является сложной частью. 2. OpenCL на FPGA существует уже более 4 лет, включая развертывание с плавающей запятой и «облако» от Microsoft (Asure) и Amazon F1 (Ryft API). С OpenCL проектирование системы относительно просто из-за очень четко определенной модели памяти и API между хост-компьютерами и вычислительными устройствами.

Программисты просто должны немного узнать об архитектуре ПЛИС, чтобы иметь возможность делать вещи, которые даже невозможно с графическими процессорами и центральными процессорами, по причине того, что они являются фиксированными и не имеют широкополосных (100 Гбит +) интерфейсов с внешним миром. Уменьшение геометрии чипа больше невозможно, равно как и выделение большего количества тепла из пакета с одной микросхемой без его плавления, поэтому это выглядит как конец пути для чипов с одной упаковкой. Мой тезис здесь состоит в том, что будущее принадлежит параллельному программированию многочиповых систем, и FPGA имеют большие шансы быть впереди игры. Проверьте http://isfpga.org/, если у вас есть сомнения по поводу производительности и т. Д.

4 голосов
/ 15 августа 2009

Очевидно, что это сложный вопрос. Вопрос может также включать процессор клетки. И, вероятно, нет ни одного правильного ответа на другие связанные вопросы.

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

Еще один общий пример, когда FPGA может иметь гораздо более высокую производительность, - это каскадные процессы, где выходы процесса становятся входами для другого, и они не могут быть выполнены одновременно. Каскадные процессы в FPGA просты и могут значительно снизить требования к вводу / выводу памяти, в то время как память процессора будет использоваться для эффективного каскадирования двух или более процессов, в которых существуют зависимости данных.

То же самое можно сказать о GPU и CPU. Алгоритмы, реализованные на С, выполняемые на ЦП, разработанные без учета присущих характеристик производительности кэш-памяти или системы основной памяти, не будут работать так же хорошо, как реализованный, который работает. Конечно, если не учитывать эти характеристики производительности, это упрощает реализацию. Но по стоимости исполнения.

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

4 голосов
/ 24 июня 2009

Решение на основе FPGA, вероятно, будет намного дороже, чем CUDA.

3 голосов
/ 20 июля 2016

ПЛИС не будут пользоваться преимуществами тех, кто склонен к программному обеспечению, так как им нужно изучать HDL или, по крайней мере, понимать systemC.

Для тех с аппаратным смещением FPGA будет первым выбранным вариантом.

В действительности требуется твердое понимание того и другого, и тогда может быть принято объективное решение.

OpenCL предназначен для работы как на FPGA, так и на GPU, даже CUDA можно перенести на FPGA.

Ускорители FPGA и GPU могут использоваться вместе

Так что дело не в том, что лучше того или другого. Существует также дискуссия о CUDA против OpenCL

Опять же, если вы не оптимизировали и не сравнили их с вашим конкретным приложением, вы не можете знать со 100% уверенностью.

Многие просто пойдут с CUDA из-за его коммерческого характера и ресурсов. Другие будут использовать openCL из-за его универсальности.

3 голосов
/ 20 ноября 2009

Я разработчик CUDA с очень небольшим опытом работы с FPGA, однако я пытался найти сравнение между ними.

К чему я пришел к выводу:

GPU имеет гораздо более высокую (доступную) пиковую производительность Он имеет более благоприятное соотношение FLOP / Watt. Это дешевле Он развивается быстрее (довольно скоро у вас будет буквально «настоящий» TFLOP). Проще программировать (читай статью по этому не личному мнению)

Обратите внимание, что я говорю реальный / доступный, чтобы отличать числа, которые вы увидите в рекламе GPGPU.

НО GPU не является более благоприятным, когда вам требуется случайный доступ к данным. Надеемся, что это изменится с новой архитектурой Nvidia Fermi, которая имеет дополнительный кэш l1 / l2.

мои 2 цента

3 голосов
/ 25 ноября 2008

CUDA имеет довольно существенную кодовую базу примеров и SDK , включая сервер BLAS . Попробуйте найти примеры, похожие на то, что вы делаете, возможно, посмотрите также серии книг GPU Gems , чтобы оценить, насколько хорошо CUDA подойдет для ваших приложений. Я бы сказал, с точки зрения логистики, с CUDA легче работать и намного, намного дешевле, чем с любым профессиональным инструментарием для разработки FPGA.

В какой-то момент я заглянул в CUDA для моделирования имитации резерва. Существует довольно хорошая серия лекций, связанных с веб-сайтом для обучения. В Windows необходимо убедиться, что CUDA работает на карте без дисплеев, поскольку графическая подсистема имеет сторожевой таймер, который обнуляет любой процесс, выполняющийся более 5 секунд. Это не происходит в Linux.

Любая машина с двумя слотами PCI-e x16 должна поддерживать это. Я использовал HP XW9300, который вы можете купить на Ebay довольно дешево. Если вы это сделаете, убедитесь, что у него есть два ЦП (не один двухъядерный ЦП), поскольку слоты PCI-e находятся на отдельных шинах Hypertransport, и вам нужно два ЦП на машине, чтобы обе шины были активны.

...