Programing

특수 목적의 3D 그래픽 계산을위한 CUDA 또는 FPGA?

즐거운 cyworld 2021. 1. 10. 16:46
반응형

특수 목적의 3D 그래픽 계산을위한 CUDA 또는 FPGA?


저는 3D 그래픽 계산이 많은 제품을 개발 중이며 가장 가까운 지점 및 범위 검색 . 일부 하드웨어 최적화가 유용합니다. 나는 이것에 대해 거의 알지 못하지만 소프트웨어 경험이없는 내 상사는 FPGA를 옹호하고 (맞춤형이 가능하기 때문에), 우리의 주니어 개발자는 저렴하고 뜨겁고 개방적이기 때문에 CUDA로 GPGPU를 옹호합니다. 이 질문에 대한 판단력이 부족하다고 생각하지만 유연성이 걱정되기 때문에 CUDA가 갈 길이라고 생각합니다. 우리 제품은 여전히 ​​강력한 개발 중입니다.

따라서 질문을 다시 표현하면 FPGA를 사용해야 할 이유가 있습니까? 아니면 세 번째 옵션이 있습니까?


나는 얼마 전에 같은 질문을 조사했다. FPGA에 대해 작업 한 사람들과 대화를 나눈 후 다음과 같은 결과를 얻었습니다.

  • FPGA는 1ms의 지연도 너무 길 수있는 실시간 시스템에 적합합니다. 귀하의 경우에는 적용되지 않습니다.
  • FPGA는 특히 잘 정의 된 디지털 신호 처리 용도 (예 : 레이더 데이터)에 매우 빠를 수 있지만 좋은 것은 전문 GPGPU보다 훨씬 더 비싸고 전문화되어 있습니다.
  • FPGA는 프로그래밍하기가 매우 번거 롭습니다. 컴파일하는 데 하드웨어 구성 구성 요소가 있으므로 몇 시간이 걸릴 수 있습니다. 소프트웨어 개발자보다 전자 엔지니어 (일반적으로 FPGA에서 작업하는 엔지니어)에게 더 적합한 것 같습니다.

CUDA가 작동하도록 할 수 있다면 아마도 현재 최선의 선택 일 것입니다. 확실히 FPGA보다 더 유연 할 것입니다.

다른 옵션으로는 ATI의 Brook이 있지만 큰 일이 일어나기 전까지는 CUDA만큼 잘 채택되지 않았습니다. 그 후에도 여전히 모든 기존 HPC 옵션 (x86 / PowerPC / Cell 클러스터)이 있지만 모두 상당히 비쌉니다.

도움이되기를 바랍니다.


FPGA와 CUDA를 비교했습니다. SIMD 방식으로 문제를 실제로 공식화하고 합쳐진 메모리에 액세스 할 수 있다면 CUDA가 빛나는 한 가지. 메모리 액세스가 합쳐지지 않거나 (1) 다른 스레드에서 다른 제어 흐름이있는 경우 GPU의 성능이 크게 저하 될 수 있으며 FPGA가 성능을 능가 할 수 있습니다. 또 다른 것은 당신의 수술이 실제로 작지만 엄청난 양을 가지고있을 때입니다. 그러나 동기화로 인해 한 커널의 루프에서 시작할 수 없으며 GPU 커널에 대한 호출 시간이 계산 시간을 초과합니다.

또한 FPGA의 성능이 더 좋을 수 있습니다 (애플리케이션 시나리오에 따라 다릅니다. 즉, GPU가 항상 컴퓨팅 할 때만 더 저렴합니다 (와트 / 플롭 측면에서)).

FPGA에는 몇 가지 단점도 있습니다. IO는 하나가 될 수 있습니다 (여기서 애플리케이션은 70GB / s가 필요했고 GPU에는 문제가 없었지만 FPGA로이 양의 데이터를 가져 오려면 기존 설계에 필요한 것보다 더 많은 핀이 필요합니다.) ). 또 다른 단점은 시간과 비용입니다. FPGA는 최고의 GPU보다 훨씬 비싸고 개발 시간이 매우 깁니다.

(1) 다른 스레드에서 메모리로 동시에 액세스하는 것은 순차적 주소 여야합니다. 이것은 때때로 달성하기 정말 어렵습니다.


나는 CUDA와 함께 갈 것입니다.
저는 이미지 처리 분야에서 일하고 있으며 수년간 하드웨어 애드온을 사용해 왔습니다. 먼저 i860, Transputer, DSP, FPGA 및 하드웨어로 직접 컴파일을 사용했습니다.
필연적으로 일어난 일은 하드웨어 보드가 실제로 디버그되고 신뢰할 수 있고 코드가 이식되었을 때였습니다. 일반 CPU가이를 능가하거나 호스팅 시스템 아키텍처가 변경되어 이전 보드를 사용할 수 없었습니다. 이사회 제작자는 파산했다.

CUDA와 같은 것을 고수하면 FPGA 보드의 작은 전문 제조업체에 묶여 있지 않습니다. GPU의 성능은 CPU보다 빠르게 향상되고 있으며 게이머가 자금을 지원합니다. 이는 주류 기술이므로 향후 멀티 코어 CPU와 통합되어 투자를 보호 할 것입니다.


