CUDA GPU filters [Archive]

Malcolm

23rd November 2008, 00:51

I have asked for this multiple times in the past. My last thread about this topic was Request: Support for Pixel Bender Filters in Avisynth (http://forum.doom9.org/showthread.php?t=138000). Number of replies? ZERO!
Pixelbender is one flavor of how this can be done. But that's not the point actually. Currently OpenCL (http://en.wikipedia.org/wiki/OpenCL) would be the most generally usable and future safe solution.
I was thinking about putting another request, proposing OpenCL, but honestly didn't expected to find much resonance so i just abandoned it.

I'd like to point out 3 things:
1. I see a big slowdown in programming Avisynth filters over the last years when looking into the doom9 forum. There was a boom when Avisynth 2.x was new and people started to play around with SVCD and later DVDs. Also Avisynth development has slowed down a lot. (To be honest: Avisynth does a lot of stuff very good for a long time now, so this seems to be the main reason for the slowdown) There is mainly bugfixing, but nearly no progress technology-wise for years now. So, there seems to be no 'drive' or 'desire' to do this kind of stuff..
(Let me make this clear: I don't want to disgruntle the avisynth & filter developers. They did and still do great things!)
2. Avisynth is all about doing cool stuff with video (and this is inherently computational intensitive. Especially in the last years where motion compensation, filters working in frequency domain etc. have become popular) - But Avisynth development has failed in some way to support programming / execution of fast video filters: That is using the leading technologies of today: GPU and CPU-Multicore programming! (I know there are some things going on right now, but that's the case for years and progress is way too slow!) Maybe it would be a clever idea to add a library of highly optimized GPU/Multicore functions to Avisynth that are commonly used in video filters. This way, know-how ist mainly needed to create these functions inside Avisynth, whereas the filter programmers can focus on the main filter purpose and stay with C(++).
3. It's a 'people problem'. When asking to simply 'redo' 80% of all existing filters for avisynth in CUDA/CAL/OpenCL/GLSL/Pixelbender you need a lot of manpower. Best would be if the original programmers will do it. But where are they? Some of them have left the forum since years! How long will this take? Programming the original filters took years (including fixing of bugs)! (parallel) GPU programming is much more complex than single-threaded C(++) programming. Sometimes you need to change the algorithm completely. (So you can't just 'redo' it in a schematic way) And so on...

Fizick

23rd November 2008, 09:02

Thing number 4:
Instead of asking somebody to implement somewhat, sit down, learn "how-to", and try (start) implement it. Then you will got much more support and "replies" ;)

Malcolm

25th November 2008, 19:07

Apple announced OpenCL (or the Open Computing Language) in early June, promising the C-based programming interface would allow developers to "efficiently tap the vast gigaflops of computing power currently locked up in the graphics processing unit." Think of OpenCL as an open, royalty-free cousin of Nvidia's CUDA and AMD's Brook+ that's designed to work with all kinds of hardware—even "cheesy integrated graphics" and x86 microprocessors, Mattson says. The OpenCL working group includes AMD, Nvidia, and Intel.http://techreport.com/discussions.x/15935

If we really want avisynth to thrive and prosper (again) then it's time to talk about supporting / switching to OpenCL! I think of people like sh0dan, Bidoche, Fizick, IanB, Wilbert, Richard Berg, ...
In the future CPUs will only grow in number of cores. And rather shrink than grow in no. of operations/clock or clocks/second! Also GPUs will scale by number of shaders (~cores). That's what they already for some time now.

Malcolm

26th November 2008, 22:42

322 reads and only one answer besides mine so far...
Let's talk about tsps 'MT filter'. (Sorry tsp, i should have mentioned you in the list of people above. I'm sure you are one of the key players regarding this topic).
There are currently 1002(!) replies in the 'MT 0.7' thread and nearly 160.000 reads! Everyone that has posted there should care about this thread too! Why?
I really do honor tsps work for adding multithreading support to avisynth. And i really don't want to bash what he did. I'm sure he did the best he can considering the technical circumstances. But ultimately 'MT filter' is nothing but a hack!
I state that more than 80% of all posts in the 'MT 0.7' thread exist because of strange & erroneous behaviours when running filters multithreaded the way MT does it (has to do it). People fiddle around for hours, writing hundreds of posts and are happy when their script is accelerated by a factor of 1.4! Wow!
I mean video processing is a prime example for parallelizable algorithms! Think 3 years into the future: 32 core CPUs and you have to wait 10 hours for the encode to finish because avisynth is only able to use one (or two) of the cores. That's ridiculous!
.. And MT filter is certainly not able to scale to 32+ cores! (Sorry tsp, i don't mean it this way. I'm sure you'll understand what i'm trying to say!)
It's avisynths job to provide an environment where script writers do not have to think at all about if and how this or that combination of filters can be used multithreaded in their script. Also filter programmers should be provided with an API that gives a clear structure of how filters have to be written so they can safely be executed in parallel. Ideally filter programmers can concentrate on the core filter function and not about what must be done to use multiple CPU cores or GPU shaders simulaneously. OpenCL is specifically intended for this.

