#qi-hardware IRC log for Thursday, 2011-05-19

qi-bot[commit] Werner Almesberger: tools/atrf-xtal/: new option -b for relative result; -p for pass/fail http://qi-hw.com/p/ben-wpan/ff6c83402:05
qi-bot[commit] Werner Almesberger: prod/doc/analysis.html: added precision clock measurement for atben http://qi-hw.com/p/ben-wpan/d2fda3702:05
qi-bot[commit] Werner Almesberger: prod/Makefile (ben): used simplified setup with only one atben and one atusb http://qi-hw.com/p/ben-wpan/6446a6e02:05
qi-bot[commit] Werner Almesberger: prod/doc/setup.html: corrected mangled sentence http://qi-hw.com/p/ben-wpan/dc40ff602:05
qi-bot[commit] Neil Stockbridge: libsdl-doc-man has been renamed to libsdl-dev and now includes header files http://qi-hw.com/p/openwrt-packages/1460a7902:21
xiangfuHi unclouded 02:24
uncloudedhi02:24
xiangfuwhich version you using in your nanonote now?02:24
uncloudedrootfs is the latest02:24
uncloudedkernel is still from December02:24
xiangfucan you give me the output of 'wget --version', 02:25
uncloudedthat's when I run from MMC, which I do most of the time02:25
uncloudedNAND has latest kernel and rootfs and works fine02:25
uncloudedwget: unrecognized option `--version'02:25
uncloudedlooks like busybox is handling wget02:25
xiangfuthanks. can you make sure it. ? 02:26
uncloudedalthough I have built my own busybox so the busybox package might have been mangled to include wget whether the release version does or not02:26
uncloudedsure.  my NAND is pristine, so I'll boot that and do the test there instead02:27
xiangfuthanks.02:27
uncloudeddifferent result.  I must have elected for busybox to include wget when I rebuilt it02:30
uncloudedNAND says GNU Wget 1.1202:31
xiangfuunclouded: ok. what about ` wget --version | grep iri`02:32
uncloudedsimply says "-iri"02:32
uncloudednothing else02:32
xiangfuok.02:32
uncloudedwould you like me to do any other tests on the NAND or can I boot back to MMC?02:33
xiangfumaybe the libidn is build after 'wget' build. that is why 'wget' not detect the libidn, but recently the packages build order changed, 02:34
xiangfuunclouded: thanks. just back to MMC, '-iri' is enough :)02:34
uncloudedhey xiangfu, can I get a folder at http://downloads.qi-hardware.com/people/ so I can make available some man-tiny .ipk files for testing?02:36
xiangfusure. 02:37
xiangfudo you have account on downloads.qi-hardware.com?02:37
xiangfureal user in server?02:37
uncloudeddon't think so.  I have two Qi accounts: wiki and projects.  it's not either of those is it?02:38
xiangfuunclouded: ok. just send your ssh public key to me. I will setup account in downloads.qi-hardware.com02:41
uncloudedthe key is on its way to you now02:43
xiangfuunclouded: just ssh to downloads.qi-hardware. I setup a symlink in your home folder name 'people.unclouded' point to downloads.qi-hardware.com/people/unclouded/02:58
xiangfuwolfspraul: I found the folder under people/ is all www-data.www-data, only my folder is xiangfu.xiangfu, I always using 'scp' to copy files to downloads.qi-hardware.com, should I also using 'www-data'?02:59
wolfsprauldon't know, I doubt there is much difference03:07
xiangfuunclouded: some feedback, if install both busybox man and your man-tiny, by default it's busybox, since the /sbin/ at a front of /usr/bin,  03:11
xiangfuunclouded: there are some example : http://dpaste.com/544114/ just FYI.03:12
uncloudedthat's pretty cool.  so packages can patch themselves over the busybox versions and then restore the busybox version if the extended package is removed?03:13
xiangfuunclouded: another thing, you may also want re-package 'manpages-dev_3.27-1_all.deb' to openwrt package.03:16
xiangfu:)03:17
uncloudedthat would make it easier for people to get the dev man pages on to the NanoNote for sure.  will add to list03:17
uncloudedI couldn't find an upstream tarball for manpages-dev.  I think the collection actually originates at Debian03:18
xiangfuunclouded: ok. 03:18
xiangfuthen we can just download the deb package. and then write 'define Package/manpagers-dev/postinst  opkg isntall manpages.deb'03:19
kyakit would be nice to have some openwrt hack to be able to generate these *-dev packages automagically04:55
kyakjust having a look at libsdl-dev by Neil.. everything is already there in build root, it's just a matter of copying of headers/libs/man pages04:56
kyakxMff: do you think it is possible to do somehow?04:57
xiangfukyak: include $(INCLUDE_DIR)/man.mk ?05:00
xiangfuthen add  CONFIG_MANPAGE ?05:00
xiangfumaybe no man.mk, just CONFIG_MANPAGE.05:01
kyakxiangfu: yes, maybe some global flag whether to include manpages/dev libs or not.. But i was thinking about separate packages for that05:02
xiangfukyak: you mean every package like:  wget, wget-dev?05:03
kyakmaybe, if this flag is set, then build system will generate according separate pacakges..05:03
kyakyeah: wget, wget-dev, wget-manpages05:03
kyaki think it's done in lime like that05:04
kyakand all localization files are also splitted05:04
kyaklike wget-locales-ru 05:05
xiangfunot sure if OpenWrt users will like wget-dev, wget-manpages.05:05
kyakopenwrt users won't need it, for sure05:05
kyakso they won't set the flag :)05:05
xiangfukyak: another idea is , after all package compiled,  search all manpages in build_dir/... then create a package for all package man page :)05:06
kyakthat would be a lot of information i think..05:06
kyakand i'm not even sure opkg running on Ben is capable of isntalling it05:07
kyakit will run out of memory, and then diskspace :)05:08
kyakanother option is just to create there -dev and -man packages by hand, when necessary05:09
kyakjust like Neil did05:09
kyaksomeone need to develop ncurses app on Ben? let's package ncurses-dev05:10
xiangfumy system is 40M /usr/share/man05:10
kyakmine is 63M :)05:10
xiangfukyak: then the package-dev.mk is better.05:10
wolfspraulone day we need to do the 'next big repartitioning'05:16
kyakxiangfu: so this package-dev.mk will be a helper to package -dev and -man packages?05:16
kyakand magic will happen there?05:17
xiangfuwolfspraul: yes. we should thinking about it when we start switch to trunk I guess.05:17
xiangfukyak: (package-dev.mk) I guess so.05:18
xiangfukyak: something like rewrite 'Build/Compile/Default' , just an idea. 05:19
xiangfukyak: for example the cmake.mk. 05:19
xiangfukyak: hmm... maybe not. then we need change so many packages. that is not good05:20
uncloudedwill the size of the man pages matter much?  only those who wish to write C on the NanoNote would install a lot of -dev packages05:56
uncloudedI was thinking the -dev packages could include the man pages ( no need for a seperate -man package) although that would waste disc space for a C developer who wants to read all their documentation in HTML05:57
uncloudedbut how likely is that?  and just how much space would the man pages consume?05:57
kyakhm06:12
kyakthe total size of all manpages under build_dir is 6293699 bytes06:13
kyakbut it might be due to the fact that most packages are not confgiured to generate manpages06:13
kyaki also wonder if i calculate correctly: find ~/openwrt-xburst.full_system/build_dir -name "*.man" -printf %s+ | sed 's/+$/\n/g' | bc -l06:14
kyakyeah, the assumption that manpages are named as "*.man" is not correct :)06:16
kyak-regex ".*\.man\|.*\.[1-9]" seems better06:20
kyakbut then, it accounts for uncompressed man pages06:20
kyakhe-he, and also some libs :)06:20
uncloudedI would have expected man pages to compress well but the SDL ones only went from about 720K to 680K or something.  not much compression06:43
xMffkyak: yes, I think so08:06
xMffkyak: with a bit of work08:06
kyakxMff: what is your idea?08:19
xMffhijack Build/InstallDev somehow08:19
kyakhm.. so not even necessary to create additional makefiles in include/ and modify package Makefiles08:21
xMffyeah08:21
xMffsince InstallDev typically installs what a -dev package would contain08:21
kyakexactly..08:21
xMffand its always relative08:22
xMfftarget path is passed as $(1)08:22
xMffnot coded in the define08:22
xMffbut its just a crazy idea for now08:22
xMffone has to dig through rules.mk, include/package*.mk and package/Makefile08:23
xMffto implement it08:23
xMffor to find out howto create corresponding -dev packages "out if thin air"08:23
kyakso it's not so simple after all..08:25
xMffwell, its advanced makefile changes08:25
xMffbut they  have to be done once only08:25
xMffnot for each package08:25
xMffok08:26
xMffthe BuildPackage macro should be expanded08:27
xMffproblem is when multiple binary packages share one source bundle08:27
xMffhow do you name the -dev package?08:27
kyakbinaries are usually separated from libraries?08:29
kyaklike, curl and libcurl and libcurl-dev08:29
kyakbut all build from the same tarball08:30
xMffright08:33
xMffand progrqammatically you can't decide whether it should be curl-dev or libcurl-dev without additional hints08:34
xMffyou could only take the source package name and append -dev08:34
xMffwhich would be "curl-dev" in this case08:34
xMffor "glib2-dev" for libglib208:34
kyakso you are saying that we can only peek at PKG_NAME08:36
xMffyes, more or less08:36
kyakmaybe just prepend "lib" to the name08:37
xMffbecause source:ipk relation is 1:n08:37
kyakthat would be a more or less correct guess08:37
xMffnot sure08:37
xMfffor example libsocks08:38
kyakhaving it as $(PKG_NAME)-dev is not so bad after all08:38
xMffthe source is called dante08:38
xMffthe dev package would be libdante-dev08:38
kyakthough confusing :)08:38
xMffwhich makes no sense08:38
kyakmaybe an argument to InstallDev to override that?08:39
xMffI fear nobody is going to maintain that08:39
kyakthere won't be a lot of packages with confusing names08:40
xMffthe extra argument I mean08:40
xMffwe can consider it08:40
xMffsomething like  PKG_DEV_NAME08:40
xMffwith fallback to $(PKG_NAME)-dev08:40
kyakthen if someone decides that he is not happy with libdante-dev, he would add that PKG_DEV_NAME into makefile..08:41
xMffhowever I would not add the lib by default08:41
xMffthat would be liblibtorrent-dev then :P08:41
kyakyeah..08:41
kyakexactly what i was going to say :)08:41
kyakthough it can be considered08:42
xMffthats details after the actual implementation is there08:42
kyakare you interested in implementing this for openwrt? I fear i'm not capable, deep knowledge of openwrt internals is required08:43
xMffI'll take a stab at it08:43
kyaknice! :) call me anytime you need a hand at testing. .that's the best i can do08:45
xMffinteresting08:49
xMffapparently one can overlay package makefiles08:49
xMff$(eval -include $(wildcard $(TOPDIR)/overlay/*/$(PKG_NAME).mk))08:49
xMffjust a side-note08:49
xMfffound it while checking the makefiles08:50
wpwrakJay7: btw, where was the home page of your kexec-based boot loader again ?09:22
kyakxMff: what does "overlaying makefiles" mean?09:35
xMffapparently you can override certain sections of existing makefiles with overlay makefiles09:35
xMffto e.g. redefien the description without patching it09:35
xMffit was new to me so I was excited09:36
kyaki see.. are you looking into exploiting this somehow?09:38
xMffno not really, I will somehow generate a -dev package definition from within the BuildPackage macro09:39
xMffone funny thing is that it will produce a lot of new entries in menuconfig09:41
kyakoh yea.. maybe make all of those dependant on CONFIG_PKG_DEV09:41
kyakso it won't appear for someone who is not interested to see it :)09:42
xMffyes, that for granted09:43
xMffbut it will still look like09:43
xMfflibfoo09:43
xMfflibfoo-dev09:43
xMfflibbar09:43
xMfflibbar-dev09:43
xMff...09:43
xMffin menuconfig09:43
kyakdo you think it's bad?09:43
xMffit looks unclean09:44
kyakmayeb these could be hidden09:44
xMffbut maybe it can be relocated into a new category "Development Headers"09:44
kyakbut still built if CONFIG_PKG_DEV is set09:44
xMffwith all -dev packages lumped together09:44
xMffthen its out of sight09:44
kyakseparate category also sounds nice09:45
xMffI have to relocate to the workplace, will hack on it from there. bbl09:48
kyakjow_laptop comes into play :)09:55
whitequarkJay7: no problem, in russian: http://lanc.bcmg.ru/wiki/index.php/IP_HDTV_%22LANC003%22_-_open_software_camera_project14:26
wpwrakDocScrutinizer: hmm, should shorting an antenna to ground be safe or could this damage amplifier/balun ? considering that all the power that goes into the antenna should also leave this way, i would expect that it's safe. but i'm not sure if i can trust this theory ;-)15:17
ron_wpwrak have you heard any progress/status re: SMT run for the ATben and ATusb?15:22
wpwrakrjeffries: only that tuxbrain said last week that he'd make sure he'll set a day aside for going through the testing process this week.15:23
Jay7wpwrak: kexecboot.org15:26
Jay7whitequark: nice project :)15:27
wpwrakJay7: ah, kinda obvious, in retrospect ;-) thanks !15:28
Jay7wpwrak: np :) what is context behind that question? ;)15:28
wpwrakJay7: ah, there's a discussion of boot loaders on heise.de, and i wanted to mention one active project using a kexec-based boot loader15:34
DocScrutinizerwpwrak: depending on amp/tx, band, antenna, point of shortening it, you can create a SWR that's so abysmal that it blows your TX power amp. Not on <500mW TX pwr of course15:34
Jay7wpwrak: seems we (kexecboot) are last active project :)15:34
Jay7qi-bootmenu is stalled15:34
wpwrakDocScrutinizer: i have 2 mW ;-) safe enough then ?15:34
Jay7all other was stalled even early15:34
DocScrutinizerprobably15:34
wpwrakJay7: we should call them "mature" ;-)15:35
Jay7wpwrak: hehe ;)15:35
xiangfuhttp://kexecboot.org/screenshots nice 15:39
Jay7yeah.. I should update screenshots15:53
Jay7font and icons was changed15:53
qi-bot[commit] Werner Almesberger: prod/doc/analysis.html: more material on checking the supply voltages http://qi-hw.com/p/ben-wpan/47b710d17:31
qi-bot[commit] Werner Almesberger: atusb: varistor Vdc was off by 100 mV; made it clearer that we use Vdc, not Vb http://qi-hw.com/p/ben-wpan/926ed2617:31
methril_workwpwrak, i'm almost going to FISL, do you have a MMOne?18:04
wpwrakmethril_work: no, just a bunch of bens (and an avt2)18:06
methril_workok18:06
methril_worki've my ben, and a MMOne18:06
wpwrakmethril_work: rejon said he'll bring an mm1 to fisl18:07
methril_workrejon is going to FISL!! this is new to me :)18:07
wpwraki need to clean up ubb-vga a little. would be nice to do the presentation with my ben ;-)18:07
methril_workhow many ubb's do you have?18:08
rejonyeah, i'll be there18:09
methril_worki would like to buy 1 or two :)18:09
rejoni'm catching up today18:09
rejonexcellent!18:09
wpwrakmethril_work: yeah, i could part with one or two :)18:11
methril_workwe'll try to pass brz taxes ;)18:12
wpwrakthey still have RA taxes on them. but they're only about half of yours :)18:32
rohwpwrak: seen this? http://www.nxp.com/campaigns/greenchip/pages/smartlighting.php18:32
wpwrakroh: using ieee 802.15.4 for domotics. nice :)18:36
wpwrakroh: the next step should be to combine energy harvesting with all this ;-)18:36
rohnot that neccessary18:36
rohmost energy is eaten by displays not wifi or other radios18:37
wpwrakroh: hey, smart lighting that doesn't need a power supply ? don't you think that would sell like crazy ? ;-)18:37
lunavorax_miniI came up to the conclusion that the Raspberry Pi was a total faillure from start.19:56
wpwrak;-))19:57
lunavorax_miniPoor kids need a ZX-Spec desing-like computer, small keyboard (with normal keys, not rubber ;) ) and composite out for video and SD card slot for storage (plus some USB in for devices) and that's IT. No wireless crap, no extra stuff, only maybe a mono speaker or audio in + audio out.19:57
wpwraklunavorax_mini: lekernel will be happy to read this :)19:57
lunavorax_miniimho, I'm not a computer specialist/designer19:58
lunavorax_miniHaha19:58
Jay7yes! let's reinvent ZX :)19:58
mstevenslunavorax_mini: have you seen http://sites.google.com/site/libby8dev/fignition ?19:58
Action: Jay7 like that idea :)19:58
lunavorax_minimstevens, the first line makes me liking the idea :)19:59
wpwrakeasy. i'm quite sure you could generate composite video with a ben. instant zx2011, and it's even mobile ;-)19:59
lunavorax_mini:)19:59
lunavorax_miniAnd letting kids playing with Python, no need to discourage them with C/C++.19:59
lunavorax_mini[troll] I think C# is better for kids as a first programming language [/troll]20:00
lunavorax_mini(no, I'm actually not thinking this)20:00
lunavorax_minimstevens, that's really insteresting !20:01
wpwrakmipsel-linux-gas will do nicely20:01
lunavorax_minigas ?20:01
wpwrakassembler20:03
lunavorax_miniOh ok20:03
lunavorax_miniI think some kids should start with Python or other high level language first20:04
lunavorax_miniI don't know much about Lua or Ruby.20:04
wpwrakbah. i started with the ti-57. 50 program steps. 10 variables. no persistent storage. all those friendly languages will just spoil them :)20:07
lunavorax_miniYeah I don't know20:07
lunavorax_miniI feel stupid when I heard someone saying "I was programming in ASM at 13yrs old"20:07
lunavorax_miniAnd I still can't make a functionnal (and interesting) C program.20:08
mthI was programming in asm at 11 years old ;)  although I wasn't very good back then20:14
mthI think I was about 15 before I actually could do useful things in asm20:17
wpwrakbah, at 11, i was designing my own computer :) (not that it would have worked ... i hadn't quite grasped the concept behind the R in "RAM" back then)20:18
lunavorax_miniOh come on guys, now how should I feel ? :(20:18
wpwrakmth: four years of nothing but frustrating failure ? that's a rough childhood20:19
mthwpwrak: no, I went back to using BASIC in the mean time20:19
mththe main problem was that I had an asm book that wasn't written for beginners20:20
mthback then I wanted to learn asm because BASIC was really slow (interpreted on Z80)20:21
mthI don't know how it is for today's young20:21
lunavorax_miniWell I think I can answer20:21
lunavorax_miniAnd that's why I was defending the use of Python as it is simple to understand for a beginner and not that slow for simple things.20:22
lunavorax_mini(still I am planning to learn asm this summer)20:23
mthI do know that people from the Informatics Olympiad were trying to teach me a LISP-like Logo dialect with little success20:23
mthalthough that was more because of the weird structure editor rather than because of the language itself20:23
lunavorax_miniHaven't you forgot a ) ? ;)20:24
mthah no, it was derived from Scheme, not LISP20:24
mthwell, it is LISP-like20:25
Jay7I was programming ASM about 15 years old20:26
Jay7because I had zx spectrum :)20:26
Jay7like mth :)20:27
mthI guess the structure editor was designed to avoid parenthesis problems, but I couldn't get over the fact that the cursor would move through the program tree rather than just going up/down/left/right one position20:27
mthJay7: actually MSX for me, but pretty similar hardware20:27
mthmy first attempt at learning C also failed, I tried learning it from a book during a holiday (no laptop in that time, so holiday meant a few weeks without a computer)20:31
mthI think I don't learn from books very well, I have to be able to try things out20:31
mthlunavorax_mini: MIPS asm would be a good candidate then, it's much more elegant than x8620:33
wpwrakmth: naw, VAX assembler would be so much better. nothing illustrates better where the complexity in CISC lies than a little MOVC5 or a POLYH ;-)20:41
lunavorax_minimth, actually, I'm aiming at learning x86 asm. I need it in order to understand disassembly of some x86 software I want to try to reverse-engineer20:54
lunavorax_miniIn the other hand, I have 3 of the 4 only existing books about Z80 asm :)20:55
lunavorax_miniI'm also aiming to learn it at some point, I have a lot of Z80 devices here (gameboy, ti-83, VG5000, ZX-Spec)20:56
lunavorax_minionly existing French* books20:56
mthif you've never done asm before, Z80 might be a good way to learn20:57
mthit's CISC, but not as complex as x8620:57
graphitemasterthe cool part about asm is you only need to know the basic fundementals of it, then you can plug in any type of instruction assuming the hardware supports it and it'll work20:57
graphitemastermost instruction sets are highly documents and can be found with a small google search.20:58
graphitemaster*documented20:58
lunavorax_minimth, CISC ?21:02
mthcomplex instruction set computing21:03
mthas opposed to RISC21:03
mthin RISC instructions do very little work and are highly orthogonal21:03
lunavorax_minigraphitemaster, yeah I heard someone saying to me "I only know the instruction set and I can do whatever I want". Also a University teacher told me "I don't know any language that is simpler than asm"21:04
mthwhile in CISC instructions do more work and are specialized21:04
mthfor example, on Z80 there is the DJNZ instruction, which does "decrement B, jump if non-zero" in one instruction21:04
graphitemasterRISC instructions are no good for anything but battery life and embedded platforms, with exception to ARMv6 which I think is the only sane RISC route these days.21:04
lunavorax_miniBattery life ? That means ultra precise programming then, no ?21:05
mthgraphitemaster: RISC might be easier for compilers to generate code for as well21:06
mthsince the registers are interchangeable21:06
graphitemasterwell I would never reccomend a CISC set for an embedded platform because it's just too complex and pointless in that type of situation21:06
mthwhen writing Z80 asm, good register allocation is probably the most important factor for performance21:06
graphitemasterwell I think the worst is RISC does a fine job at splitstreaming instructions to a fair common selection, but does a horrible job at doing a select task in the fewest instructions possible21:08
mthmost C compilers that target Z80 will pass arguments via the stack rather than registers, making the generated code a lot slower than hand-written asm21:08
graphitemasterwith exception to ARMv621:08
mthmaybe not the actual stack via SP, but some kind of program-managed stack using IX or IY21:09
graphitemasterI think my biggest issue is most of the older RISC chips has no microcode so they where forced down the pipeline into logical control singnals for the datapaths _directly_ from each instruction bit.  Now take a rather obstruisve program that requires a lot of decodes and the branches will slow down and take FOREVER to resolve and you ruin performance not for the whole program but everything21:12
graphitemasterI think ARM was the chip that actually broke away from this method which is primarly the reason I like ARM chips these days.21:13
mthI haven't written any ARM asm yet21:14
mthlast thing I did in asm was MMX and SSE versions of video scaling algorithms21:14
graphitemasterMMX is pretty useless21:14
graphitemasterit's deprecated in all newer generation AMD chips21:14
mththis was over 5 years ago though :)21:15
graphitemasterwell that acounts for something then :)21:15
graphitemasterI have worked on ARM code before, I find it a delight to work with it's well documented too.21:15
mthtoday I probably wouldn't bother with MMX indeed and go straight for SSE2 or GLSL or OpenCL21:15
graphitemasterSSE4 is pretty suboptimal21:16
graphitemasterGLSL again does the card support shaders?21:16
graphitemaster5 years ago ARB was really the only choice :)21:17
mthmost cards do nowadays21:17
graphitemasterand ARB was not all that different from ASM the syntax was but the thinking was and still is the same.21:17
graphitemastererm thinking was the same the syntax was different *21:17
mthactually my first GLSL shaders are from 2006 :)21:18
mthbut back then it would only work on certain cards21:19
mthespecially Intel didn't support OpenGL 2.0 for a long time21:19
graphitemasterIntel still doesn't support half of GL :P21:19
graphitemasterI've herd cases where you can get better gfx using llvmpipe over Intel then using the native Intel GMA crap :P21:20
graphitemastersoftware rasterization at it's finest :)21:20
Action: Jay7 remember LDIR instruction21:20
Jay7was very useful for graphics :)21:20
mthon MSX VRAM was not shared with the Z80, so you had to use OTIR instead21:21
graphitemasterthere where quickerways then using LDI LDIR21:22
graphitemasterusually save the stack pointer, load the hl register pair with zero.  massive loop pushing HL onto the stack, then the stack moves up screen and down through memory and in the process and clears the screen :)21:23
rohmeh21:24
rohyou guys make me feel old.21:24
graphitemasterI'm 16 years old :P21:24
Action: roh will be 30 in august and its evil to hear stuff you did when it was new and fancy21:24
graphitemasterI own a ZX Spectrum I've played with Z80 before :P21:25
rohmy 2 cents: ignore the current seperation of 'X'PU(s)21:25
mthroh: I'm 35, these are stories from the good old days ;)21:25
rohthere will be cpus which just have N cores and units which will look remarkably like some merge of cpu, gpu, crypto-accel, dsp and maybe we will get even some pld-esque units21:26
rohall that syncronisation stuff just eats away most of the gain by offloading anyways.21:27
graphitemasterI think what would be neat is if someone interlocked varations of CPUS from mixed CISC it mixes RISC then made a common interface that could translate op code and offload work on each cpu equally21:27
mthroh: but will it have a shared memory like current CPUs or local memories like the Cell?21:27
rohe.g. dma not being faster than simple loops etc. (cloggs memory bus, set up partially complex and needed too often etc)21:28
graphitemastergenerally you can just plugin anything into this core and as many as you wanted and it would work21:28
rohmth: modern computers are numa cubes anyways. atleast amd based ones since... well.. nearly 10 years now21:28
rohmeans every 'cpu' has its own local memory, maybe shared by 2 or more local cores, and there is a shitload of bandwith with low latency to 'other stuff' .. maybe cpus, maybe io (mostly differs in cache coherency)21:29
rohalso i think that these nice products like cell will vanish. their special feats will become mainstream. but specialized cpus like that just make no sense economically21:30
Action: Jay7 is 32 :)21:30
rohthus.. my bet is on 'we will have fun with new instructions' and lots of cores.21:31
wpwrakroh: agreed on xPUs. those specialized co-processors come and go. they always end up being absorbed into the principal core sooner or later.21:32
rohwpwrak: if they make sense, yes21:32
mthwhat will we use to program them though?21:32
rohmth: more uniform than this gpu, dsp, cpu madness right now (which needs specialized tools and knowledge for every sub-arch)21:33
rohbasically: think 'gcc' (replace with clang or what you wish when they finally make it complete)21:33
mthI don't know C + threads is going to work21:34
mththreads are horrible things anyway21:34
rohmth: sure. have a better idea?21:34
mthnot really, that's the problem21:34
graphitemasterforking21:35
mthGLSL parallizes very well, because it's basically a functional language with a C-like syntax21:35
mthbut not every algorithm is easy to express in GLSL21:35
mth*parallellizes (?)21:36
rohmy point is: try syncing 3 of the current cores in a pipeline working on some data... then imagine the cpu is also running a multitasking os with preemtion. then imagine every of these cores using a different compiler from a different company... can you imagine that c-threads somehow sound quite nice compared to the hell you will be in now?21:36
rohits all nice and shiny as long as you dont need to glue 2 vendor-sdks into one project21:37
rohalso lots of stuff mis-optimized (depending on usecase) isnt in your way anymore. e.g. writing stuff to gpu memory is fast (optimized) .. try reading something back to the cpu memory... takes aeons21:39
rohcompared to a write. has been that way since agp times. so sometimes it even makes sense to do steps on the cpu instead of using the fast way into gpu mem, do some op there (do sync), fetch slowly, do next op which the cpu can but the gpu is too stupid for.21:40
mthiirc AGP was very asymmertrical with the bandwidth, but on PCI Express the direction shouldn't make much of a difference21:41
rohso in the end one ends up with optimizing the own usecase, which could mean: do more steps on the cpu even if the gpu is faster not not get your advantage eaten up by slowness in unoptimized memory transfers (which one cannot speed up)21:41
rohmth: pci-e still is multiple times slower than memory access or a hypertransport link21:41
mthyes, but CPU->VRAM and VRAM->CPU are both about equally slow21:42
rohmy point is: nowadays gpus arent much more like 5-10 years ago. its mostly a block of shaders with some minimal memory copying logic and a display-readout and fast memory. add the shaders and the memory interface bandwith to the main cpu and you dont loose anything, you only gain21:43
mthbut it's true that fast processing is useless if you can't get the data in/out in time21:43
rohmth: gpus are optimized for gaming, not your usecase neccessarily.21:43
rohe.g. all the video and multimedia blitting units are gone. because you can also program a shader to do colorspace conversion21:44
rohbut when it comes to e.g. implementing complex stuff which isnt just doing fast math but assembling packets, shaders suck. not built for that. so compressing data or so isnt their best deed. they can do some steps but the gruntwork usually is done in specialized hw or the cpu and not a programmed shader.21:46
rohamd is on the right way there. lets hope they dont die from intels constant nagging21:46
rohand keep supporting free drivers.21:47
mthI hope that at some point driver support will just be an LLVM backend for a new chip rather than a full driver21:48
rohi hope we dont need new archs that often21:48
rohand that llvm gains more working backends. last time i tried it couldnt even generate properly working arm code, not speaking of booting kernels21:49
mthApple allows LLVM-compiled apps to be submitted, so it must work most of the time nowadays21:49
mthI recently managed to compile openMSX (pretty complex C++ code, crashes quite a few GCC versions) with Clang++ and libcxx on x86_6421:50
mthso it's starting to become useful in production21:50
rohis there a avr backend?21:51
mthafaik only x86, x86_64 and ARM are mature backends, the others are experimental21:51
mthI don't know about AVR support; MIPS support exists but may or may not be usable21:52
rohmeh. that needs to change. multi-arch is the most important feat of gcc.21:52
rohatleast to me. compilers are annoying enough that i dont want more than one kind to know personally ;)21:52
rohwell.. in the end ist all just a fancy macroassembler, so if you do nice code, the backend shouldnt matter that much nowadays21:53
mththey have reduced the arch-specific code to a minimum, so that should help in getting more archs supported21:54
mthI've heard people complain about GCC support for Alpha, so it's not paradise either21:54
rohalpha is dead. really dead for some time now21:55
rohall thats nice in there went into x86-64 anyways. and into the design of amd cpus21:55
rohthats where hypertransport and the numa concept come from.21:56
mthyep21:56
rohhppa is also dead. i think mostly mips arm x86-64, x86 and some mcu platforms are important right now21:56
rohthe problem is the sheer number. msp430, avr, infineon has its own 16bit arch... the hitachi stuff.. renesas...  etc21:57
rohavr is to inprecise. there are 8bit and now also 32bit ones (different arch, avr32)21:58
Action: mth afk now22:02
qi-bot[commit] Neil Stockbridge: There is now a libncurses-dev package http://qi-hw.com/p/openwrt-packages/b9ee6f423:53
--- Fri May 20 201100:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!