FPGA

  • 필요한 것 :
    • VHDL / Verilog 배우기 (그렇지 않을 거라고 믿으세요)
    • 테스트 용 hw 구매, 합성 도구에 대한 라이센스
    • 좋은 프레임 워크를 선택한 경우 (예 : RSoC )
      • 디자인 개발 (몇 년이 걸릴 수 있음)
    • 그렇지 않은 경우 :
      • DMA, hw 드라이버, 초고가 합성 도구
      • 버스, 메모리 매핑, hw 합성에 대한 수많은 지식
      • hw 구축, ip 코어 구매
      • 디자인 개발
  • 예를 들어 Xilinx virtex-6 칩이 포함 된 평균 FPGA pcie 카드는 3000 달러 이상입니다.
  • 결과:
    • 정부로부터 보수를받지 않으면 자금이 충분하지 않습니다.

GPGPU (CUDA / OpenCL)

  • 이미 테스트 할 hw가 있습니다.
  • FPGA 항목과 비교 :
    • 모든 것이 잘 문서화되어 있습니다.
    • 모든 것이 싸다
    • 모든 것이 작동합니다
    • 모든 것이 프로그래밍 언어에 잘 통합되어 있습니다.
  • GPU 클라우드도 있습니다.
  • 결과:
    • SDK를 다운로드하기 만하면 시작할 수 있습니다.

FPGA 기반 솔루션은 CUDA보다 훨씬 비쌉니다.


분명히 이것은 복잡한 질문입니다. 질문에는 셀 프로세서도 포함될 수 있습니다. 그리고 다른 관련 질문에 맞는 답은 하나도 없을 것입니다.

내 경험상, 추상적 인 방식으로 구현 된 모든 구현, 즉 컴파일 된 고수준 언어 대 기계 수준 구현은 필연적으로 성능 비용, 특히 복잡한 알고리즘 구현에서 발생합니다. 이것은 FPGA와 모든 유형의 프로세서 모두에 해당됩니다. 복잡한 알고리즘을 구현하도록 특별히 설계된 FPGA는 처리 요소가 일반적인 FPGA보다 성능이 뛰어나 입력 제어 레지스터, 데이터 I / O 등에서 어느 정도의 프로그래밍 가능성을 허용합니다.

FPGA가 훨씬 더 높은 성능을 발휘할 수있는 또 다른 일반적인 예는 프로세스 출력이 다른 프로세스에 대한 입력이되고 동시에 수행 할 수없는 계단식 프로세스입니다. FPGA의 계단식 프로세스는 간단하며 메모리 I / O 요구 사항을 크게 낮출 수 있으며 프로세서 메모리는 데이터 종속성이있는 둘 이상의 프로세스를 효과적으로 계단식으로 연결하는 데 사용됩니다.

GPU와 CPU에 대해서도 마찬가지입니다. 캐시 메모리 또는 메인 메모리 시스템의 고유 한 성능 특성과 관계없이 개발 된 CPU에서 실행되는 C로 구현 된 알고리즘은 구현 된 알고리즘만큼 성능이 떨어집니다. 물론 이러한 성능 특성을 고려하지 않으면 구현이 간단 해집니다. 그러나 성능 비용이 있습니다.

Having no direct experience with a GPU, but knowing its inherent memory system performance issues, it too will be subjected to performance issues.


This is an old thread started in 2008, but it would be good to recount what happened to FPGA programming since then: 1. C to gates in FPGA is the mainstream development for many companies with HUGE time saving vs. Verilog/SystemVerilog HDL. In C to gates System level design is the hard part. 2. OpenCL on FPGA is there for 4+ years including floating point and "cloud" deployment by Microsoft (Asure) and Amazon F1 (Ryft API). With OpenCL system design is relatively easy because of very well defined memory model and API between host and compute devices.

Software folks just need to learn a bit about FPGA architecture to be able to do things that are NOT EVEN POSSIBLE with GPUs and CPUs for the reasons of both being fixed silicon and not having broadband (100Gb+) interfaces to the outside world. Scaling down chip geometry is no longer possible, nor extracting more heat from the single chip package without melting it, so this looks like the end of the road for single package chips. My thesis here is that the future belongs to parallel programming of multi-chip systems, and FPGAs have a great chance to be ahead of the game. Check out http://isfpga.org/ if you have concerns about performance, etc.


CUDA has a fairly substantial code base of examples and a SDK, including a BLAS back-end. Try to find some examples similar to what you are doing, perhaps also looking at the GPU Gems series of books, to gauge how well CUDA will fit your applications. I'd say from a logistic point of view, CUDA is easier to work with and much, much cheaper than any professional FPGA development toolkit.

At one point I did look into CUDA for claim reserve simulation modelling. There is quite a good series of lectures linked off the web-site for learning. On Windows, you need to make sure CUDA is running on a card with no displays as the graphics subsystem has a watchdog timer that will nuke any process running for more than 5 seconds. This does not occur on Linux.

