**** BEGIN LOGGING AT Tue Aug 02 02:59:57 2011 Aug 02 03:38:51 dtzWill: sometimes I overcomplicate things - I think I'll just try banging on /dev/fb like you said **** BEGIN LOGGING AT Tue Aug 02 03:41:18 2011 Aug 02 03:43:59 PuffTheMagic, i like it Aug 02 03:48:19 heh i don't think anyone's been able to use palm's source to build sdl Aug 02 03:48:55 Simon80: wait condition sounds good. so no sound instead of stutters? Aug 02 03:49:02 yeah Aug 02 03:49:13 Simon80: i'm re-investigating fixing my pixi so i can test, but no dice so far. Aug 02 03:49:23 not only that, but if it waits for a bit and the sound becomes available, you get proper sound instead of no sound or stutters Aug 02 03:49:44 oh, i see. indeed. Aug 02 03:50:50 optimally, what should happen, at least on GB, but probably also on the GBA, if possible, would be to simply copy the registers that control the sound synth, and just generate the sound during the callback Aug 02 03:51:14 so, there would still be data transfered between the threads, but presumably a lot less Aug 02 04:06:05 so, I just tried disabling texture uploads and testing GBA emulation, to see how it is, and it's still pretty bad Aug 02 04:06:13 but then there are those asm instructions to try out too Aug 02 04:09:56 Simon80: the ubfx ones, or...? Aug 02 04:10:05 Simon80: the ubfx i think gave a ~5% on the pre, not a whole lot. Aug 02 04:10:19 i forget what other ones the asm_core uses that the pixi doesn't have. Aug 02 04:10:20 well, not those, I mean, enabling ARM_CORE, entirely Aug 02 04:10:27 it's just ubfx, I think Aug 02 04:10:33 and I can fix that Aug 02 04:10:51 for sure, i just figured if it was only ubfx i would've done it already Aug 02 04:10:58 since i introduced the ubfx versions... Aug 02 04:10:59 lol Aug 02 04:10:59 maybe there are others Aug 02 04:11:07 oh, was the rest someone else's code? Aug 02 04:14:50 I'm mostly a newbie when it comes to ARM asm, at least writing it, but I think those ubfx instructions can be and + lsr instead Aug 02 04:15:15 you'd maybe have to load the number 1 into another register if the first operand has to be a register and not an immediate Aug 02 04:19:36 well the question is if that's going to be any better than computing the flags themselves Aug 02 04:20:03 the idea behind ubfx was "hey we're emulating arm instructions with complicated flag predicates. lets use the chip to compute the flags, since it /has/ these instructions, and then just extract the results' Aug 02 04:20:16 the flags then stall on the computation itself, but overall it proved to be faster Aug 02 04:20:44 but yeah ubfx is just a builtin for shifting and masking out the bits Aug 02 04:22:02 i'd look at the ASM generated for the pixi for the C version, curious how terrible (or not) it is. Aug 02 04:24:10 it's hard to tell, because there's debugging directives inflating the volume of code, and if you put it into a function, there's overhead from that Aug 02 04:24:40 and everything is out of order, of course (I hope that's because the compiler schedules things intelligently, but I don't know Aug 02 04:25:00 I would guess that it's not as good, but it wasn't an order of magnitude off Aug 02 04:25:24 I gave up on that and just decided that when I wanted to check on that, I should enable ARM_CORE and just see if there's a speedup Aug 02 04:27:05 sounds good Aug 02 04:27:13 wonder how the scheduler /is/ going in gcc Aug 02 04:28:05 i don't mean to throw ricer flags around, but i'd imagine given the extreme manual inlining it's resorting to some linear reg allocators, and maybe it can do better. Aug 02 04:28:56 shrug, mostly a note for myself b/c i'm curious :) Aug 02 04:31:33 yeah, I'm not that deep into compiler land yet Aug 02 04:31:46 although I know what reg allocators are at least :\ Aug 02 04:32:14 dtzWill, Simon80: all set. Aug 02 04:32:41 Simon80: welcome! Aug 02 04:32:46 thanks! Aug 02 04:41:48 PuffTheMagic, any reason that make package needs to rebuild the app every time you run it? Aug 02 04:42:40 "need" no Aug 02 04:43:14 ok, any reason makefile is configged for that? Aug 02 04:43:54 always works Aug 02 04:44:00 lol Aug 02 04:44:01 ok Aug 02 04:44:05 that is true Aug 02 04:44:58 I hate it that it's 2011 and choosing a build system is still a quagmire Aug 02 04:44:58 also, ccache is your friend Aug 02 04:52:01 I didn't mean that in a negative way, though, just that using ccache would mostly make it ok to do a full rebuild every time Aug 02 05:49:32 dtzWill: you're probably asleep, but I added a wait condition back into the sound code, in only the one direction - it seems to work fine and not interfere with performance, so I published it Aug 02 15:31:51 Simon80: run gentoo, then your OS is your build system and everything is great! Aug 02 18:56:40 PuffTheMagic, i broke my copy of editah last night hacking on it, this new push you did this morning still has make prepare broken. http://pastebin.com/AnfCQK0G Aug 02 18:58:17 so... fun fact. gonna Aug 02 18:58:47 govnah is not setting the second core to 1.5 with uberkernel. found that out playing with sunspider Aug 02 18:59:08 orly Aug 02 18:59:24 * scoutcamper goes to try f15c Aug 02 19:05:11 halfhalo: that's very interesting Aug 02 19:07:24 yeah. Aug 02 19:08:10 also, I do want the 2ghz test kernel. want to play with sunspider on it. Aug 02 19:08:39 halfhalo, me top Aug 02 19:08:42 to* Aug 02 19:10:10 the second core on the tp is interesting in that it's offline most of the time Aug 02 19:10:43 I could see lots of governor-type things having issues with that Aug 02 19:13:38 in my case it just didn't get the higher freq passed to its max scaling freq file. Aug 02 19:36:13 scoutcamper: why do you keep recloning Aug 02 19:36:23 all you need to do is rm -rf *; git reset --hard; git checkout -f Aug 02 19:37:00 PuffTheMagic, i like 100% completely fresh stuff Aug 02 19:37:09 call me crazy ... Aug 02 19:37:26 that is crazy Aug 02 19:37:32 git does completely fresh Aug 02 19:37:50 scoutcamper: STOP CLONING! Aug 02 19:37:53 its a waste of bw Aug 02 19:37:57 PuffTheMagic, ok Aug 02 19:37:57 you NEVER need to reclone Aug 02 19:38:00 you can actually just do git clean -dxf to delete everything Aug 02 19:38:10 the commands i just showed you will give you a clean setup Aug 02 19:38:22 git clean -dxn shows you what would be removed Aug 02 19:38:52 Simon80: i never trusted git clean... but then i never really explored all its options Aug 02 19:39:22 scoutcamper: latest Tide has rooted service now Aug 02 19:39:46 yeah, if you don't pass any args, it doesn't clean empty dirs, and doesn't remove ignored files, which is weird Aug 02 19:39:57 you can also remove only ignored files, which makes more sense to me Aug 02 19:40:10 but git clean -dxf removes everything Aug 02 19:40:25 including things you didn't want to get removed, of course Aug 02 19:42:25 thats what i like Aug 02 19:42:26 which is why i do rm -rf * Aug 02 19:42:26 ;) Aug 02 19:42:26 i dont have things in my repo that i dont want tracked usually Aug 02 19:42:26 only time that happens is when some build process leaves shit around Aug 02 19:43:05 god damn submodules Aug 02 19:44:30 yeah, but I mean, if you have a tag file in there or something Aug 02 19:45:30 tag file? Aug 02 19:45:51 ctags Aug 02 19:46:25 for completion and jumping to function definitions and stuff Aug 02 19:47:19 i dont think i 've ever use ctags Aug 02 20:04:15 https://www.box.net/shared/m91m38y2k42aq3xok38j Aug 02 20:04:19 ^^ Tide 0.0.11 Aug 02 20:04:21 with rooted service Aug 02 20:05:45 * scoutcamper smacks himself for breaking his ability to build tide Aug 02 20:06:59 scoutcamper: that should be fixed Aug 02 20:07:01 i think Aug 02 20:08:33 same error Aug 02 20:08:43 different clone # though Aug 02 20:09:23 i dont get why there are always figgen issues with the submodules Aug 02 20:09:44 just cd into that dir and do 'git checkout master' for now Aug 02 20:09:49 then it should proceed Aug 02 20:11:48 nope, its still breaking on node. im going to manualy clone dryice, pilot, and all that other crap and see if i can just make it build Aug 02 20:16:15 breaking on node? Aug 02 20:16:26 you mean uglify-fs? Aug 02 20:16:58 yes Aug 02 20:18:45 give me 1 min Aug 02 20:24:09 scoutcamper: works now Aug 02 20:27:27 PuffTheMagic, works now :D Aug 02 20:32:53 PuffTheMagic, im setting up to compile in chroot on device Aug 02 20:33:12 soon ill be able to work on tide with tide and compile on device Aug 02 20:33:17 i hope Aug 02 20:33:37 scoutcamper: you should work on getting things like gcc and python in preware Aug 02 20:34:27 i should Aug 02 20:37:41 holy crap Aug 02 20:37:46 sdk installed in chroot Aug 02 20:38:24 no emulator, but who needs that Aug 02 22:01:00 scoutcamper|away, filewriting support pushed Aug 02 23:24:09 PuffTheMagic, built and installed on device :D Aug 02 23:24:53 scoutcamper|away, you shuld pull and build again Aug 02 23:24:56 0.0.14 Aug 02 23:27:09 PuffTheMagic, also built and installed using chroot and the device only :D Aug 02 23:27:51 PuffTheMagic, nice spot to keep your todo list Aug 02 23:28:04 :D Aug 02 23:28:12 * scoutcamper|away likes it Aug 02 23:28:20 now, to work on tide with tide Aug 02 23:28:44 scoutcamper|away: will you clean it? ;) Aug 02 23:29:00 heh Aug 03 00:26:44 who was it who had played with CPU1 enabling on the Touchpad ? Aug 03 00:28:02 linuxjacques, Aug 03 00:28:24 I did too but he worked it harder than I did Aug 03 00:32:57 Simon80: great re:adding sound code, i'd imagine it doesn't interfere much and sounds like the right fix. Aug 03 00:33:32 Simon80: informally, does it 'sound' better? Sound seems to be one of those things one can notice issues in rather readily (as opposed to dropping a frame or two) Aug 03 00:34:17 heh i've always done rm * -rf; git checkout .; to fix a borked git tree Aug 03 00:34:41 PuffTheMagic: can you make a shared box.net and upload tide to there as you update it? :D Aug 03 00:35:12 i'm very excited to push the touchpad as a development device ^.^ Aug 03 00:35:17 alright enough backlog... Aug 03 00:35:36 Simon80: sorry that I disappeared last night, some things came up and I didn't finish what I wanted. Aug 03 00:36:00 no, no, I really don't want you to feel like you have to stick around just cause I'm on IRC Aug 03 00:36:04 I'm about to disappear myself Aug 03 00:36:10 Simon80: haha nah i'm alwaayyss here :) Aug 03 00:36:18 * halfhalo goes to sunspider new 1.7GHz kernel! Aug 03 00:36:24 halfhalo: post results! :) Aug 03 00:36:29 k, bbl Aug 03 00:36:39 Simon80: (is idling a problem? ;)) Aug 03 00:37:08 Simon80: i'll poke at it briefly, but when you get a chance could you look at the pixi branch on the webos-internals branch? (and master, if you'd like) Aug 03 00:37:18 I can't test pixi, and reviving it failed again, so writing it off once and for all. Aug 03 00:37:33 maybe some guest damaged it or something while it was on my desk, idk :/ Aug 03 00:37:48 (it's sole job was to sit on my desk and help test... how'd it get damaged?!) Aug 03 00:38:45 I will in a bit. forcing cpu1 to 1.5GHz makes a 600ms difference in sunspider vs it being 1.2ghz. if someone makes me a 2GHz kernel I shall be muy happy. Aug 03 00:39:26 Simon80: i got overzelous in trying to fix the scripts to allow objdir != srcdir, and then merging pixi branch into master.... such that we could have a unified source base for all devices Aug 03 00:40:06 dtzWill, shared box.net? Aug 03 00:40:07 happy to discuss if that seems like a bad idea, but moving forward i think isolating the main differences in devices (armv7 vs armv6), and the various resolutions Aug 03 00:40:20 PuffTheMagic: like a folder? thought you could do that Aug 03 00:40:31 and then give people access so you could just drop ipk's in there and we'd all get them Aug 03 00:40:57 Simon80: but idea is unified codebase instead of having a ...pre/pre3/pixi/veer/touchpad set of branches, at least if that's possible. Aug 03 00:41:04 its gonna go to testing feed soon Aug 03 00:41:47 fix up the resolution hardcoding (biggest sticking points there are text-reflowing and the resources, which we can look for in resources-320x480/ or whatever, maybe) Aug 03 00:41:58 having just fought to get things working on the pixi from the pre stuff, maybe you have some insight there. Aug 03 00:42:07 PuffTheMagic: oh, even better Aug 03 00:42:34 you seemed disinclined to put it there, and i wasn't gonna argue, but since you were already uploading to box.net, it seemed short hopskip to putting it somewhere where i could just click on my deice and have it ^.^ Aug 03 00:42:52 oh, btw 1.5GHz sunspider is ~3200, 1.5+1.2 is ~3800, 1.2 is ~4200 Aug 03 00:43:29 halfhalo: that mimics my results. Aug 03 00:43:48 maybe should've spoken up sooner, but was curious that i got 3800 when 3200 was posted for 1.5ghz earlier Aug 03 00:44:13 figured i wasn't paying enough attention (maybe just came off a misc failure and it'd reset to 1.2ghz), and left it at that Aug 03 00:44:28 halfhalo: did you see my results from earlier that in X, chrome gets like 2400 or something? Aug 03 00:44:29 lol Aug 03 00:44:34 that was one 1.5/1.2 Aug 03 00:44:36 *on, even. Aug 03 00:44:54 ka6sox-farfarawa: weren't you poking at buliding preware packages that installed stuff into the chroot Aug 03 00:45:07 having chrome in a card would be pretty useful, works great Aug 03 00:45:15 yes, thats on my list Aug 03 00:45:32 ka6sox-farfarawa: kk just know you'd poked at it, figured i'd poke you about it since that'd be excellent Aug 03 00:45:41 i needa get off my ass and push the updated touchpad keybindings ._. Aug 03 00:45:59 yup :) Aug 03 00:46:03 yeah, was going wth earlier today running sunspider. the 1.5GHz matches nicely with the default 1.5 4G tablet, which makes mucho sense. Aug 03 00:46:22 but I need to get with you and rwhitby about making xecutah and the xserver so we can manage multiple xservers with xecutah and assign apps to them. Aug 03 00:46:38 dtzWill: so are you saying that chrome running inside the Ubuntu chroot rendering to X in a card beats the native browser on SunSpider? Aug 03 00:46:48 rwhitby: painfully so Aug 03 00:46:56 whoa Aug 03 00:47:09 yeah guess y'all missed that in the backlog :) Aug 03 00:47:11 dtzWill: how do I replicate that result? Aug 03 00:47:13 like 25% faster Aug 03 00:47:26 rwhitby: apt-get install chrome-browser Aug 03 00:47:31 err maybe chromium-browser Aug 03 00:47:34 run it Aug 03 00:47:39 i was also using lxde at the time Aug 03 00:47:46 chromium-browser Aug 03 00:48:05 FWIW i /was/ using my framebuffer blitting hack, but i didn't think the js stuff did anything w.r.t actual rendering anyway, but just saying that as a potential source of unreproducibility Aug 03 00:48:14 ...we can revisit differences if somehow you get something different Aug 03 00:48:32 dtzWill, i will look into the foler after i eat Aug 03 00:48:58 PuffTheMagic: kk. testing feed works too, and i have enough going on that if testing feed is happening in next day or so not on my behalf Aug 03 00:49:04 but that said, it might be useful for all of us Aug 03 00:49:07 for easy ipk distribution Aug 03 00:49:27 since we _do_ have 50GB kicking around ^.^ Aug 03 00:50:11 chromium being faster makes sense Aug 03 00:50:31 box.net's touchpad app lets you make folders and send links to people Aug 03 00:50:39 it's the only client i _have_ so idk about the rest hehe Aug 03 00:52:18 dtzWill: ok, going to reproduce your sunspider results now Aug 03 00:52:47 what are the 1.2GHz stock and 1.5GHz sunspider results so far? Aug 03 00:56:30 rwhitby: stock is ~4200, 1.5+1.5 is ~3200, and i just got a 2756 on 1.7+1.7 Aug 03 00:57:00 in webos browser. been running these almost all day :p Aug 03 00:58:32 dtzWill, hopefully tonight after i take care of a few small things and no one else brings up anything major Aug 03 00:59:41 PuffTheMagic: wonderful Aug 03 01:01:24 PuffTheMagic: so ridiculously glad you not just started it, but are following through on tide :D Aug 03 01:01:56 err not suggesting you have a habit of not doing so; but OSS projects in general seem susceptible to that, and it's exciting to see this being pushed :D Aug 03 01:02:43 dtzWill: results replicated. 2665 for chromium on 1.5+1.2 Aug 03 01:03:16 dtzWill, thanks, i do take on too many projects and then things get forgotten about Aug 03 01:03:19 ..... novatool .... Aug 03 01:03:27 dtzWill, I just need more time...I have 3 things I need to finish Aug 03 01:03:29 dtzWill: and tweeted. Aug 03 01:03:34 PuffTheMagic: I'm _certainly_ guilt of it as well, but definitely wasn't a personal comment :) Aug 03 01:03:39 * halfhalo notes chromium will always be faster for now. it has its own v8 process/engine vs sharing one. Aug 03 01:03:47 dtzWill, didnt take it as one Aug 03 01:04:03 * dtzWill nods, just like being clear :) Aug 03 01:04:19 one day i'll actually say something mean and WONT CLARIFY I WASNT BEING MEAN Aug 03 01:04:22 rwhitby, will you give tide a spin and let me know of anything obvious that im missing Aug 03 01:04:25 then you'll know, oh you'll know... Aug 03 01:04:28 * dtzWill wonders off for a bit Aug 03 01:04:35 PuffTheMagic: yes. where's the latest ipk? Aug 03 01:06:07 rwhitby: in build.git, is it possible to claim deviceompatiblity for both pre /and/ pixi, but build _different_ ipk's for each? Aug 03 01:06:21 (such that each ipk is only, in fact, suitable for a particular device?) Aug 03 01:06:25 dtzWill: it's make, it does what you tell it to do Aug 03 01:06:42 rwhitby: i mean w.r.t how it's pushed to the feeds/interpreted by ipk/etc Aug 03 01:06:49 but okay, i'll poke at it :). Aug 03 01:07:14 dtzWill: compatibility is just a value in the source line in the control file Aug 03 01:07:23 rwhitby, https://www.box.net/shared/p80p933gyh5r0jxb4zh0 Aug 03 01:07:27 ^^ v0.0.15 Aug 03 01:07:27 dtzWill: and routing to feeds is done by the _arm*.ipk extension Aug 03 01:07:32 for anyone that wants to play Aug 03 01:08:05 * dtzWill palm-installs for later Aug 03 01:08:18 rwhitby: great, tyvm for teh info. Aug 03 01:08:59 dtzWill: I'll take a look at what makefile trickery needs to be done to cause the right bits to go in the right places Aug 03 01:09:31 dtzWill: but the easiest is just to say compatible with both, and key on armv6 and armv7 package targets Aug 03 01:10:18 dtzWill: should we focus on RANDR before optimising performance? Aug 03 01:10:55 rwhitby: that's what i was going to do re:compatbile both/targest, but wasn't sure. tyvm for info/ideas. Aug 03 01:11:44 dtzWill: we often do just _arm these days, but _armv6 and _armv7 continues to be supported Aug 03 01:12:07 rwhitby: hmm, maybe. I'm not especially compelled to, but it shouldn't be too hard to add to the GL version and would probably be nice... Aug 03 01:12:43 dtzWill: randr is required to allow us to dynamically scale the display size when we work out how to make the keyboard disappear when a bluetooth keyboard is connected, right? Aug 03 01:16:45 dtzWill, you can make "fat" packages that have both armv6 and armv7 now Aug 03 01:18:46 ka6sox-farfarawa: are you sure about that? Aug 03 01:19:19 I don't think that's a good idea when the binary's pushing 1MB Aug 03 01:19:26 PuffTheMagic: did that .ipk have a postinst file in it? Aug 03 01:19:32 Simon80: it's not the case. Aug 03 01:19:39 rwhitby, ya it should have Aug 03 01:19:47 webOS fat packages are enyo + mojo Aug 03 01:20:00 ah, that makes a lot more sense Aug 03 01:20:08 I've not seen anything about armv6+armv7 in one ipk. Aug 03 01:20:20 it would have been a surprise to me too Aug 03 01:20:23 not that I would know Aug 03 01:20:33 just seems too wasteful Aug 03 01:20:52 rwhitby, there an issue or something? Aug 03 01:20:55 PuffTheMagic: sorry, my mistake Aug 03 01:22:31 nvm, need more poking at building stuff to make it work in our dev envs as well as build.git. :) Aug 03 01:22:37 my understanding was those are being used and accepted Aug 03 01:22:44 will be happy when this is done, though, been wanting it all built from source for a while now... Aug 03 01:23:16 yeah, it would hopefully be easier Aug 03 01:23:21 who runs it though, us? Aug 03 01:23:53 I mean, that's the best case scenario Aug 03 01:23:58 in terms of effort Aug 03 01:24:11 dtzWill, im gonna have to get TeXLive in preware so I can write paper in Tide! Aug 03 01:25:12 dtzWill: sorry for giving you reason to waste time on the build system instead of working on more interesting stuff Aug 03 01:25:18 I guess I have that effect on people, lol Aug 03 01:25:33 Simon80: haha nah i like build stuff, and this needs to be done regardless Aug 03 01:25:43 PuffTheMagic: nice! :D Aug 03 01:26:55 I don't think it will get done today, but I'm going to try backporting the asm to armv6 in the meantime, out of curiosity Aug 03 01:30:30 great! Aug 03 01:30:56 I'm not sure it will be enough to bring GBA into the usable range though, but we'll see Aug 03 01:31:02 oh thank god codesourcery's mirrors are giving me great speeds, usually it's like 50k/s x.x Aug 03 01:31:03 it's pretty much find and replace Aug 03 01:31:11 yeah, it was for me Aug 03 01:31:20 which toolchain are you grabbing? Aug 03 01:31:26 Simon80: yeah, is hopefuly straightforward. you mean the ubfx -> shift+mask? Aug 03 01:31:29 yeah Aug 03 01:31:50 I switched to 2011.03 yesterday, it added 200kb to statically link libstdc++, but that's okish Aug 03 01:31:55 Simon80: well, 2009q1. i actually have....quite a few of them already (inc this one) but build.git doesn't konw that and since it downloaded so fast i'm cool with ditching it Aug 03 01:32:01 err with not fighting it Aug 03 01:32:02 beats the memory usage when ARM_CORE is enabled Aug 03 01:32:15 oh, yeah Aug 03 01:32:22 wonderful, glad for that. Aug 03 01:32:32 and yes, I agree with unifying the codebase Aug 03 01:32:56 I started out not following that, but at least with the July changes, I started trying to stick to that Aug 03 01:33:02 oh dear, build.git does _not_ work with parallel make hahaha Aug 03 01:33:12 yeah, <3 make Aug 03 01:33:29 understood, and especially intially it's a perhaps unreasonable burden. you just wanted it working ^.^ Aug 03 01:34:01 Simon80: yeah, i absolutely love make as well :) Aug 03 01:34:30 it's why I've tried so many build systems Aug 03 01:34:57 it's amazing how hard it can be to solve such a well defined problem Aug 03 01:35:11 I won't call it a simple problem Aug 03 01:35:43 absolutely understood, and agreed. Aug 03 01:35:56 wrt to porting things, in general it's best to define conditions based on screen size, cpu instruction set, and NOT device Aug 03 01:36:06 mostly surprising is how it's /not/ solved givne that it's behind pretty much everything. Aug 03 01:36:15 yeah, that too Aug 03 01:36:24 but we put up with it Aug 03 01:36:34 Simon80: great. maybe have defines for architecture, and dynamicaly detect resolution and do what we can from there? Aug 03 01:36:40 I like the idea with SCons to hash content and try to be ultra safe, but performance kind of suffers Aug 03 01:36:41 (expect resources to be avail for that, etc?) Aug 03 01:36:45 yeah, exactly Aug 03 01:36:58 although resolution can be hardcoded as it is now, I don't care Aug 03 01:37:08 understood, but i wanna get this on my veer :) Aug 03 01:37:09 but I mean, menu code, etc. should check that, not the device Aug 03 01:37:14 and yes Aug 03 01:37:16 but i guess i could just run the pixi version lol Aug 03 01:37:35 but then touchpad stuff is on the horizon, although that might have to be a somewhat different app, we'll see how that goes Aug 03 01:37:39 the veer's a good example of this though, cause it has the Pixi's screen size, but a Cortex-A8 CPU faster than the Pre's Aug 03 01:37:56 and the GPU is again more like the Pixi Aug 03 01:38:19 I will be surprised if it doesn't also have a horrible problem there with streamed textures Aug 03 01:39:17 btw, the architecture defines are a nightmare Aug 03 01:39:46 do the pixi/veer have discrete video memory? Aug 03 01:40:31 some cute trick people did on other devices is upload a special texture, scan memory for the bytes in it, and just blit there Aug 03 01:41:02 I'm not an expert, but I think the way it works is they have on-chip memory that is used to process tiles, and the rest is system memroy Aug 03 01:41:04 memory* Aug 03 01:41:07 so that may work Aug 03 01:41:08 last time i looked in that direction i concluded it wouldn't work on our devices, but i thought i'd mention it again since you might be more comfortable with the related issues Aug 03 01:41:29 I'm not really more comfortable with that than you'd be, I think Aug 03 01:41:41 plus, the texture probably gets swizzled first Aug 03 01:41:47 hence the slowdown and CPU time Aug 03 01:41:58 and if you try to swizzle it yourself, you might be just as slow Aug 03 01:42:08 definitely haven't tried it, the direct freambuffer blitting worked better and i think is the 'best' you can get in terms of performance w.r.t blitting a bunch of screen-sized pixel to the screen Aug 03 01:42:11 (not for things like scaling, etc) Aug 03 01:42:15 for sure Aug 03 01:42:33 Simon80: agreed I would guess there's soomomee kinda of reformatting going on Aug 03 01:42:45 swizzling, etc Aug 03 01:42:46 I think you can do the scaling within the budget that is freed up by not using the driver Aug 03 01:42:51 and I don't like scaling anyway Aug 03 01:42:56 other than 2x scaling Aug 03 01:43:02 quite possibly, especially if you limit yourself to clean multiples scaling Aug 03 01:43:24 does the pixi have neon? scaling seems suitable to accel by SIMD Aug 03 01:43:27 nope Aug 03 01:43:53 fyi though, if you're ever implementing an orientation change or scaling in software, memory access may be the biggest cost Aug 03 01:44:28 I don't have experience testing out the cost and such, but I've read about it, on x86 it's insanely high if all you're doing is touching the memory Aug 03 01:45:06 so for an orientation change, you'd want to work in n by n squares where n is the L1 cache line size Aug 03 01:45:23 yeah i'd definitely outsource the impl if i could Aug 03 01:45:35 I think you can just add an extra inner loop to do this Aug 03 01:45:49 writing a maximally optimal memcpy, taking advantage of alignment/SIMD/etc, i'd be disclined to think i could do better myself without at least trying to find an existing impl Aug 03 01:45:58 heh, hopefully. Aug 03 01:46:24 yeah, the other thing is you can just write a simple as possible for loop for scaling or copy, and hope the compiler recognizes it Aug 03 01:46:55 I dunno if that would work for orientation changes, etc. Aug 03 01:47:26 I don't care about scaling though, and I mean, skin support is maybe out if the blending has to be done in software Aug 03 01:47:36 maybe not though, what with the freed up 25% Aug 03 01:48:07 oh, I forgot to link to this: Aug 03 01:48:07 http://boost.2283326.n4.nabble.com/Help-needed-for-shared-ptr-issue-on-iPad2-dual-core-ARM-td3411481.html#a3412746 Aug 03 01:48:59 this is how you tell if you're on armv7 or not, you have to detect one of those.. it would be 7A for all WebOS stuff though, presumably Aug 03 01:54:52 I was just hoping there would be an __ARM_ARCH__ macro or something I could use, but apparently that's our responsibility to define Aug 03 02:01:19 Simon80: you mind if i abstract out the depency on GLESv2 by using SDL_GL_GetProcAddress? can't imagine it'd hurt anything... Aug 03 02:01:31 build.git doesn't have the library, and adding it looks annoying. Aug 03 02:01:49 I wouldn't, except that I don't think that works Aug 03 02:01:56 lol what Aug 03 02:01:57 :( Aug 03 02:02:02 try it and see Aug 03 02:03:02 well their sdl source has it defined and loading the right library and dlsym'ing :( Aug 03 02:03:04 but okay i'll try Aug 03 02:03:26 yeah, if it works, I definitely will not mind something like that Aug 03 02:03:41 to the contrary, lol Aug 03 02:03:45 :) Aug 03 02:04:21 except that I don't think any of the extensions that would open up for me would actually help against the texture upload problem Aug 03 02:04:52 extensions id would open up? Aug 03 02:05:10 the PDK contains the PowerVR libGL Aug 03 02:05:30 so I can't link against it and call functions that only exist in Qualcomm's Aug 03 02:05:45 ah, kk. Aug 03 02:05:48 yeah Aug 03 02:06:02 yeah te symbols in the various libGL's didn't seem to be especially useful (ones ending in _OES, etc) Aug 03 02:06:27 there's probably some combination of libraries I could grab from the Pixi and link against, but grabbing just the one I needed caused segfaults Aug 03 02:07:32 I didn't use the source when I tried to get GetProcAddress working, maybe you'll have better luck Aug 03 02:07:42 I'd forgotten all the source was available Aug 03 02:07:49 lol i have libsdl-ttf from 1.3.5 staged from last time i tried to do this Aug 03 02:07:49 haha Aug 03 02:10:51 rwhitby/et al: Does build.git have dependencies atm? AKA how does an app know that toolchain/* was already built? Aug 03 02:11:01 or do we just force that being built first Aug 03 02:11:02 it does not Aug 03 02:11:29 kk Aug 03 02:11:35 build.git is an incredibly dumb build system Aug 03 02:12:16 i'm okay with that, that's one of it's benefits :P Aug 03 02:12:21 less to break xD Aug 03 02:12:46 sigh, okay so it doesn't have libSDL or libSDL_ttf or anything else, and we can't build those from source since the sources aren't complete Aug 03 02:12:52 or weren't last time we all looked at this Aug 03 02:13:06 should i create dummy shlibs like was done for lunaservice? :/ Aug 03 02:15:05 bleeh Aug 03 02:15:15 maybe we should just built the binaries ourselves, Simon80 :) Aug 03 02:15:20 *build, even. Aug 03 02:15:33 i'm for making this work, but this has gone to more than i can bite off atm :) Aug 03 02:16:43 yeah, I'm fine with that Aug 03 02:17:01 I think if we do that, maybe the makefiles should expect ipks instead Aug 03 02:17:27 instead of expecting the pkg dir as it currently is Aug 03 02:17:44 Simon80: i thought about that, but the formatting of the ipk's is different in preware iirc Aug 03 02:17:54 or maybe i just didn't figuring that piece out, w.r.t signing, etc Aug 03 02:17:57 yeah, but the makefile takes the ipk and extracts it, I think Aug 03 02:18:07 Simon80: sounds like you've investigated that more than i have :) Aug 03 02:18:08 and then remakes it in its own image Aug 03 02:18:20 I might have.. I just glanced at it though Aug 03 02:18:55 you define SRC_IPK and then it does stuff, but I didn't look at exactly what - it definitely was rebuilding them though Aug 03 02:19:15 it just repacks, not rebuilds. Aug 03 02:19:28 it works on extracted ipk so that it can do things like add control files and the like i think... Aug 03 02:19:29 yeah, sorry, I meant rebuild the package, not the binaries Aug 03 02:19:42 yeah Aug 03 02:19:43 SRC_IPK should be a last resort Aug 03 02:20:10 rwhitby: so shipping binary and packing in build.git is preferred? Aug 03 02:20:15 (as is done presently?) Aug 03 02:20:28 ok, but then in our situation, if we're not building from source in build.git, what's the difference? Aug 03 02:20:44 building from source is preferred Aug 03 02:21:03 fall-back from that is building from source in widk and then packaging the resulting binaries in build.git Aug 03 02:21:08