I am just wondering why Thetis does not actively use CUDA cores from NVIDIA graphics cards to assist in processing?
I know that Simon uses them on SDR-Console & there is a big difference in CPU usage.
FFT can be shoved out to CUDA & leave the CPU to do what it's meant to, by my understanding.
Ed
WA4SIX
Why not use CUDA cores?
Re: Why not use CUDA cores?
I've wondered that myself, it would help a marginal CPU if some of the workload could be transferred to the graphics card if one was present.
Mark
Mark
Re: Why not use CUDA cores?
I remember from TeamSpeak sessions, that Warren NR0V was working on this within the context of ChannelMaster support for the DFC (Direct Fourier Conversion) based Minerva board. The trouble he was having was related to thread scheduling of the CUDA cores, in support of the multi-threaded requirements of ChannelMaster (protocol-2). It wasn't working out the way he was expecting and wasn't sure of the way forward.
Does Simon's SDR Console use CUDA cores for protocol-2 or just protocol-1?
73, Bryan
Does Simon's SDR Console use CUDA cores for protocol-2 or just protocol-1?
73, Bryan
Re: Why not use CUDA cores?
AFAIK, SDR Console uses CUDA cores (where available--not everyone has a CUDA capable GPU) for all FFT calculations for all hardware types SDR Console supports, not just openHPSDR hardware.
The answer to this question, and every other question that starts with "Why doesn't Thetis do...", is:
Because no developer was interested in doing it.
It's really that simple.
This is not a market-driven environment we live in with our openHPSDR software. Our radios exist at the whim and desires of the people who we are lucky enough to have writing code. If you can convince one of them that the feature or capability you want is interesting enough or important enough then perhaps they might sit down and write it. Because it has to be fun and interesting for them, not drudgery. Otherwise why else would they do it?
It also needs to be within their repertoire or, if it is not, they need to see it as fun or useful to add to their repertoire. Other than Simon, I'm not aware of anyone who is programming CUDA code. It's apparently not a common skill set.
No doubt there are a lot of potential arguments against CUDA:
- It's not fully open (but there is OpenCL as an alternative)
- It only supports those with Nvidia CUDA hardware (but again there is OpenCL which runs on AMD et al)
- It's not really necessary (IMHO it is desirable even for those with fast machines, but that's just my opinion)
- It requires substantial rework/refactoring of Thetis (probably true)
- It's "yet another option" for Thetis in a vast sea of existing Thetis options, how complex do you want the code to be? Because you do need to support non-CUDA environments.
The answer to this question, and every other question that starts with "Why doesn't Thetis do...", is:
Because no developer was interested in doing it.
It's really that simple.
This is not a market-driven environment we live in with our openHPSDR software. Our radios exist at the whim and desires of the people who we are lucky enough to have writing code. If you can convince one of them that the feature or capability you want is interesting enough or important enough then perhaps they might sit down and write it. Because it has to be fun and interesting for them, not drudgery. Otherwise why else would they do it?
It also needs to be within their repertoire or, if it is not, they need to see it as fun or useful to add to their repertoire. Other than Simon, I'm not aware of anyone who is programming CUDA code. It's apparently not a common skill set.
No doubt there are a lot of potential arguments against CUDA:
- It's not fully open (but there is OpenCL as an alternative)
- It only supports those with Nvidia CUDA hardware (but again there is OpenCL which runs on AMD et al)
- It's not really necessary (IMHO it is desirable even for those with fast machines, but that's just my opinion)
- It requires substantial rework/refactoring of Thetis (probably true)
- It's "yet another option" for Thetis in a vast sea of existing Thetis options, how complex do you want the code to be? Because you do need to support non-CUDA environments.
-
laurencebarker
- Posts: 225
- Joined: Mon Nov 11, 2019 7:39 pm
Re: Why not use CUDA cores?
I would just add to that:
The code that would be affected is WDSP rather than the "main body" of Thetis; so the scope is well bounded.
if there are any developers out there that are interested, there are opportunities here!
The code that would be affected is WDSP rather than the "main body" of Thetis; so the scope is well bounded.
if there are any developers out there that are interested, there are opportunities here!
Laurence Barker G8NJJ
Re: Why not use CUDA cores?
laurencebarker wrote:I would just add to that:
The code that would be affected is WDSP rather than the "main body" of Thetis; so the scope is well bounded.
if there are any developers out there that are interested, there are opportunities here!
Excellent point, Laurence!
Question: how much code is in WDSP that wasn't written by Warren Pratt, NR0V? It's pretty much his amateur radio magnum opus and a major part of that which made our radios the technological tour de force that they are. People might be afraid to touch it without his permission, but he's a super nice guy and I'd bet he'd be very supportive of work like that.
-
John-G0ORX
- Posts: 17
- Joined: Sun Apr 09, 2017 4:24 pm
Re: Why not use CUDA cores?
I have not looked at CUDA for several years but did work on the CUDA code for the DFC code running on a Jetson SBC.
One of the early problems was that the amount of time taken copying the buffer to and from the GPU made the speed of the CUDA FFT not worthwhile compared with using FFTW. Especially as the buffets were relatively small.
The advantage of the Jetson at the time was that it used shared memory so there was no copying of buffets.
Nvidia do have the cuFFT library that they describe as:
The cuFFTW library is provided as a porting tool to enable users of FFTW to start using NVIDIA GPUs with a minimum amount of effort.
-- John G0ORX
One of the early problems was that the amount of time taken copying the buffer to and from the GPU made the speed of the CUDA FFT not worthwhile compared with using FFTW. Especially as the buffets were relatively small.
The advantage of the Jetson at the time was that it used shared memory so there was no copying of buffets.
Nvidia do have the cuFFT library that they describe as:
The cuFFTW library is provided as a porting tool to enable users of FFTW to start using NVIDIA GPUs with a minimum amount of effort.
-- John G0ORX
Re: Why not use CUDA cores?
If GPU data transfer is somehow a bottleneck (which seems unlikely in this day and age of 120Hz frame rate, ultra-low latency gaming, there is another option.
The vast majority of CPUs now come with on chip GPUs and they share the same memory and are highly integrated. OpenCL provides extensive support for a wide variety of modern (and not so modern) AMD and Intel products. Not only is this more "open", but it removes the requirement to own an Nvidia CUDA-capable product.
The vast majority of CPUs now come with on chip GPUs and they share the same memory and are highly integrated. OpenCL provides extensive support for a wide variety of modern (and not so modern) AMD and Intel products. Not only is this more "open", but it removes the requirement to own an Nvidia CUDA-capable product.
Re: Why not use CUDA cores?
If I remember right, Simon uses CUDA & Open CL.
This was just one of my meandering thoughts, as I play with Thetis 2500 miles from my HL-2. Wish I had set it up for remote, but thought I was only going to be here for 4 days, not a few weeks.
Thank you,
Ed Grafton
WA4SIX
This was just one of my meandering thoughts, as I play with Thetis 2500 miles from my HL-2. Wish I had set it up for remote, but thought I was only going to be here for 4 days, not a few weeks.
Thank you,
Ed Grafton
WA4SIX