I'm curious about how many post this thread will get over time :rolleyes:
But i fear nowadays a lot of people here are only interested to get a 'solution' for their problem within the next 5 minutes...

Guest

26th November 2008, 22:58

I agree with Fizick.

Sagekilla

26th November 2008, 23:02

@Malcolm: Unfortunately you can't just expect filters to run multithreaded automatically. There's quite a few of them out there that create temporal dependencies, and you start having a situation where to filter one frame, you have to have the previous frame which depends on two other frames and so forth.

There's lots of functions that run just like that. And in situations like this, it'd be very difficult to efficiently multithread it.

Fizick

26th November 2008, 23:06

Well, one more post. :)
1. As I write above, try at least look to the real code.
2. you probably know, that tsp's "MT filter" and "SetMTMode" are different things. IMO, both may be scaled to 32 (may be with some adjusting, e.g. both vertical and horizontal splitting for MT Filter).
3. are you know details of unpublished OpenCL or you siply repeat some adv article ? :)
4. this thread should be moved to "Avisynth development" subforum ;)

Malcolm

26th November 2008, 23:52

Fizicks answer is the standard answer of the avisynth devs here. It's certainly correct. But you can't (and shouldn't) stall every discussion with it.
I'm a software engineer and do programming on a professional base for nearly 15 years. I don't want to elaborate on which languages and technologies i have used, but you'll certainly can imagine that it's a lot. I also know fairly well what it means to write graphical & multithreaded software ;). Although i'm not the one who's going to extend / rewrite avisynth, i think what i have to say has a point. So should i stop talking because i can't provide some code?

Come on guys, each of your answers sounds as if you want to give a short statement, just to end this talk as fast as possible! I'd like to create a prolific discussion about how avisynth can get where i (or we?) would like to see it in the future!
(Now don't remind me of Fizicks 'thing number 4' :p)

@Fizick:
To point 3: No, i don't know about any details from OpenCL. Although i have read multiple papers & code about CUDA, GLSL & Pixelbender. Some of them from Siggraph. But is that really the point? Do i have to know any details about OpenCL for this discussion? Certainly not. We all know enough about the stated technologies and what they're supposed to do. OpenCL is just an example and will probably do what it's designed for.
To point 4: Yeah! But since i didn't started the thread...

@Sagekilla:
I know about the problems with avisynth and the way multithreading is implemented currently. (Dependencies and so on). That's what i mean with 'technical circumstances). It's certainly not the best way of how multithreading can be done in avisynth.
The aforementioned APIs use multithreading in a different way - a way that scales much better with lots of cores/shaders.

Anyway, the key sentence is marked in blue.

Cheers!

Guest

26th November 2008, 23:58

Despite your claims, to me you sound naive about the realities of threading.

Please sketch the main design idea you have for Avisynth threading.

Malcolm

27th November 2008, 00:24

"to me you sound naive about the realities of threading"
Thank you! What a nice compliment! :rolleyes:
I know what i'm talking about. I i don't have to 'prove' it! I'm not asking you to prove anything either. If you think i'm too 'naive' you can stop talking with me.

The mentioned APIs force you to write code that can be executed in parallel. Thread execution (Scheduling) is typically done by the 'driver' (CUDA driver, OpenCL driver, ...) So you don't have to care (a lot) about. That's the nice thing.
So this could already be one answer for your question of how to do 'Avisynth threading'.

As i said above. another idea could be that avisynth includes a library of functions that are often used by filters. Let's say filter 'building blocks'. They would be programmed in the OpenCL C-Language.
This is one idea for 'Avisynth threading'. Maybe a good one, maybe a bad one. Maybe we need another 3 methods, so filters (i know, they can work very differently) can effectively use multiple cores/shaders.
I think this thread is the place where all other readers can provide their ideas too.

