IPB

Welcome Guest ( Log In | Register )

17 Pages V  « < 15 16 17  
Reply to this topicStart new topic
FLACCL: CUDA-enabled FLAC encoder by Gregory S. Chudov (prev. FlaCuda), Formerly "lossless codecs and CUDA"
bilbo
post Aug 4 2013, 14:58
Post #401





Group: Members
Posts: 190
Joined: 16-April 07
Member No.: 42593



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."


--------------------
Glass half full!
Go to the top of the page
+Quote Post
ktf
post Aug 4 2013, 18:21
Post #402





Group: Members
Posts: 306
Joined: 22-March 09
Member No.: 68263



QUOTE (bilbo @ Aug 4 2013, 15:58) *
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."

If you take a good look at the graphs you can see it's 2.1.5.


--------------------
Music: sounds arranged such that they construct feelings.
Go to the top of the page
+Quote Post
Propheticus
post Aug 5 2013, 00:24
Post #403





Group: Members
Posts: 218
Joined: 10-September 11
Member No.: 93615



I downloaded the latest version I could find of the standalone Flaccl (0.3) since I didn't need/want cuetools. Why this would be a less recent version than what is bundled with the cuetools eludes me. I expected these to be the same.

This post has been edited by Propheticus: Aug 5 2013, 00:25
Go to the top of the page
+Quote Post
Wombat
post Aug 5 2013, 00:30
Post #404





Group: Members
Posts: 950
Joined: 7-October 01
Member No.: 235



If you follow the thread you'll see i always test the latest versions bundled with CUEtools. I reported several issues over time to Grigory. Unfortunately the flacCL page at the CUEtools Wiki isn't exactly well documented. This means i sometimes find out it suddenly behaves different without a notice anywhere. I always copy out the needed files to use it with a frontend for my usage.
You need CUETools.Codecs.FLACCL.dll, CUETools.FLACCL.cmd.exe, CUETools.Codecs.FLAKE.dll, CUETools.Codecs.dll, OpenCLNet.dll and flac.cl
Go to the top of the page
+Quote Post
JuanPabloCuervo
post Sep 16 2013, 18:57
Post #405





Group: Members
Posts: 16
Joined: 7-June 06
Member No.: 31567



Hi,

i just found out about the "new technology", FPGA PCIe OpenCL compatible cards.

have found 3 brands with Altera chips, i like more Xilinx, donīt know why.
http://www.nallatech.com/opencl-fpga-accelerator-cards.html
http://www.bittware.com/opencl-for-altera-fpgas
http://www.plda.com/products/boards/low-pr...5-lp-he?pid=205

http://www.altera.com/products/software/pa...paign=quartus13
http://www.khronos.org/opencl/
arround $1000usd.

Im eager to get one of those cards....

look the video at 18:20
FPGA vs. HD7970 vs. Xeon, "15x times faster than GPU."
http://www.youtube.com/watch?v=OAkHjyhJgWk

This post has been edited by JuanPabloCuervo: Sep 16 2013, 18:58
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Sep 17 2013, 19:56
Post #406





Group: Developer
Posts: 683
Joined: 2-October 08
From: Ottawa
Member No.: 59035



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.


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
JuanPabloCuervo
post Sep 18 2013, 03:34
Post #407





Group: Members
Posts: 16
Joined: 7-June 06
Member No.: 31567



QUOTE (Gregory S. Chudov @ Sep 17 2013, 13:56) *
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.


The SSD limitation can be solved....with RAID 0,
but, i thought what makes AMD faster than NVIDIA doing BruteForce stuff *Not Games, itīs because the parallel processing.
FPGA is King, ASIC God.

LuxMark benchmark, crark, Flaccl, hashcat, Bitcoin, etc...
http://www.extremetech.com/computing/15346...-bitcoin-mining

