Re:Daala: Are We Compressed Yet?
by petermonsson on Saturday December 13, 2014 @05:30PM
(#8746708)
Cool stuff. Thanks a bunch. I agree with you that software optimization takes preference, but I have also seen optimized crypto code in assembly that was completely undocumented and unreadable. I hope that Daala won't fall into that trap.
All functions in Daala have a C version, along with corresponding assembly versions which have tests to make sure that the assembly version matches the C reference.
Re:Daala: Are We Compressed Yet?
by yazaddaruvala on Monday December 15, 2014 @02:18AM
(#8750987)
Given this is funded by Mozilla, I'm surprised its not written in Rust. Any particular reasons?
Re:Daala: Are We Compressed Yet?
by higherpurpose on Saturday December 13, 2014 @05:54PM
(#8746780)
ARM and its partners will probably start supporting HSA in 2016 and beyond, so you might want to look at that, too.
The transforms no longer take as much CPU time as they used to, due to having better SIMD accelerated versions. Much of the time is now spent on the PVQ decoder, which is not optimized for speed at the moment.
One thing I learned after writing large fixed-function transform hardware is that it doesn't take much extra hardware to turn them into microcoded programmable pipelines, much like a GPU. In fact, this approach is very common internal to hardware video decoders, though the firmware is not exposed to the user. One notable exception is Broadcom's Videocore IV, which is quite an interesting architecture [2].
Also, with the latest mobile processors having 8 or more ARM cores, we can also exploit CPU parallelism in much the same way. I feel it is very important to have the codec perform well on CPU alone, as not everyone will have hardware that can decode it right away. This is something I would like to play with a lot more.
[1] http://thomasdaede.com/wordpress/?cat=9 [2] http://www.broadcom.com/docs/support/videocore/VideoCoreIV-A...