Malcolm

27th November 2008, 00:31

@neuron2
Do you rather like threads that go like this:

Help me! My source that i have just downloaded from thepiratebay.org is so blocky and noisy! What is the best filter to clean it?

Just kidding :)

Fizick

27th November 2008, 06:22

Malcolm, I never said that I disagree with point 3 your first post. :)
But I disagree with your suggested list of developers (Ben, etc).
For hard goals you provided we really need in new (additional) developers.

IMHO, new (sub)project like "avisynth 4.0 for Windows" may be created. :)
Reason: v2.x must preserve compatibility with old 2.x plugins,
v3.0 has too wide platform list (that is serious task itself).

I (or you) can create v4 project at sourceforge tomorrow, and declare its compatibility with OpenCL
;)

vcmohan

27th November 2008, 07:05

Is it Open GL or Open CL ? I could not get any reference to Open CL when Googled.

Leak

27th November 2008, 09:37

Is it Open GL or Open CL ? I could not get any reference to Open CL when Googled.
Probably because it's actually "OpenCL" (http://en.wikipedia.org/wiki/OpenCL) (without the space)... ;)

IanB

28th November 2008, 01:04

So, realistically what extra do you need from the Avisynth core services?

Given only a cursory look at the issue I can see nothing obvious to impede anyone writing plugins that use or support this technology. There are already GPU based filters in existance. Maybe deeper analysis will reveal some issue but for now I only see lack of manpower as the problem.

Malcolm

28th November 2008, 11:27

Ok, it's clear that right now anyone is already able to write plugins that use CUDA or one of the other APIs.
Since i'm not an avisynth dev, i can only speculate about how much it will bring, if Avisynth directly supports OpenCL.

But here are my assumptions:
1. A lot of the core Avisynth functions could be (re)written for OpenCL. That would bring at least some performance gain. Maybe Avisynths core functions could use cpu core2 (or all cores), all other (legacy) plugins could use core1 of your cpu...
2. When writing independent OpenCL plugins you have to do things like the following multiple times and separated from each other: Create a OpenCL context, create a work queue, allocate memory (maybe copy/transform the frame content to my mem in a way that it's suitable for OpenCL), run the compute kernel (my 'filter').
If i have direct support in Avisynth for OpenCL, it could be sufficient to do only the last step (run the compute kernel), because everything else is already done (once for all filters) by Avisynth.
I guess you (Ian) will know better if my 'maybes' and assuptions are correct or wrong.
It could well be that 'collecting' multiple compute kernels ('filters') and executing them on a single context will be much more efficient (higher fps, more cores used) than doing this separately.
Edited: Also, letting Avisynth control the execution could lead to a lower memory consumption, could also mean it's more robust when chaining multiple OpenCL plugins (one context, multiple kernels instead of n contexts).
3. Adding explicit support for OpenCL could motivate plugin writers to actually use the technology! At the moment the situation is like this: "Sure you can write a plugin using CUDA. How? Oh, i have no idea! You have to look for yourself!"
But it could as well be like that: "Hey, Avisynth already has this sleeky API that makes it soo easy to write an OpenCL plugin. You just have to do these few steps to get you first plugin running..."
Maybe it's not much technology behind OpenCL support in Avisynth, but knowing that OpenCL is the preferred way for writing plugins will already help
I'm sure we would all profit from this...

MfA

28th November 2008, 12:50

So, realistically what extra do you need from the Avisynth core services?
Standardized (ie. core) way to pass GPU side images from GPU filter to GPU filter would be nice ... crossing the bus and the FP->8-bit->FP conversions each time isn't only bad for precision but also performance.

Really though at that point you would want all the core filters to be FP compatible :)

mikeytown2

29th November 2008, 09:24

One idea I have on how to multithread AviSynth is to have a cascading cache. It would have to be in the 64bit version because it would eat ram like crazy; but this is how I envision it working. Lets say you have 10 filters, the output would be delayed by 10 frames, so the start and end wouldn't be multithreaded but, in the middle it would be. Filter A is doing frame 3 while Filter C is doing frame 1, ect. In order to decrease ram usage you could use some form of lossless compression on the frame.

In short it's glorified prefetching using other threads to get the frame ready.

