| 00:13.02 | *** join/#arm-netbook revident (~scott@76-10-173-74.dsl.teksavvy.com) |
| 00:38.55 | *** join/#arm-netbook stefanro1 (~stefan@p57B94E78.dip0.t-ipconnect.de) |
| 01:01.11 | *** join/#arm-netbook tinti_ (~tinti@pdpc/supporter/student/tinti) |
| 01:14.17 | *** join/#arm-netbook torqu3e (~tesingh@c-71-202-178-46.hsd1.ca.comcast.net) |
| 03:11.32 | *** join/#arm-netbook KoH__ (~kane@trir-4d0ba708.pool.mediaWays.net) |
| 03:26.31 | *** join/#arm-netbook mSquare (~selvan@27.34.241.70) |
| 03:30.14 | *** join/#arm-netbook aholler_ (~aholler@p57B201C5.dip0.t-ipconnect.de) |
| 05:07.43 | *** join/#arm-netbook sv (~discopig@unaffiliated/discopig) |
| 05:12.37 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 05:21.51 | *** join/#arm-netbook christopher (~christoph@c-174-54-115-236.hsd1.pa.comcast.net) |
| 05:35.20 | *** join/#arm-netbook rellla (~rellla@p5B07837B.dip0.t-ipconnect.de) |
| 05:36.30 | *** join/#arm-netbook pcat (~cat@37-136-37-55.nat.bb.dnainternet.fi) |
| 05:49.33 | *** join/#arm-netbook abesis (~abesis@78.187.167.191) |
| 05:55.04 | *** part/#arm-netbook mSquare (~selvan@27.34.241.70) |
| 06:23.46 | *** join/#arm-netbook rellla2 (~rellla@p5B078191.dip0.t-ipconnect.de) |
| 06:48.43 | *** join/#arm-netbook focus (~Doug@host81-149-149-147.in-addr.btopenworld.com) |
| 06:57.47 | *** join/#arm-netbook sv (~discopig@modemcable140.167-130-66.mc.videotron.ca) |
| 06:57.47 | *** join/#arm-netbook sv (~discopig@unaffiliated/discopig) |
| 07:16.24 | *** join/#arm-netbook kaspter (~Instantbi@58.247.209.105) |
| 07:18.54 | *** join/#arm-netbook hg_5 (~chatzilla@unaffiliated/hg-5/x-8664886) |
| 07:28.54 | *** join/#arm-netbook focus (~Doug@host81-149-149-147.in-addr.btopenworld.com) |
| 07:44.49 | *** join/#arm-netbook popolon (~popolon@og-free.planet-service.fr) |
| 07:57.40 | *** join/#arm-netbook sspiff (c24e0469@gateway/web/freenode/ip.194.78.4.105) |
| 08:01.49 | *** join/#arm-netbook kaspter (~Instantbi@58.247.209.105) |
| 08:16.41 | *** join/#arm-netbook fossxplorer (~fossxplor@unaffiliated/fossxplorer) |
| 08:28.28 | *** join/#arm-netbook fra79Wii (~fra79Wii@cbs212.cbs.dtu.dk) |
| 09:49.55 | *** join/#arm-netbook tzafrir (~tzafrir@local.xorcom.com) |
| 10:46.07 | *** join/#arm-netbook anunnaki (~christoph@c-174-54-115-236.hsd1.pa.comcast.net) |
| 11:02.51 | *** join/#arm-netbook ganbold (~ganbold@173.244.215.173) |
| 11:20.32 | *** join/#arm-netbook Brandon15811 (~Brandon15@2a01:e0b:1:156:e914:b02d:c464:58d1) |
| 11:22.00 | *** join/#arm-netbook ganbold (~ganbold@173.244.215.173) |
| 12:30.32 | *** join/#arm-netbook datagutt (~datagutt@unaffiliated/datagutt) |
| 12:46.35 | *** join/#arm-netbook hg_5 (~chatzilla@unaffiliated/hg-5/x-8664886) |
| 12:48.56 | *** join/#arm-netbook ganbold_ (~Ganbold@173.244.215.173) |
| 12:49.48 | *** join/#arm-netbook kaspter (~Instantbi@58.247.209.105) |
| 12:55.27 | *** join/#arm-netbook kaspter (~Instantbi@58.247.209.105) |
| 13:46.41 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 14:08.34 | *** join/#arm-netbook hg_5 (~chatzilla@unaffiliated/hg-5/x-8664886) |
| 14:22.10 | *** join/#arm-netbook acfrazier (~acfrazier@ionnox.com) |
| 15:04.12 | *** join/#arm-netbook rz2k (~rz2k@93-80-138-112.broadband.corbina.ru) |
| 15:07.40 | *** join/#arm-netbook Undertasker (~meister@p5099d479.dip0.t-ipconnect.de) |
| 15:07.44 | *** join/#arm-netbook pcat (~cat@gprs-internet-bcee81-176.dhcp.inet.fi) |
| 15:41.18 | *** part/#arm-netbook fra79Wii (~fra79Wii@cbs212.cbs.dtu.dk) |
| 16:04.23 | *** join/#arm-netbook hg_5 (~chatzilla@unaffiliated/hg-5/x-8664886) |
| 16:29.55 | *** join/#arm-netbook abesis (~abesis@176.42.189.33) |
| 17:09.52 | *** join/#arm-netbook zumbi_ (zumbi@pasanda.collabora.co.uk) |
| 17:56.42 | *** join/#arm-netbook eFfeM1 (~frans@c73189.upc-c.chello.nl) |
| 18:09.24 | *** join/#arm-netbook KoH_ (~kane@trir-5d800414.pool.mediaWays.net) |
| 18:14.15 | *** join/#arm-netbook tinti (~tinti@pdpc/supporter/student/tinti) |
| 18:20.47 | *** join/#arm-netbook eFfeM (~frans@c73189.upc-c.chello.nl) |
| 19:07.57 | *** join/#arm-netbook tinti (~tinti@pdpc/supporter/student/tinti) |
| 19:19.52 | *** join/#arm-netbook KoH__ (~kane@trir-4d0ba330.pool.mediaWays.net) |
| 19:20.05 | *** join/#arm-netbook eebrah (~ibrah@212.49.88.111) |
| 19:49.56 | *** join/#arm-netbook MMlosh (~MMlosh@2001:470:6f:23:20f7:5312:9808:a503) |
| 20:46.32 | SPG | lkcl master aa15587 rhombus community_ideas/games_console.mdwn * http://git.hands.com/?p=rhombus.git;a=commitdiff;h=aa15587 |
| 20:57.57 | SPG | lkcl master 1f145dd rhombus community_ideas/games_console/ (5 files) * add console images * http://git.hands.com/?p=rhombus.git;a=commitdiff;h=1f145dd |
| 20:57.57 | SPG | lkcl master 38005bf rhombus * Merge branch 'master' of ssh://git.hands.com/rhombus * http://git.hands.com/?p=rhombus.git;a=commitdiff;h=38005bf |
| 20:57.57 | SPG | lkcl master 3bd1190 rhombus community_ideas/games_console.mdwn * corrections to console * http://git.hands.com/?p=rhombus.git;a=commitdiff;h=3bd1190 |
| 21:00.06 | SPG | lkcl master b294822 rhombus community_ideas/games_console.mdwn * corrections to console * http://git.hands.com/?p=rhombus.git;a=commitdiff;h=b294822 |
| 21:16.06 | *** join/#arm-netbook tzafrir (~tzafrir@bzq-218-155-147.cablep.bezeqint.net) |
| 21:16.54 | traeak | games console! |
| 21:17.38 | traeak | lkcl: i still want to see that 8 core mips proc with the open media instructions |
| 21:18.28 | traeak | iCube that is |
| 21:24.01 | lkcl | traeak: yeah. me too. gotta find around $USD 8m though, because 40nm ain't gonna cut it - have to go to 28nm in 2014 when SMIC is set up and ready |
| 21:24.14 | traeak | yeah ouch |
| 21:24.17 | traeak | currently on 65nm |
| 21:24.18 | lkcl | 40nm (with a $USD 5m budget) ain't gonna cut it |
| 21:24.28 | traeak | just looking at their us website |
| 21:24.44 | lkcl | yes - via the MVP "shared silicon" programme which is about $50k, very low yields, and done about every 3 months. |
| 21:25.02 | traeak | also i noticeits dual core, 4 threads per core |
| 21:25.04 | lkcl | all the fabs do that - it's a good way for people to test their ICs. |
| 21:25.19 | lkcl | that varies. they can do more, they can do less. |
| 21:25.27 | traeak | so basically this isn't going to happen from what it looks like |
| 21:25.28 | traeak | ? |
| 21:25.35 | lkcl | it'll fucking well happen all right. |
| 21:25.52 | traeak | if they want traction |
| 21:25.58 | traeak | i can't tell how they are doing opengles |
| 21:26.02 | traeak | looks like a separate block |
| 21:26.06 | traeak | so probably proprietary again? |
| 21:26.09 | lkcl | the moment i find $8m to spare i'm going to phone them up and say "here you go" |
| 21:26.22 | lkcl | ahh no - you've missed how f*****g smart these guys are, entirely :) |
| 21:26.24 | traeak | pocket change for you? |
| 21:26.30 | lkcl | traeak: not a chance :) |
| 21:26.38 | traeak | well i spent the last 10 mins looking at their page |
| 21:26.45 | traeak | so that tells you how educated i am :-p |
| 21:26.58 | lkcl | but if this project goes as well as i planned, then yes it'll be pocket change. but not right now :) |
| 21:27.06 | lkcl | ok, the way it works is: it's *pure* software. |
| 21:27.20 | lkcl | there *are* no proprietary hardware blocks. at all. absolutely none. |
| 21:27.38 | traeak | which is exactly what's required to catch a part of the market that is absolutely not being served right now |
| 21:27.43 | lkcl | so the parallelism comes from the threads, which are nominally absolute hell to program. |
| 21:27.46 | traeak | hopefully the market is big enough |
| 21:27.47 | lkcl | yes, exactly. |
| 21:27.56 | traeak | nah, i do multithreaded stuff for a living |
| 21:27.58 | lkcl | well that depends on price-power-performance |
| 21:28.07 | traeak | i just need lots of double precision throughput |
| 21:28.13 | lkcl | ok, but this is VLIW multi-threading. |
| 21:28.23 | lkcl | so it's a bit different. |
| 21:28.39 | lkcl | and that's why they use the open64 compiler ****NOT***** gcc. |
| 21:28.42 | traeak | ie: i code at a higher level, not at machiencode level |
| 21:28.48 | lkcl | i repeat: they DO NOT use gcc. |
| 21:28.56 | traeak | i don't care :-p |
| 21:29.01 | lkcl | open64 diverged from gcc by using its front-end **ONLY**. |
| 21:29.12 | traeak | our stuff works on 3 compilers, probably also open64 and intel |
| 21:29.32 | traeak | i hate msvc by the way, but it's a good check for compatibility |
| 21:29.44 | lkcl | so at the "high level", the open64 VLIW compiler simply takes *STRAIGHT* c-code |
| 21:30.02 | lkcl | and if it's parallelisable across multiple VLIW threads, it will parallelise it for you... automatically. |
| 21:30.09 | lkcl | that's it. |
| 21:30.10 | traeak | ahh |
| 21:30.12 | lkcl | done. |
| 21:30.16 | lkcl | end of story. |
| 21:30.29 | traeak | so it's sortof lowish level parallelization |
| 21:30.38 | traeak | whereas i've been rewlying on task level parallelization |
| 21:30.53 | lkcl | as a result, they LLLLIITTTERRRALLLY just take the standard mesagl - not the clunky opengles - libraries |
| 21:31.03 | lkcl | and do "CC=open64 ./configure". |
| 21:31.05 | lkcl | make |
| 21:31.07 | lkcl | make install |
| 21:31.14 | lkcl | and that's.... it. |
| 21:31.50 | lkcl | they have an automatically-parallelised version of mesagl, capable of performing at the level of the big boys. |
| 21:32.09 | traeak | good |
| 21:32.15 | traeak | for applcation level stuff then it should be good things |
| 21:32.17 | lkcl | they have a guy with over 20 years of compiler experience, working for SGI, prior to being on-board with icube. |
| 21:32.19 | lkcl | yes! |
| 21:32.26 | traeak | i'm just currently pissed at intel for high performance |
| 21:32.35 | traeak | no competition anymore they just raise their prices on their "old shit" |
| 21:32.56 | lkcl | now, here's the thing though: one single CPU, even with multiple hardware threads, is *still* not really fast enough to do H264 decode |
| 21:32.59 | traeak | ie: a 3930k processor costs more now than when it was released |
| 21:33.05 | lkcl | arse!! |
| 21:33.09 | traeak | hmm? |
| 21:33.14 | lkcl | well, they're going to get a bit of a shock in this market |
| 21:33.23 | traeak | intel or icube? |
| 21:33.41 | lkcl | why their processor is not fast at doing H264 decode is because the CABAC decode of H264 is inherently non-parallelisable |
| 21:34.10 | lkcl | so you have to decode multiple frames, add in a multi-frame buffer, allocate one per core (4 cores say) |
| 21:34.11 | traeak | hmm |
| 21:34.38 | traeak | what's their power envelope? |
| 21:34.39 | lkcl | then have the remaining 4 do the parallelisable bits such as the YUV-to-RGB and the DCT bits, that's all fine |
| 21:34.56 | lkcl | about the same as any other GPU |
| 21:35.05 | lkcl | not the embedded ones, the desktop ones. |
| 21:35.11 | traeak | so the gpu runs on the cores |
| 21:35.13 | lkcl | for performance/watt that is |
| 21:35.19 | lkcl | no, the gpu *is* the core. |
| 21:35.24 | lkcl | the core *is* the gpu. |
| 21:35.28 | traeak | okay |
| 21:35.30 | lkcl | there *are* no separate cores. |
| 21:35.48 | traeak | so the fun is how well it runs under various loads |
| 21:36.03 | lkcl | there are only instruction set extensions that happen to run on separate hardware blocks, but there are no separate cores. |
| 21:36.15 | traeak | sure |
| 21:36.19 | lkcl | and the more "threads" in the GPU-style instructions, the faster those go |
| 21:36.32 | lkcl | and the more "threads" in the video-decode-style instructions, the faster _those_ go. |
| 21:36.43 | traeak | hmmm |
| 21:36.55 | lkcl | but those instructions are issued by the *main CPU* to those pipelined thread engines |
| 21:37.02 | lkcl | there *is* no separate "GPU". |
| 21:37.04 | traeak | so its geared mostly towards float32 type? or how is the float64 performance? |
| 21:37.10 | lkcl | they call it "Unified Processing Unit" |
| 21:37.23 | lkcl | i think it's mainly geared towards 32-bit |
| 21:37.37 | lkcl | but there are 64-bit floating point instructions as well - they just take longer |
| 21:37.41 | traeak | makes sense if they want to compete at themobile level |
| 21:37.51 | lkcl | and keep the power down, yes. |
| 21:38.00 | traeak | i honestly don't know what aarm64 is going to look like |
| 21:38.23 | lkcl | it turns out that in many cases, only 12-bit accuracy in the last stages of floating-point 3D operations is perfectly good enough! |
| 21:38.35 | lkcl | yeah arm are swamped :) |
| 21:38.45 | traeak | for consumer stuff sure |
| 21:39.10 | traeak | hopefully you could play with raytracing stuff on this |
| 21:39.21 | traeak | but the other question is how much bandwidht is available meomry wise |
| 21:39.22 | lkcl | no they're swamped right now with Soc vendors for aarm64 :) |
| 21:39.27 | lkcl | on the ic2? |
| 21:39.30 | traeak | yeah |
| 21:39.46 | lkcl | yeah we spec'd that as 64-bit wide, up to 1333mhz. approx. |
| 21:40.06 | lkcl | maybe by 2014 it'll be possible to go for LPDDR3 or maybe LPDDR4 - whatever. |
| 21:40.23 | lkcl | but, the NREs on licensing those hard macros gets insanely expensive. |
| 21:40.48 | lkcl | i can't quite recall but i think it was either $500,000 or $600,000 for the DDR3 interface hard macros |
| 21:41.03 | lkcl | USB3 was $300,000. etc. etc. |
| 21:41.54 | lkcl | it's why we needed $5m for a 40nm chip. about $1m was for the production masks. about $2.5m for hard macro licensing. |
| 21:42.06 | traeak | yeah ouch |
| 21:42.09 | lkcl | 28nm will be another jump on that. |
| 21:42.55 | traeak | caches seem a bit low, but again this is competing with arm stuff i gather |
| 21:43.02 | lkcl | but, you see, if it works, you sell $400m worth of chips in about 6 months. |
| 21:43.14 | lkcl | so it's a high risk that can pay off *big*. |
| 21:43.47 | lkcl | all you need is someone who doesn't mind blowing $5m (or $9m for 28nm) |
| 21:44.18 | eebrah | lkcl, traeak: what are we talking about? who's iCube? |
| 21:44.25 | lkcl | and as it's only money, if i had $9m i'd definitely put it down - cash up front - to make $100m+ and satisfy free software requirements as well |
| 21:44.32 | lkcl | http://icubecorp.com |
| 21:44.38 | eebrah | thanks |
| 21:44.55 | traeak | is there still room in the market? |
| 21:44.58 | traeak | for this stuff i mean |
| 21:45.54 | lkcl | traeak: if you get it right, then yes. and have the sales channels, yes. |
| 21:46.22 | lkcl | if it compiles android including 3D graphics and pisses over the competition on price, then what do they care what the CPU is, underneath? |
| 21:46.50 | traeak | yup, that's what i was wondering |
| 21:46.59 | traeak | number of transistors, cost per unit, profit, etc |
| 21:47.13 | traeak | and if we aren't stuck on just android |
| 21:47.18 | traeak | that will make lots of people very happy |
| 21:47.24 | traeak | although the "big companies" don't give a rat's ass |
| 21:47.58 | lkcl | traeak: it's a general-purpose processor with instruction extensions that happen to be parallel and happen to be suitable for 3D and video decode. |
| 21:48.12 | lkcl | so you can do what you like! |
| 21:48.40 | traeak | you won't have a problem selling to me if it's capable of being a light desktop etc |
| 21:48.59 | eebrah | interesting stuff |
| 21:49.12 | lkcl | and the advantage for the people shipping it, they are no longer critically dependent on a complex proprietary GPU which is hell to integrate into the build. |
| 21:49.18 | lkcl | and goes wrong. |
| 21:49.18 | traeak | uh yeah |
| 21:49.30 | traeak | the GPU shit is exactly what can kill off arm socs |
| 21:49.37 | lkcl | and requires insane support calls and costs to get it fixed. |
| 21:49.43 | lkcl | yeah tell me about it. |
| 21:50.01 | traeak | i would really like to see imageon and nvidia bite the dust hard |
| 21:50.35 | lkcl | well... yeah.. imgtec that wouldn't surprise me, people are getting fed up with their overcomplex architecture |
| 21:50.41 | traeak | so us nerds tend to be excited by this, just as long as we can use it :-p |
| 21:50.46 | lkcl | nvidia ... ha ha |
| 21:50.53 | traeak | or the fun that is vidcore (hehe) |
| 21:51.02 | lkcl | nvidia are well ahead of the game, and so have the funds to *stay* ahead. |
| 21:51.29 | traeak | if you dont' care about being 100% tied to android |
| 21:51.43 | lkcl | because they're owned by toshiba. first ever with a commercially successful ARM Cortex A9 for example |
| 21:52.04 | *** join/#arm-netbook manuel254 (~yaaic@212.49.88.103) |
| 21:52.05 | lkcl | NEC's Emma was only 600mhz and didn't really count. |
| 21:52.19 | lkcl | yeah. i don't care about android, you might have guessed :) |
| 21:52.22 | lkcl | ls -altr |
| 21:52.24 | lkcl | fail |
| 21:52.34 | lkcl | find . -name "*.txt" |
| 21:52.35 | lkcl | fail |
| 21:52.41 | lkcl | grep |
| 21:52.42 | lkcl | fail |
| 21:52.45 | lkcl | du |
| 21:52.46 | lkcl | fail |
| 21:52.49 | lkcl | wtf |
| 21:52.50 | lkcl | fail |
| 21:52.55 | lkcl | deeply unimpressive :) |
| 21:54.35 | lkcl | ok. enough |
| 21:54.37 | lkcl | night all |
| 22:01.19 | traeak | have fun and thanks for the update |
| 22:01.44 | traeak | if this chip could serve nicely as a lightwieght desktop with some reliable media capabilities i'd be happy |
| 22:01.54 | traeak | i'll still be stuck with intel chips for serious development |
| 22:17.03 | *** join/#arm-netbook KoH_ (~kane@trir-4d0bacb9.pool.mediaWays.net) |
| 22:47.22 | *** join/#arm-netbook anunnaki (~christoph@c-174-54-115-236.hsd1.pa.comcast.net) |
| 22:49.17 | *** part/#arm-netbook Undertasker (~meister@p5099d479.dip0.t-ipconnect.de) |
| 23:08.01 | *** join/#arm-netbook projectgus (~gus@spork.chainxor.org) |
| 23:11.56 | *** join/#arm-netbook gsilvis (~almostsix@50.12.163.241) |
| 23:41.07 | *** join/#arm-netbook RITRedbeard_ (~redbeard@c-68-37-165-37.hsd1.nj.comcast.net) |