[06:19]  * ethanbot2 waves to ethana2
[06:19] <persia> Somehow I doubt that worked the way it was intended.
[17:38] <lool> ogra: For the record, we wont expect NEON in karmic+, only ARMv6 and VFP v3; our toolchain doesn't output NEON by default anyway
[19:57] <Martyn> re
[20:58] <Martyn> lool : *nod*
[20:59] <Martyn> lool : I'm looking to see what it would take to compile karmic w/ full NEON and v7 optimizations
[20:59] <Martyn> akin to building the i686 port
[21:41] <lool> Martyn: why NEON?
[21:42] <lool> Martyn: karmic will likely move to v6 + vfp v3
[21:43] <lool> There are some advantages to v7 over v6, but not really in a way which we'd use
[21:45] <lool> Martyn: NEON isn't picked up by the fsf toolchain yet AFAIK, it might be by the codesourcery one; perhaps you want to rebuild some specific NEON using apps with NEON enabled?  But I don't see much value in using NEON righ tnow
[21:55] <Martyn> CodeSourcery supports it
[21:55] <Martyn> lool : Not for ubuntu "we" but for smooth-stone "we" I need as much optimized performance as I can get out of our new SoC
[21:56] <Martyn> And it's a quad-core v7 w/ a huge L2
[21:56] <Martyn> Similar to what you're going to see out of pegatron and company once the A9MP's start rolling out
[22:07] <lool> Martyn: ok, but what's going to use your NEON instructions?
[22:08] <lool> Do you plan using a custom toolchain which generates more NEON code?
[23:14] <Martyn> lool : Yep.
[23:15] <Martyn> lool : Or more specifically, the customers that will be making systems from this architecture will need it