=== ApOgEE is now known as Ap0g33 === Ap0g33 is now known as ApOgEE- [06:19] * ethanbot2 waves to ethana2 [06:19] Somehow I doubt that worked the way it was intended. === ScriptRipper_ is now known as ScriptRipper === bjf is now known as bjf_afk === cbrake_away is now known as cbrake === bjf_afk is now known as bjf === Omegamoon is now known as Omegamoon|cookin === Omegamoon|cookin is now known as Omegamoon|dinner [17:38] ogra: For the record, we wont expect NEON in karmic+, only ARMv6 and VFP v3; our toolchain doesn't output NEON by default anyway === Omegamoon|dinner is now known as Omegamoon [19:57] re [20:58] lool : *nod* [20:59] lool : I'm looking to see what it would take to compile karmic w/ full NEON and v7 optimizations [20:59] akin to building the i686 port [21:41] Martyn: why NEON? [21:42] Martyn: karmic will likely move to v6 + vfp v3 [21:43] There are some advantages to v7 over v6, but not really in a way which we'd use [21:45] 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] CodeSourcery supports it [21:55] 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] And it's a quad-core v7 w/ a huge L2 [21:56] Similar to what you're going to see out of pegatron and company once the A9MP's start rolling out [22:07] Martyn: ok, but what's going to use your NEON instructions? [22:08] Do you plan using a custom toolchain which generates more NEON code? === cbrake is now known as cbrake_away [23:14] lool : Yep. [23:15] lool : Or more specifically, the customers that will be making systems from this architecture will need it