Any mahcine with two PCI-e x16 slots should support this. I used a HP XW9300, which you can pick up off ebay quite cheaply. If you do, make sure it has two CPU's (not one dual-core CPU) as the PCI-e slots live on separate Hypertransport buses and you need two CPU's in the machine to have both buses active.


I'm a CUDA developer with very littel experience with FPGA:s, however I've been trying to find comparisons between the two.

What I've concluded so far:

The GPU has by far higher ( accessible ) peak performance It has a more favorable FLOP/watt ratio. It is cheaper It is developing faster (quite soon you will literally have a "real" TFLOP available). It is easier to program ( read article on this not personal opinion)

Note that I'm saying real/accessible to distinguish from the numbers you will see in a GPGPU commercial.

BUT the gpu is not more favorable when you need to do random accesses to data. This will hopefully change with the new Nvidia Fermi architecture which has an optional l1/l2 cache.

my 2 cents


FPGA will not be favoured by those with a software bias as they need to learn an HDL or at least understand systemC.

For those with a hardware bias FPGA will be the first option considered.

In reality a firm grasp of both is required & then an objective decision can be made.

OpenCL is designed to run on both FPGA & GPU, even CUDA can be ported to FPGA.

FPGA & GPU accelerators can be used together

So it's not a case of what is better one or the other. There is also the debate about CUDA vs OpenCL

Again unless you have optimized & benchmarked both to your specific application you can not know with 100% certainty.

Many will simply go with CUDA because of its commercial nature & resources. Others will go with openCL because of its versatility.


What are you deploying on? Who is your customer? Without even know the answers to these questions, I would not use an FPGA unless you are building a real-time system and have electrical/computer engineers on your team that have knowledge of hardware description languages such as VHDL and Verilog. There's a lot to it and it takes a different frame of mind than conventional programming.


FPGAs have fallen out of favor in the HPC sector because they're a horrorterror to program. CUDA is in because it is much much nicer to program and will still give you some good performance. I would go with what the HPC community has gone with and do it in CUDA. It's easier, it's cheaper, it's more maintainable.


Others have given good answers, just wanted to add a different perspective. Here is my survey paper published in ACM Computing Surveys 2015 (its permalink is here), which compares GPU with FPGA and CPU on energy efficiency metric. Most papers report: FPGA is more energy efficient than GPU, which, in turn, is more energy efficient than CPU. Since power budgets are fixed (depending on cooling capability), energy efficiency of FPGA means one can do more computations within same power budget with FPGA, and thus get better performance with FPGA than with GPU. Of course, also account for FPGA limitations, as mentioned by others.


  • FPGAs are more parallel than GPUs, by three orders of magnitude. While good GPU features thousands of cores, FPGA may have millions of programmable gates.
  • While CUDA cores must do highly similar computations to be productive, FPGA cells are truly independent from each other.
  • FPGA can be very fast with some groups of tasks and are often used where a millisecond is already seen as a long duration.
  • GPU core is way more powerful than FPGA cell, and much easier to program. It is a core, can divide and multiply no problem when FPGA cell is only capable of rather simple boolean logic.
  • As GPU core is a core, it is efficient to program it in C++. Even it it is also possible to program FPGA in C++, it is inefficient (just "productive"). Specialized languages like VDHL or Verilog must be used - they are difficult and challenging to master.
  • Most of the true and tried instincts of a software engineer are useless with FPGA. You want a for loop with these gates? Which galaxy are you from? You need to change into the mindset of electronics engineer to understand this world.

at latest GTC'13 many HPC people agreed that CUDA is here to stay. FGPA's are cumbersome, CUDA is getting quite more mature supporting Python/C/C++/ARM.. either way, that was a dated question


Programming a GPU in CUDA is definitely easier. If you don't have any experience with programming FPGAs in HDL it will almost surely be too much of a challenge for you, but you can still program them with OpenCL which is kinda similar to CUDA. However, it is harder to implement and probably a lot more expensive than programming GPUs.

Which one is Faster?

GPU runs faster, but FPGA can be more efficient.

GPU has the potential of running at a speed higher than FPGA can ever reach. But only for algorithms that are specially suited for that. If the algorithm is not optimal, the GPU will loose a lot of performance.

FPGA on the other hand runs much slower, but you can implement problem-specific hardware that will be very efficient and get stuff done in less time.

It's kinda like eating your soup with a fork very fast vs. eating it with a spoon more slowly.

Both devices base their performance on parallelization, but each in a slightly different way. If the algorithm can be granulated into a lot of pieces that execute the same operations (keyword: SIMD), the GPU will be faster. If the algorithm can be implemented as a long pipeline, the FPGA will be faster. Also, if you want to use floating point, FPGA will not be very happy with it :)

I have dedicated my whole master's thesis to this topic. Algorithm Acceleration on FPGA with OpenCL

ReferenceURL : https://stackoverflow.com/questions/317731/cuda-or-fpga-for-special-purpose-3d-graphics-computations

반응형