| 04:03 | dbsx | I have tried -march=armv7-a -mfpu=vfpv3-d16 -mtune=marvell-pj4 and |
| 04:03 | dbsx | -march=armv7-a -mfpu=vfpv3-d16 -mtune=iwmmxt (which compile my code) |
| 04:03 | dbsx | Is the 'armv7-a' the right arch for Cubox and any ideas on a best set of generic options? |
| 11:48 | dv__ | jnettlet: dbsx is here now, did you guys finally manage to share the iwmmxt string functions? :) |
| 11:49 | jnettlet | dv_, I am trying to get a hold of the copyright owners before releasing anything. |
| 11:50 | dbsx | quivering in anticipation |
| 11:50 | jnettlet | If you want to test I can provide a binary you can LD_PRELOAD and test against. |
| 11:50 | dbsx | i will wait for source, thanks anyway |
| 11:52 | dbsx | have either of you tried hardfp kernels or are you using softfp? |
| 11:55 | jnettlet | the kernel need to be softfp as when they it is loaded and run the floating point hardware usually isn't setup yet. |
| 11:59 | dbsx | Thanks, I always wondered about that. What about -marm rather than the default -mthumb? |
| 12:02 | jnettlet | that would mostly be about size. they both perform about the same but thumb binaries are significantly smaller. Having your kernel take up less space in memory is a good thing :-) |
| 12:04 | dbsx | I did some benchmarks on some of my apps and found -marm always faster (in the range of 9% to 15%). |
| 12:04 | jnettlet | dbsx, I was just looking at your gcc options above. If you are using gcc 4.8 (or a patched 4.7) you have to specifcy -mcpu=iwmmxt2 |
| 12:05 | dbsx | Ok, again elighten me. Whats the diff b/t/ iwmmxt2 and iwmmxt |
| 12:06 | jnettlet | different versions. iwmmxt is the original iwmmxt instruction set written by intel. iwmmxt2 is the next generation instruction set developed for early ARM processors. |
| 12:06 | jnettlet | just like mmx and mmx2 or sse and sse2 |
| 12:07 | dbsx | aha |
| 12:08 | jnettlet | you could be seeing a performance increase if the app has code that can directly be translated to an arm32 instruction that thumb doesn't have an equivalent to. So when built for ARM gcc can create a single arm instruction but for thumb it takes multiple instructions to do the same routine. |
| 12:11 | dbsx | On cubox the extra speed is significant, heavy size penalty though |
| 12:13 | jnettlet | are you seeing a lot of kernel cpu usage? |
| 12:13 | dbsx | no |
| 13:36 | _rmk_ | err, "softfp kernel" "hardfp kernel"? that's meaningless, the kernel doesn't care one bit because the kernel makes no use of any FP |
| 14:56 | rabeeh | _rmk_: in Dove LCD controller there is palette lookup table (insides an SRAM in the LCD controller). |
| 14:57 | rabeeh | the docs are not 100% clear; but they can map colors |
| 14:58 | rabeeh | for instance register 0x00820160 sets the offset of that table inside the sram |
| 14:58 | rabeeh | i think it can be used for the hdmi color mapping you previously mentioned |
| 15:03 | _rmk_ | rabeeh: I suspect merely reporting the correct VIF data will fix it |
| 15:04 | _rmk_ | I may at some point take the cubox over to the TV shop and try it out on many different TVs there. |
| 15:05 | _rmk_ | but that won't be this week because he's away on holiday |
| 15:06 | _rmk_ | it was fine playing overlayed full-screen video though |
| 20:18 | jnettlet | I have gotten an acknowledgement on the mem and str functions. The developer at Marvell that wrote them is checking on the license. |
| 20:19 | _rmk_ | goodo |
| 20:19 | jnettlet | a faster response than I expected actually. |
| 20:22 | dv_ | and dbsx missed it again :) |
| 23:03 | _rmk_ | jnettlet: I suspect you're lucky to get any answer which isn't a bounce message too |
| 23:04 | _rmk | 23:04 * _rmk_ crashes ubuntu 12.04.1 rhythmbox again |
| 23:04 | _rmk_ | ... and waits for apport to do its stuff |