vcmohan

29th November 2008, 11:19

For those (me for instance) using integrated graphics of mother board does this help in any way?

Gavino

29th November 2008, 13:24

One idea I have on how to multithread AviSynth is to have a cascading cache.
...
In short it's glorified prefetching using other threads to get the frame ready.
This sounds similar to the pipeline approach described in this thread, and would have to be done carefully to avoid the problems I pointed out there. The hopeful news comes in IanB's post there:
Okay this is all pretty close to an idea I am gestating for properly doing multithreading in avisynth 2.6. ...

Malcolm

9th December 2008, 13:21

The Khronos Group has released the Open CL 1.0 Specification yesterday. http://www.khronos.org/news/press/releases/the_khronos_group_releases_opencl_1.0_specification/“The opportunity to effectively unlock the capabilities of new generations of programmable compute and graphics processors drove the unprecedented level of cooperation to refine the initial proposal from Apple into the ratified OpenCL 1.0 specification,” said Neil Trevett, chair of the OpenCL working group, president of the Khronos Group and vice president at NVIDIA. “As an open, cross-platform standard, OpenCL is a fundamental technology for next generation software development that will play a central role in the Khronos API ecosystem and we look forward to seeing implementations within the next year.”

“We are excited about the industry-wide support for OpenCL,” said Bertrand Serlet, Apple's senior vice president of Software Engineering. “Apple developed OpenCL so that any application in Snow Leopard, the next major version of Mac OS X, can harness an amazing amount of computing power previously available only to graphics applications.”

OpenCL enables software developers to take full advantage of a diverse mix of multi-core CPUs, Graphics Processing Units (GPUs), Cell-type architectures and other parallel processors such as Digital Signal Processors (DSPs). OpenCL consists of an API for coordinating parallel computation and a programming language for specifying those computations.
Open CL ist strongly backed up by AMD, as well as Apple but also NVidia. According to a different source citing NVidia, Open CL applications are already running on every CUDA supported GPU. Also, the upcoming ATI Stream SDK from AMD will support Open CL.

Guest

9th December 2008, 14:44

That's a crucial step. Now we await the availability of libraries and run-time systems.

leeperry

9th December 2008, 16:20

some way to use PS scripts in Avisynth through CUDA would be really awesome...

atm they can only be used in realtime in MPC/KMP in VMR9/EVR, or in Avishader() but the frames go back and forth between the CPU<>GPU so it's a CPU hog :(

Antitargo(who wrote Avishader()) said it could be possible to do it w/ CUDA :eek:

Ranguvar

12th December 2008, 04:11

leeperry

12th December 2008, 10:16

@leeperry, I think most people are in agreement that any serious work on GPU assistance should wait until there's an open (at the very least, backed by most of the big hardware graphics companies) API for it. There are those who are going full steam ahead for their own interests, but they know full well that they will likely have to eventually switch to OpenCL or something similar. Convincing someone to start development on a project with an API that might well be deprecated very soon will not be easy ;)

Of course, I'm not too familiar with Photoshop, so it may well be that all I have said so far is garbage and it's a relatively simple chore.
PS=Pixel Shaders....what you can currently use in MPC ;)

well CUDA is most likely here to stay...and getting 100% GPU PS scripts in AVS through CUDA could be a huge time saver, like 3D LUT gamut conversions :
http://www.avsforum.com/avs-vb/showthread.php?t=912720

this is piece of cake for a GPU, a lot more work for a CPU(Avishader() in realtime puts my o/c Q6600 to its knees :scared: )

Ranguvar

12th December 2008, 17:16

Well then, I seem to have failed :p

Malcolm

12th December 2008, 18:32

Just to keep you informed:AMD today announced its intent to rapidly adopt the OpenCL 1.0 programming standard and integrate a compliant compiler and runtime into the free ATI Stream Software Development Kit (SDK).

OpenCL 1.0 was ratified today by the The Khronos Group, an independent standards body with company-members throughout the computing industry. The OpenCL programming standard and associated technologies are aimed at better enabling developers to write vender-neutral applications that can execute on either the CPU or GPU within a system. This allows developers to easily take advantage of whichever processor is best suited for the task at hand.

"The potential benefits of having applications run on both the CPU and GPU within a system are enormous," said Rick Bergman, senior vice president and general manager, Graphics Products Group, AMD. "Unfortunately, up until now programmers could only choose proprietary programming languages that limited their ability to write vendor-neutral, cross-platform applications. With today's ratification of OpenCL 1.0, I'm happy to say those days are over. Developers now have a better, truly open choice."