I had AMD, Personally i like more Nvidia, but this new FPGA could be smile.gif
http://www.luxrender.net/wiki/LuxMark#Download
http://www.luxrender.net/luxmark/

This post has been edited by JuanPabloCuervo: Sep 18 2013, 03:36
Go to the top of the page
+Quote Post
SigHunter
post Oct 6 2013, 00:35
Post #408





Group: Members
Posts: 42
Joined: 22-September 08
Member No.: 58544



did some testing for myself,

encoding an album of 59 minutes 23 seconds to flac

using the FLACCL from CUETools 2.1.5 (-11 and --fast-gpu)
on a radeon 7970
Results : 1002,26x; 462606149 bytes in 00:00:03.5547364 seconds;

using flac 1.3.0 64bit build r(-8)
on a xeon E3-1230 v3
Results : ~77x; 463919480 bytes in ~46 seconds;
(measured with powershell "Measure-Command")

this is impressive, though the CPU-test was just single threaded and i could spawn more parallel encodings during that time

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 (for me my raidcontroller cache eats most of it)


edit:
what makes it even more impressive is when you add --cpu-threads 4 to the commandline it does cpu+gpu
Results : 1252,36x; 462606149 bytes in 00:00:02.8448465 seconds;

This post has been edited by SigHunter: Oct 6 2013, 00:39
Go to the top of the page
+Quote Post
SigHunter
post Oct 6 2013, 01:58
Post #409





Group: Members
Posts: 42
Joined: 22-September 08
Member No.: 58544



QUOTE (SigHunter @ Oct 6 2013, 01:35) *
edit:
what makes it even more impressive is when you add --cpu-threads 4 to the commandline it does cpu+gpu
Results : 1252,36x; 462606149 bytes in 00:00:02.8448465 seconds;


can't edit my post, but i read this http://www.hydrogenaudio.org/forums/index....st&p=799962 and i know i described it wrong. it still gives better performance tho smile.gif
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Oct 6 2013, 18:34
Post #410





Group: Developer
Posts: 683
Joined: 2-October 08
From: Ottawa
Member No.: 59035



QUOTE (SigHunter @ Oct 5 2013, 19:35) *
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

If it is a sequential read, and near the start of the disk - this will be about the limit. Which makes speeds higher than 1000x available only with SSD or fast raids.


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
Mangix
post Dec 24 2013, 20:36
Post #411





Group: Members
Posts: 584
Joined: 26-February 06
Member No.: 28077



Zombie revive!

A new version of FLACCL was released to the Hg repository a while back: http://sourceforge.net/p/cuetoolsnet/code/....FLACCL/flac.cl

If you want to try it, just replace the flac.cl from CUETools 2.1.5 in the plugins folder.

That being said, this new version creates bigger files because of this change at line 799:
CODE
cbits = min(cbits, clz(order + 1) + 1 - shared.task.obits);
. It used to be just "order" instead of "order + 1" and as a result it creates bigger files. Changing it back fixes the issue and still creates non-broken FLAC files(I had issues with Error : unsupported residual coding and a few other errors that created FLAC files which did not decode properly).
Go to the top of the page
+Quote Post
Mangix
post Dec 27 2013, 01:37
Post #412





Group: Members
Posts: 584
Joined: 26-February 06
Member No.: 28077



Can't edit on this forum.

It seems that my previous assertion was incorrect. "order + 1" sometimes creates smaller files and other times just "other" does. It seems to be very content dependent. For example, the files which previously failed to verify usually become smaller with "order" whereas the files which were fine prior to the update tend to be smaller with "order + 1".

Needs more testing.

edit: Looks like the files which gave "Error : unsupported subframe coding (ch == 1)" are smaller with just order while the "Error : frame crc mismatch" files become smaller with order + 1.

This post has been edited by Mangix: Dec 27 2013, 02:01
Go to the top of the page
+Quote Post

17 Pages V  « < 15 16 17
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 24th April 2014 - 12:05