It might be helpful to disclose which version of FLACCL is being used in the testing. As Gregory stated earlier: " i should update or remove the separate FLACCL download to avoid confusion - right now it's out of date compared to the one that comes with CUETools 2.1.5."
That's very interesting, but i'm afraid not very practical for FLACCL for a number of reasons - prohibitive cost, tiny potential audience, and finally - unlikely to live up to this 15x promise.FLACCL on any average discrete GPU already runs faster than disc IO. Any significant improvement would be limited by SSD speed.And the saddest part - it's just not likely to be that fast on actual tasks such as FLAC compression.A quick look at the specs of some of those shows significant hardware limitations as compared to GPUs - for example, one of them sports a 72-bit data bus. That's 2-3 times less that your average GPU. And that is what will likely determine the speed on compression tasks.
edit:what makes it even more impressive is when you add --cpu-threads 4 to the commandline it does cpu+gpuResults : 1252,36x; 462606149 bytes in 00:00:02.8448465 seconds;
i don't see why there could be a limitation in disk IO, 460 mb in ~4 seconds (~120 mb/s) should be no problem for a normal disc
cbits = min(cbits, clz(order + 1) + 1 - shared.task.obits);
5:54:53 of music to flac:2:15 libflac1.2.1 157,7x1:18 flacCL 272,9x1:10 flac64_d 304,18x
The thing is, it works fine for say, 10 albums. Then I have to restart the PC to make it work again, so something goes wrong.Running 4 openCL instances gives me a boost of about 50%, so it's not bottlenecking anything. It's more like there is some sort of memory leak except it doesn't show on gpu-z's memory usage.Also, for some reason, using "--lax -11 --verify - -o %d" (or %s instead of piping) via foobar exits the encoder with code 1, doing the same via command line encodes fine... that's probably a foobar issue.
I lately compiled the needed flacCL files at 30.06 if anyone is interested.