AMD is a founding and contributing member of the OpenCL working group in The Khronos Group, and has consistently been one of the most vocal and active proponents of the standard. AMD is committed to getting this valuable new technology into the hands of programmers as quickly as possible, and is rapidly evolving its free ATI Stream SDK to make it happen. AMD is making good progress on its OpenCL-compliant offering and plans to release a developer version of the ATI Stream SDK with support for OpenCL 1.0 for content developers in the first half of 2009. Working from early specifications of OpenCL, AMD's engineering team has already started running code on its initial implementation.@leeperry: If you look into the Open CL 1.0 specification, you can see that a lot of people from NVidia have contributed to it (besides Apple, AMD and others). So NVidia stands behind Open CL as well. IMHO Avisynth should focus on Open CL rather than CUDA for obvious reasons...

leeperry

12th December 2008, 23:07

...except that CUDA is operational as we speak, apparently OpenCL beta components for nvidia will start showing up in spring 2009, and final versions on summer....so we're talking about another +8 months from now.

you can watch the slides here :
http://www.hardware.fr/articles/744-3/opencl-gpu-computing-enfin-democratise.html

Malcolm

13th December 2008, 00:31

...except that CUDA is operational as we speak
Exactly! CUDA is already here for some time now. But so far no one had enough interest to start coding something CUDA-related for Avisynth... ;) That's why i think we need a new - more general and hardware/vendor independent (say OpenCL) approach. So that everything that is written runs anywhere - be it a Geforce, Radeon, Larrabee, Core or Opteron.

By the way: [snip] - Looks less than 8 month to me... ;)

Malcolm

15th December 2008, 23:36

There is some more info from NVidia regarding Open CL. Slide 2 and 3 should make clear, that NVidia stands behind Open CL.
http://img385.imageshack.us/img385/9733/nvidiaopencl1vj1.th.jpg (http://img385.imageshack.us/my.php?image=nvidiaopencl1vj1.jpg) http://img385.imageshack.us/img385/9601/nvidiaopencl2xg4.th.jpg (http://img385.imageshack.us/my.php?image=nvidiaopencl2xg4.jpg) http://img167.imageshack.us/img167/6769/nvidiaopencl3wm1.th.jpg (http://img167.imageshack.us/my.php?image=nvidiaopencl3wm1.jpg) http://img385.imageshack.us/img385/9093/nvidiaopencl4lq0.th.jpg (http://img385.imageshack.us/my.php?image=nvidiaopencl4lq0.jpg)

squid_80

16th December 2008, 00:35

All well and good, but as people have already said at the moment OpenCL is nothing but some header files. So nothing can be even be attempted until support is added to the drivers. (I will bet any money NVIDIA delivers before ATI - OpenCL's API is very similar to CUDA's.)

MfA

16th December 2008, 01:23

Until someone feels like doing the actual programming it's a bit moot.

bill_baroud

16th December 2008, 12:05

(I will bet any money NVIDIA delivers before ATI - OpenCL's API is very similar to CUDA's.)
To the point that a few mandatory things (like minimum double precision floating-point capability) in OpenCL are for the moment only supported by Nvidia, strange isn't it ?

Fizick

12th January 2009, 20:11

CUDA in virtualDub filter
http://vlafy.iulabs.com/rus/vdubfilters.htm

CruNcher

13th January 2009, 10:49

Nice they/he have/has some great other stuff their too thx fizick :)

leeperry

1st April 2009, 04:46

some double framerate interpolation GPU computed would be really awesome :)

I guess that doesn't exist yet?

leeperry

1st April 2009, 12:10

http://www.liquidsonics.com/publicbeta/
VST convolution reverb for PC, powered by NVIDIA Cuda

unix_sansei

9th April 2009, 21:24

everyone is aware that GPU programming is only single precision? so all the heavy duty precise number crunching routines, FFT's etc still need to be done on CPU.

LoRd_MuldeR

9th April 2009, 21:26

Doesn't CUDA 2.0 add double precision support?

unix_sansei

10th April 2009, 11:54

the last time i benchmarked with Matlab, it's still single precision.

here's latest

http://developer.nvidia.com/object/matlab_cuda.html

MfA

10th April 2009, 14:12

everyone is aware that GPU programming is only single precision?
No, I'm not ... even my ancient 3870 supports double precision and newer NVIDIA cards do as well.
so all the heavy duty precise number crunching routines, FFT's etc still need to be done on CPU.
Considering the size and dynamic range of images double precision is overkill.

unix_sansei

10th April 2009, 21:40

No, I'm not ... even my ancient 3870 supports double precision and newer NVIDIA cards do as well.

Considering the size and dynamic range of images double precision is overkill.

where did you find that GPU support double floats? i run ati 4850, it's single.

are you joking? run a comparison of the PSNR on a single precision image vs double with denoising or any Gaussian or wiener filter. the double precision will blow away the PSNR of single EVERY time.

From NVIDIA CUDA docs.

"The MATLAB code is running in double-precision and the data is transformed to
single-precision before it is transferred to the GPU. The computation on the GPU
is performed in single precision and the result is transformed back to double
precision before it is returned to MATLAB. "

Please post your source for double precision.

MfA

10th April 2009, 23:25

unix_sansei

11th April 2009, 00:24

There is a world beyond matlab and high level libraries. There has been CAL support for DP for close to one year.

Single precision FFTs in FFTW have relative errors close to 10^-7. A small radius Gaussian (ie. r ~= 10) will not give large errors either, a naive implementation of very large radius gaussian filters might ... but there is a simple solution to that, don't implement it naively.

Wiener filter is a bit of a special case because Levinson Durbin can blow up under some circumstances, but it's not exactly a popular type of filter in these here parts ...

Thanks for interesting reply, not often I get to chat about numerical computations.

When I need a numerical sledgehammer, I compile FORTRAN, old school F77, but for rapid prototyping solutions Matlab/Maple is the way to go. While you're debugging cpp and asm, I've already built, prototyped, and profiled algorithms. Converting to f77 is trivial.

Anyway, with SP FFT errors, if you start getting errors, dithering, 'stuck' bits, your noise floor with 'virtually' go through the roof, with DP, at least your noise floor is starting out in the 'dirt' rather than the 'grass' as with SP.

I've exchanged emails the MIT guys, who built FFTW, a couple years ago about GPU vs CPU, they said CPU was way to go. I've got a paper from them somewhere in the archives.

From my experience, Weiner's are about the best noise filters around, they stomp all over any linear filter. I've not tested one that comes close to the performance. You have an alternative to Weiner to propose? I'll try it on some of my images and let you know the PSNR of Weiner vs. your alternative.

MfA

11th April 2009, 01:56

unix_sansei

11th April 2009, 20:06

FFT is linear, if your code isn't buggy and your constants are accurate there is just not that much that can happen unexpectedly. We have a tiny dynamic range on the input and we use tiny FFTs ... color me skeptical.

As for an alternative to Wiener filter ... to keep it simple and relatively fast, how about the Bilateral filter?

it's not just about dynamic range, whatever math you using, you need to look at number theory. for example big numbers divided by small inaccurate numbers leads to big inaccurate numbers. small inaccurate numbers divided by small inaccurate numbers still lead to inaccurate numbers. the errors compound.

well tiny is relative, if you're talking SD or less image sizes at 8-bit, ok, i'd agree, if you talking about 2k or 4k images at uint16, i wouldn't.

maybe you're breaking up the image space, using windowing and overlapping.

for me i don't care about speed or being simple, it's quality, driving the noise floor right into the dirt, 6 feet under, to get maximum PSNR. i think i can whip up a bilateral easily enough.

swaaye

20th April 2009, 17:05

FFT3DGPU uses FFT obviously and I've been eternally curious and comparing the difference between its half precision and single precision settings. It defaults to FP16. The difference between FP16 and FP32 is there but I'm not sure that there's actually an improvement at full single precision. It's a different result sure, but subjectively I'm not sure I would say that it's "better" at FP32.

From what I've read about double precision and GPUs, it is there in ATI's RV670 and newer high-end GPUs. It is a lot slower than single precision though. Half speed, I believe. And of course there is also going to be a speed impact from added data size which will depend on how much RAM bandwidth you need. I've seen a substantial difference between just FP16 and FP32. I run FFT3DGPU on a Radeon 4670 and a 3850, both of which have similar GPU capabilities but the 3850 has nearly 2x the RAM bandwidth and it definitely shows.