| 00:02.26 | detule | as totally different as they may be, eb1_clk is being adjusted according to an axi parameter in acpuclock*.c, though you are right the discussion was about eb1_clk not being relevant |
| 00:04.24 | rpierce99 | my 3d graphics are messed up on this, got some vertical bars coming down from the top |
| 00:04.41 | rpierce99 | got me to a 437 though |
| 00:04.50 | arrrghhh | neocore is really messed up |
| 00:04.51 | arrrghhh | lol |
| 00:05.02 | rpierce99 | neocore has always been messed up |
| 00:05.10 | arrrghhh | this is more than usual tho |
| 00:05.10 | rpierce99 | but all 3d is messed up |
| 00:05.17 | arrrghhh | yea |
| 00:05.23 | WisTilt2 | thats with only 10% but i do see something with fb i did that probably mess you guys up |
| 00:05.38 | WisTilt2 | let me leave it at 10% and fix fb and try again. |
| 00:05.44 | arrrghhh | o |
| 00:05.46 | arrrghhh | ok* |
| 00:06.27 | *** join/#htc-linux Ondalf (~ondalf@cable-roi-fffddd00-9.dhcp.inet.fi) |
| 00:08.23 | WisTilt2 | ok try this kernel, sorry bout' that |
| 00:08.27 | arrrghhh | np |
| 00:08.37 | WisTilt2 | im trying to verify this vsync stuff at the same time |
| 00:08.59 | *** join/#htc-linux swc|666 (~gecko@unaffiliated/swc666/x-4934821) |
| 00:10.01 | arrrghhh | kexec'ing now |
| 00:10.59 | detule | jonpry, no go? |
| 00:11.20 | jonpry | hmm. no email? |
| 00:11.43 | detule | oh got em |
| 00:12.25 | detule | brb |
| 00:13.23 | *** join/#htc-linux d3tul3 (~detule@pool-96-234-141-27.bltmmd.east.verizon.net) |
| 00:15.45 | rpierce99 | that fixed the graphics artifacts |
| 00:15.55 | d3tul3 | well it was too much to hope it would apply cleanly |
| 00:16.15 | arrrghhh | hrm |
| 00:16.18 | arrrghhh | i wonder if my SD is bad |
| 00:16.30 | arrrghhh | my phone is still slow from boot... |
| 00:16.50 | arrrghhh | still crap starting up |
| 00:16.51 | WisTilt2 | thats same phone as rpierce99? |
| 00:16.53 | rpierce99 | mine was too, i ran angry birds anyways |
| 00:16.58 | arrrghhh | oh ok |
| 00:16.58 | arrrghhh | lol |
| 00:17.08 | arrrghhh | i'm waiting for it to settle to run neocore. |
| 00:17.16 | rpierce99 | figured i wasn't looking for performance at that point, just the artifacts |
| 00:17.23 | arrrghhh | true dat |
| 00:17.38 | WisTilt2 | yeah it seems to like to settle down for a couple mins. i usually wait 15s or so after i get the green bars |
| 00:17.47 | WisTilt2 | then it flys |
| 00:17.50 | jonpry | d3tul3, your applying against GB? |
| 00:18.01 | arrrghhh | WisTilt2, same |
| 00:18.15 | d3tul3 | jonpry, yes |
| 00:18.20 | arrrghhh | all the missing textures in neocore is kinda entertaining |
| 00:18.23 | jonpry | 2.3.5? |
| 00:18.31 | d3tul3 | .7 |
| 00:18.38 | arrrghhh | i can use my imagination and put stuff in where there's trails of jetpacks etc |
| 00:18.44 | arrrghhh | 28.3fps |
| 00:18.55 | WisTilt2 | arrrghhh:you're still going to be limited to 30fps in neocore til we change this vsync rate. quadrant is probably better to see if you're increasing. |
| 00:19.05 | arrrghhh | ah ok |
| 00:19.09 | arrrghhh | running quadrant now |
| 00:19.17 | WisTilt2 | run quandrant and see if you're around same as pierce |
| 00:19.24 | jonpry | d3tul3, well let me know if its a big deal. maybe just transplant the whole surface flinger |
| 00:19.26 | arrrghhh | i'll just run the 2d and 3d tests in quadrant |
| 00:19.47 | WisTilt2 | run whole thing so you can get the xxx number |
| 00:19.50 | WisTilt2 | to compare |
| 00:20.02 | WisTilt2 | im at 453, pierce went up to 437 from 420 |
| 00:20.14 | rpierce99 | the problem comparing scores is part of this is IO perf, which we all have diff sd cards |
| 00:20.30 | WisTilt2 | thats true. |
| 00:20.37 | arrrghhh | yea, i was hoping to isolate the scores to only 2d/3d perf |
| 00:20.41 | arrrghhh | but you're right |
| 00:20.46 | arrrghhh | then i get a 50 lol |
| 00:20.59 | WisTilt2 | what quadrant you have that lets you do custom benchmarks? |
| 00:21.01 | rpierce99 | 435 on this run |
| 00:21.13 | arrrghhh | some 'advanced' versin |
| 00:21.15 | arrrghhh | serion* |
| 00:21.16 | arrrghhh | damnit |
| 00:21.17 | arrrghhh | yea. |
| 00:21.22 | arrrghhh | advanced. |
| 00:21.53 | arrrghhh | 440 |
| 00:22.30 | arrrghhh | oh |
| 00:22.41 | arrrghhh | you can still see the individual score at the bottom |
| 00:22.45 | arrrghhh | unless that's this stupid advanced version again. |
| 00:23.02 | WisTilt2 | mine only show the bars with devices and score |
| 00:23.08 | arrrghhh | bleh |
| 00:24.24 | arrrghhh | well i guess i can run a bunch |
| 00:24.29 | arrrghhh | and compare to previous kernels |
| 00:24.35 | arrrghhh | see how that particular metric changes |
| 00:26.56 | WisTilt2 | that'll work. im messing with changing vsync atm. |
| 00:27.12 | jonpry | is there a simple way to dump a pmem to file? |
| 00:29.28 | WisTilt2 | setup a buffer file on sdcard and readl/writel should work |
| 00:32.59 | rpierce99 | where do i get the scbs calculation app |
| 00:33.29 | d3tul3 | jonpry can't you go with the file descriptor? |
| 00:33.38 | arrrghhh | it's a binary in the rootfs no? |
| 00:33.44 | arrrghhh | i can't remember. check the scbs thread :P |
| 00:34.00 | rpierce99 | the daemon is, but the apk to actually generate the profile is not, afaik |
| 00:34.31 | arrrghhh | http://www.prymfg.com/kernel/BABS.apk |
| 00:35.45 | rpierce99 | THX |
| 00:35.48 | arrrghhh | np |
| 00:36.54 | jonpry | d3tul3 i was kind of hoping to do it from command line |
| 00:37.04 | jonpry | but that probably will not work |
| 00:37.27 | arrrghhh | hrm |
| 00:37.33 | arrrghhh | SOD with the screen on... |
| 00:37.58 | arrrghhh | i was going to to 10 tests with the gpu oc kernel |
| 00:38.03 | arrrghhh | and 10 tests on the kernel from last night |
| 00:38.08 | arrrghhh | to see if there was any big difference... |
| 00:38.15 | WisTilt2 | what was it doing when it locked up |
| 00:38.24 | arrrghhh | one of the gfx tests |
| 00:38.26 | jonpry | melting down |
| 00:38.30 | arrrghhh | lol, that. |
| 00:38.33 | arrrghhh | it wasn't hot tho |
| 00:38.35 | arrrghhh | oddly enough |
| 00:38.37 | WisTilt2 | damn, thats only 10% oc'd too |
| 00:38.44 | d3tul3 | alright jonpry got the patches in |
| 00:38.50 | jonpry | sweet |
| 00:38.51 | arrrghhh | WisTilt2, i've had it happen before, could be a fluke. |
| 00:38.59 | jonpry | d3tul3, also maybe one other thing i forgot |
| 00:39.38 | d3tul3 | surprisingly it actually built |
| 00:39.42 | d3tul3 | :) |
| 00:40.01 | jonpry | nm its already in |
| 00:41.25 | *** join/#htc-linux MethoS (~clemens@134.102.106.250) |
| 00:46.52 | WisTilt2 | jonpry: these panels only do 70hz max, 50hz minimum |
| 00:49.18 | jonpry | i think its running @60 |
| 00:49.57 | jonpry | the mdp update rate is not really the same thing |
| 00:50.04 | WisTilt2 | it is now yes so i guess best we can get is 35fps at best |
| 00:50.50 | WisTilt2 | ok 20% on gpu1 still working so far |
| 00:52.13 | d3tul3 | jonpry, no bootani blank screen |
| 00:52.28 | jonpry | yeah have to delete /system/bin/bootani |
| 00:52.33 | jonpry | all 3d apps will blow up |
| 00:53.08 | d3tul3 | should i reboot or will this recover back to the home screen |
| 00:53.13 | arrrghhh | lol |
| 00:53.16 | arrrghhh | maybe i should do 20 tests |
| 00:53.30 | arrrghhh | these numbers are all over the place, and all i'm doing is rerunning the test over&over |
| 00:53.33 | jonpry | if you delete the animation and kill system_server it might recover |
| 00:56.00 | jonpry | i did some performance testing and this external texture thing is killing it. pixel flinger is faster than the hardware renderer if we have to use gltexsubimage |
| 00:59.42 | arrrghhh | ok, going to back to the mem OC kernel only to compare. |
| 00:59.50 | arrrghhh | perhaps i should go back to .27 vanilla and compare :D |
| 01:04.01 | *** join/#htc-linux bzo (~chatzilla@c-174-62-79-238.hsd1.ca.comcast.net) |
| 01:04.02 | WisTilt2 | .27 would be a good test too |
| 01:05.34 | bzo | WisTilt2: the OC code in .39 works fine, I've been running 768mhz the whole time |
| 01:06.26 | arrrghhh | imma make a google doc outta this to make sense of it all |
| 01:06.28 | WisTilt2 | really? it might be my config then |
| 01:06.32 | arrrghhh | bzo, is that with a different command tho? |
| 01:06.53 | bzo | yeah, in .39 it's slightly different |
| 01:06.57 | WisTilt2 | or maybe i dont have the right cmd in startup, have same as .27 and never changed it |
| 01:07.08 | arrrghhh | yea, i'm thinking that's it |
| 01:07.11 | arrrghhh | the OC command changed |
| 01:07.24 | d3tul3 | the file name changed |
| 01:07.27 | arrrghhh | or that |
| 01:07.35 | arrrghhh | did that change the actual command detule ? |
| 01:07.38 | arrrghhh | er d3tul3 |
| 01:07.39 | bzo | acpuclock-arm11.oc_freq_khz=xxx |
| 01:07.50 | WisTilt2 | lol, never even looked at it. |
| 01:08.12 | bzo | this probably explains why I'm the only one that ran into the mdelay/udelay OC bug that I recently pushed |
| 01:08.22 | arrrghhh | lol bzo |
| 01:08.23 | arrrghhh | that's awesome. |
| 01:08.46 | bzo | I thought it was weird no one else was having SODs on .39 |
| 01:09.10 | arrrghhh | no one else was overclocking, properly or otherwise :P |
| 01:09.19 | bzo | It's only taken me like a week, but I'm finally back to a stable running config |
| 01:09.50 | bzo | at one point I was almost thinking my phone had a hardware problem |
| 01:10.29 | d3tul3 | jonpry, it's up and running...though er wouldn't call it running really |
| 01:10.32 | arrrghhh | well first test seems to indicate gpu OC didn't do anything.... |
| 01:10.42 | jonpry | d3tul3, whats wrong with it? |
| 01:10.56 | d3tul3 | screen is messing up in all sort of ways, perhaps i patched this wrong |
| 01:11.08 | jonpry | try opening and closing the settings app |
| 01:11.21 | jonpry | the buffers get switched around |
| 01:11.41 | jonpry | and that fixes it 9 times out of 10 |
| 01:11.59 | d3tul3 | can't unblank the screen |
| 01:12.15 | jonpry | yeah can't let it blank or its over |
| 01:12.38 | jonpry | eventually system server will restart itself though |
| 01:12.41 | arrrghhh | lol |
| 01:12.46 | arrrghhh | that's what kept happening to me |
| 01:12.52 | arrrghhh | system server does eventually restart d3tul3 |
| 01:14.06 | bzo | d3tul3: are you just cherry pick commits to sync up .39/3.x? |
| 01:15.15 | d3tul3 | bzo, at this point yes, they are pretty much in chronological sync, so only the top few commits are missing at a time |
| 01:15.49 | d3tul3 | (except that in 3.0 there was an extra patch required to silence certain scbs related WARNs) |
| 01:16.04 | bzo | ok, was going to fix that acpuclock bug in 3.0 and wanted to see if there was a better way than that |
| 01:16.23 | d3tul3 | if you wish i can merge that into 3.0 with whatever the top commits that missing from .39 are |
| 01:16.39 | bzo | sure, if you're going to do so anyways |
| 01:17.13 | bzo | blech, 3.0 still has that annoying extra checked in files problem that was fixed in .39 |
| 01:17.30 | d3tul3 | yeah i have it merged locally i just wanted a change to run 3.0 with it for a big, i had one or two occasions where the screen power-on didn't work while usb was plugged in, not sure if it was pathological or something from the recent commits |
| 01:17.38 | d3tul3 | s/change/chance/ |
| 01:17.59 | bzo | are you actively keeping 3.1 up to date as well? |
| 01:18.15 | d3tul3 | no 3.1 is missing some commits outside of /mach-msm |
| 01:18.25 | d3tul3 | in particular sdio core and evdev (jonpry has a much better idea) |
| 01:18.32 | d3tul3 | also wifi |
| 01:19.04 | jonpry | and /proc oom permission thing |
| 01:19.09 | d3tul3 | after those it's missing everything recent |
| 01:19.16 | bzo | I may go back to 3.0 this week now that I seem to up and running reasonably again |
| 01:19.57 | bzo | btw, I do suspect that the bma150 is sucking power with the sensor enabled gb |
| 01:20.10 | bzo | just did a back to back run, and I'm losing an extra percent or more an hour of batt |
| 01:20.15 | d3tul3 | jonpry, can't explain it it's unusable |
| 01:20.58 | arrrghhh | WisTilt2, 2d was slightly lower and 3d was slightly higher on the non-GPU OC kernel... |
| 01:21.08 | arrrghhh | i'm thinking that's pretty inconclusive and would probably wash out over lots of tests. |
| 01:21.13 | arrrghhh | 10% is pretty small too |
| 01:21.22 | arrrghhh | lemme try .27 then if you have the 20% one ready i'll give it a whirl |
| 01:21.42 | WisTilt2 | 3d is lower on the oc'd one? |
| 01:21.51 | arrrghhh | yea, makes no sense. |
| 01:22.05 | arrrghhh | the avg is 4.5 points higher on the non-OC'd one. |
| 01:22.24 | arrrghhh | but the deviation was pretty big |
| 01:22.31 | arrrghhh | from 173-195 on the non-OC |
| 01:22.40 | jonpry | d3tul3, i dunno. it's definitely very quirky on mine. but i can use it for sure |
| 01:22.41 | arrrghhh | and 173-195 on the OC lol |
| 01:22.57 | WisTilt2 | unless i did the math wrong that cant be right |
| 01:23.06 | d3tul3 | i probably patched this wrong i see a lot of these E/SurfaceFlinger( 1420): BufferManager: initEglImage |
| 01:23.20 | jonpry | thats ok |
| 01:23.26 | jonpry | well not too many is ok |
| 01:23.31 | d3tul3 | here's the patebin http://pastebin.com/qeug8pAz |
| 01:24.37 | jonpry | yeah thats too many |
| 01:24.52 | jonpry | i think its caused by running out of gpu memory |
| 01:25.52 | jonpry | you don't have one of those 1mb gpu0 setups? |
| 01:27.13 | d3tul3 | here's my pmem http://pastebin.com/5jxrsWXt |
| 01:28.21 | jonpry | that doesn't show gpu0 |
| 01:29.42 | jonpry | should i upload my cm build or something? |
| 01:31.33 | d3tul3 | i am on a slow internet conenction that will likely take up the rest of the night... |
| 01:31.57 | *** join/#htc-linux Sand_away (~Sandvold@207.80-202-111.nextgentel.com) |
| 01:32.03 | jonpry | it sometimes takes me 3 or 4 surface flinger starts before it will work. high quality software here |
| 01:32.40 | d3tul3 | it's at a point here where the screen doesn't register any touches |
| 01:32.58 | jonpry | yeah thats usually system_server restarting everything |
| 01:33.17 | jonpry | thats what i have to go through several times |
| 01:33.56 | jonpry | i think it depends on the goal here. like if you want to hack on it. then we will make it work :p. i'm already fairly certain it will be slow |
| 01:35.54 | d3tul3 | 'ts ok my contribution here is marginal at the very best |
| 01:36.07 | arrrghhh | uhm |
| 01:36.21 | arrrghhh | WisTilt2, don't be mad but my first quadrant test on .27 was... really good. |
| 01:36.36 | arrrghhh | like 10pts higher |
| 01:37.09 | WisTilt2 | mad? lol. i may setting our gpu the other way if its lower like that |
| 01:37.19 | arrrghhh | this is just odd |
| 01:37.23 | arrrghhh | it's getting higher... |
| 01:37.32 | WisTilt2 | is the test you're doing just testing 3d |
| 01:37.42 | arrrghhh | 2d/3d |
| 01:37.46 | arrrghhh | wow |
| 01:37.51 | arrrghhh | 2d i just got 140 on .27 |
| 01:38.04 | arrrghhh | i didn't get over 80 on .39 |
| 01:38.30 | arrrghhh | should i ignore 2d testing? |
| 01:38.36 | arrrghhh | this is very strange. |
| 01:38.49 | jonpry | is there a cpu test? |
| 01:38.51 | arrrghhh | i almost want to do a full set of benchmarks comparing |
| 01:38.53 | arrrghhh | jonpry, indeed |
| 01:39.09 | arrrghhh | right now i'm doing a custom benchmark, only checking 2d and 3d |
| 01:39.11 | WisTilt2 | thats odd. let me put that app on mine and try it to see what i get on .39, then ill look over my method on gpu1 for errors, which we obviously have it seems |
| 01:39.17 | jonpry | need that for these ram clocks |
| 01:39.30 | arrrghhh | WisTilt2, you want me to share this google doc with you? |
| 01:39.38 | WisTilt2 | which is that? |
| 01:39.59 | arrrghhh | i'm just putting down and averaging all these benchmarks i'm taking |
| 01:40.08 | arrrghhh | just punching in numbers and letting it do the work basically |
| 01:40.25 | bzo | arrrghhh: you don't have the OC enabled on .27 right? |
| 01:40.34 | arrrghhh | oh shoot |
| 01:40.43 | arrrghhh | i probably still have that in my startup. that's not fair. |
| 01:41.06 | WisTilt2 | bzo does oc just turn up cpu, ahb and axi or what? |
| 01:41.08 | arrrghhh | which the 10% GPU OC kernel is overclocked to 614 |
| 01:41.09 | arrrghhh | lol |
| 01:41.32 | bzo | just have both acpuclock.oc_freq_khz and acpuclock-arm11.oc_freq_khz set and it will work in both |
| 01:41.39 | arrrghhh | bzo, awesome |
| 01:41.46 | bzo | WisTilt2: it turns up pll2, so anything connected to that... |
| 01:42.07 | bzo | I believe it's only the cpu clock though |
| 01:42.43 | arrrghhh | well i might as well run these all at 614 |
| 01:42.48 | arrrghhh | er |
| 01:43.05 | bzo | arrrghhh: that is if WisTilt2 didn't disable the OC code in his latest kernels |
| 01:43.07 | arrrghhh | crap... nvm. if oc works, it'll work in any kernel. unless did you hardcode it in that test kernel with 10% OC WisTilt2 ? |
| 01:43.13 | arrrghhh | lol |
| 01:43.40 | WisTilt2 | yes, because i have this test kernel locked at 614400 max but dont know what it will do if you also have oc'ing enabled. i pretty much removed most of the clock stuff and put ours in but no telling. |
| 01:43.54 | arrrghhh | oh... |
| 01:43.58 | arrrghhh | hrm |
| 01:44.13 | arrrghhh | i'll just have to check to see if the OC works when i flip back to .39 |
| 01:44.16 | bzo | arrrghhh: in that case, I suppose you should set both params to 614400 and it should all be teh same regardless |
| 01:44.32 | arrrghhh | bzo, yea i was thinking that too. gotta redo all but one then... oh well. |
| 01:44.34 | WisTilt2 | i think i have any of the regular oc stuff gone for these tests anyway so just set your .27 tests to 614400 |
| 01:44.53 | arrrghhh | sounds good |
| 01:45.40 | *** join/#htc-linux hardwalker (~hardwalke@122-117-115-146.HINET-IP.hinet.net) |
| 01:45.55 | bzo | WisTilt2 and d3tul3 : I think we are going to have to go through the 27 commits since 39 was forked |
| 01:46.10 | bzo | given that the acpuclock fix was missing, and Wis noticed the panel code was old |
| 01:47.14 | WisTilt2 | hopefully anything else missed was bad anyway:) |
| 01:47.20 | arrrghhh | lol |
| 01:47.22 | WisTilt2 | .39 is running so nice |
| 01:48.00 | bzo | yeah, aside from the OC hangs that are now gone, it's running great |
| 01:48.16 | bzo | though I think the 27 kernel is better on power right now, but that may be just from the panel code |
| 01:48.17 | WisTilt2 | bzo you did that udelay fix a long time ago iirc. it is odd that its missing along with the panel stuff, which i did myself |
| 01:48.51 | bzo | jonpry did fork 39 quite a while ago |
| 01:49.10 | bzo | well by fork I mean copy over the existing 27 stuff at the time, hehe |
| 01:49.12 | WisTilt2 | im .8% hr in sleep everyday |
| 01:49.35 | bzo | haven't done much better than 3%, think I was under 2% with 27 |
| 01:50.08 | rpierce99 | generated my battery profile :) |
| 01:50.22 | d3tul3 | 39 initial commit May 8, 27 acpuclock fix May 13 |
| 01:50.23 | WisTilt2 | you want to try this test kernel with the memory oc'ing and compare? be interested if it drops to 1% or better |
| 01:51.32 | bzo | WisTilt2: maybe later, I'm trying to figure out if the gsensor is sucking power right now |
| 01:52.39 | WisTilt2 | bzo i haven't added it yet but did you see [acl]'s gpio find for the gsm gsensor? i have the bma150 disabled in my kernel but need to add that gpio and turn it back on. |
| 01:53.17 | bzo | I'll be interested to know if you see the power drain also |
| 01:53.29 | d3tul3 | isn't acl's gpio find related to capella not bma? |
| 01:53.40 | bzo | that may be only on the new gingerbread build though, it has a new userland driver |
| 01:53.47 | WisTilt2 | yes, dont know what im thinking:) |
| 01:54.09 | WisTilt2 | d3tul3^^ |
| 01:54.46 | d3tul3 | that userland driver looks like a carbon copy of most of the bma stuff in froyo/sensors but perhaps something is different after all |
| 01:55.09 | d3tul3 | bzo, if you turn off auto-rotate in settings, do you still see the g-sensor being activated in logcat |
| 01:55.32 | WisTilt2 | i do have gsensor disabled though still along with prox via the variant |
| 01:55.58 | d3tul3 | the kernel side gsensor driver is unchanged from 27 |
| 01:56.39 | d3tul3 | though emwe found an actually BOSCH oem driver that he is using in .35 |
| 01:57.11 | d3tul3 | it migth be worth looking into, since there's quite a few hacks in the current bma driver |
| 01:57.38 | bzo | d3tul3: yeah, turning off auto-rotate stops orientation msgs in logcat |
| 01:57.51 | bzo | though would need some more debugging to see if it actually gets turned off |
| 01:57.57 | WisTilt2 | rpierce99 which dataset did you use, one of your most recent older ones? |
| 01:58.09 | bzo | d3tul3: agreed, maybe we should switch drivers to begin with |
| 01:58.20 | rpierce99 | i had one that was like 1.7mb from a few months ago, haven't taken any recently |
| 01:58.22 | arrrghhh | i'm still getting higher scores in 2d on .27 |
| 01:58.36 | WisTilt2 | that should be close enough for a good model to start with |
| 01:58.50 | WisTilt2 | how much higher arrrghhh? |
| 01:58.53 | arrrghhh | we'll see how it averages out |
| 01:58.57 | bzo | bbl |
| 01:59.07 | arrrghhh | WisTilt2, almost double |
| 01:59.21 | WisTilt2 | wow |
| 01:59.43 | WisTilt2 | let me look over this code again |
| 01:59.48 | arrrghhh | 3D, not so much |
| 01:59.54 | arrrghhh | we'll see how this pans out overall tho |
| 02:00.08 | WisTilt2 | 2d i dont care about:) thats not from gpu1 |
| 02:00.14 | arrrghhh | lol |
| 02:00.15 | arrrghhh | i see |
| 02:00.22 | WisTilt2 | i havent touch that gpu |
| 02:00.41 | arrrghhh | hrm |
| 02:00.47 | arrrghhh | i wonder if doing this plugged in helps |
| 02:01.38 | WisTilt2 | shouldnt matter |
| 02:01.57 | *** join/#htc-linux EdLin (~EdLin@securabit/listener/edlin) |
| 02:05.13 | arrrghhh | WisTilt2, i'm really curious if these two metrics are higher on your fandangled GSM device. |
| 02:05.35 | arrrghhh | i need to redo the mem OC only tab |
| 02:05.48 | arrrghhh | but the 10% GPU OC kernel already had the 614 set... |
| 02:05.59 | WisTilt2 | im moving that app on it now to test it |
| 02:06.03 | arrrghhh | np |
| 02:06.29 | arrrghhh | adb install is nice ;) |
| 02:06.38 | arrrghhh | i always forget about it |
| 02:13.58 | d3tul3 | you fella's know if we have ever mapped the g-sensor power on/off gpios? |
| 02:17.59 | arrrghhh | WisTilt2, 3d avg is 15 points higher |
| 02:18.25 | arrrghhh | 2d is... yea. almost double... 63 points higher. |
| 02:18.37 | arrrghhh | ^^ in .27 |
| 02:22.10 | WisTilt2 | ok sorry, had an issue to deal with in the backyard with our cats |
| 02:22.18 | arrrghhh | lol |
| 02:22.23 | arrrghhh | got some puma's roamin around? |
| 02:22.32 | WisTilt2 | arrrghhh: 2d=76 3d=188 is what i got |
| 02:22.56 | arrrghhh | yea, that's about what i was getting on .39 with the 10% GPU OC |
| 02:23.04 | arrrghhh | are you on 20%? |
| 02:23.04 | WisTilt2 | lol, just some wild cat made it in trying to steal our cats food. 3 cats all 18yrs old now |
| 02:23.14 | arrrghhh | heh |
| 02:23.29 | WisTilt2 | i tested that on same kernel as you to compare |
| 02:23.33 | arrrghhh | yea your 3d score was a little higher |
| 02:23.40 | arrrghhh | my avg 3d score on .39 was 180 |
| 02:23.44 | arrrghhh | highest was 195 |
| 02:23.53 | arrrghhh | what's weird is on .27 |
| 02:23.58 | arrrghhh | 3d was 195 avg |
| 02:24.12 | arrrghhh | but the lowest? 192. highest was 198 |
| 02:24.59 | WisTilt2 | ok let me make another kernel with the gpu oc changes gone so only the memory oc stuff left and see if it changes |
| 02:25.08 | arrrghhh | ok |
| 02:25.12 | arrrghhh | i tested with the mem OC only |
| 02:25.17 | arrrghhh | but that was 528 cpu |
| 02:25.23 | arrrghhh | so the numbers... aren't accurate |
| 02:25.32 | WisTilt2 | did 3d numbers get lower? |
| 02:25.36 | d3tul3 | for what is worth stock .39 scores better than .27 in neocore in froyo |
| 02:25.36 | arrrghhh | and i g2g to the store right now, can't pull new numbers. will be back soon |
| 02:25.38 | arrrghhh | WisTilt2, yes |
| 02:25.43 | arrrghhh | er |
| 02:25.46 | arrrghhh | no? |
| 02:25.47 | arrrghhh | wtf |
| 02:25.56 | arrrghhh | avg 3d was 184 on mem OC only |
| 02:25.57 | WisTilt2 | ok arrrghhh ill be on a few more hours |
| 02:26.08 | arrrghhh | sounds good |
| 02:26.21 | arrrghhh | i'll take some more tests |
| 02:26.28 | WisTilt2 | thanks |
| 02:26.34 | arrrghhh | with everything as equal as i can get it... |
| 02:26.35 | d3tul3 | at least i know my .39 neocore was 20.1, and i don't ever recall scoring that high witth .27 |
| 02:26.35 | arrrghhh | np |
| 02:27.02 | WisTilt2 | d3tul3 you get 20fps on neocore on .39? |
| 02:27.16 | arrrghhh | i assume on froyo |
| 02:28.12 | WisTilt2 | if he's lower than 30 in gb that would be a good way to see if we're going anywhere with this or now since it should be higher with oc'd gpu1 |
| 02:29.00 | arrrghhh | hrm |
| 02:29.05 | arrrghhh | i should probably do this on a fresh data.img |
| 02:29.09 | arrrghhh | with only quadrant installed |
| 02:29.10 | arrrghhh | damnit. |
| 02:33.13 | *** join/#htc-linux Bry8Star (~Bry8Star@gateway/tor-sasl/bry8star) |
| 02:36.39 | d3tul3 | WisTilt2, 20 in froyo, in gb with no textures 28-29 |
| 02:37.52 | d3tul3 | also i am not sure if arrrghhh and rpierce99 are testing with a reduced pmem pool down to 16MB, gralloc requisitions the entire pmem pool it seems when 3d is running, so perhaps this is somehow skewing the results |
| 02:39.54 | WisTilt2 | thats possible... i have pmem pool at 16mb right now so probably need to go back to 32 and test again |
| 02:40.25 | jonpry | so i create a texture. then download all the memory. can't find it anywhere dur |
| 02:48.13 | d3tul3 | bzo, 3.0 caught up |
| 03:00.41 | *** join/#htc-linux FlawlesStyle (~LOL@unaffiliated/flawlesstyle) |
| 03:07.43 | toastcfh | jonpry, hows progress going? |
| 03:08.44 | jonpry | i'm working on gingerbread trying to get the hardware composition going |
| 03:08.51 | jonpry | i have something. just need to make it faster |
| 03:08.53 | toastcfh | ahh |
| 03:09.09 | toastcfh | sf_bypass? |
| 03:09.12 | toastcfh | in gb? |
| 03:09.24 | toastcfh | i got that working on7x30 and 8x60 |
| 03:09.35 | arrrghhh | WisTilt2, very strange overall. .27 "feels" slower overall. 2d/3d numbers don't agree, but i'm not comparing anything else ATM. |
| 03:09.37 | jonpry | i don't know what that is |
| 03:09.39 | toastcfh | think 7k does it too |
| 03:11.07 | d3tul3 | arrrghhh, try .39 straight from the autobuild |
| 03:11.13 | toastcfh | guess im gonna try and figure out the Unable to dequeue native buffer issue with gl |
| 03:11.20 | arrrghhh | d3tul3, good idea |
| 03:11.26 | d3tul3 | should give us a baseline |
| 03:11.37 | arrrghhh | wow |
| 03:11.47 | jonpry | toastcfh i'm pretty sure that is caused by not having the external texture extension |
| 03:11.48 | arrrghhh | glemsom's hasn't built anything usable in a while. |
| 03:11.49 | arrrghhh | lol |
| 03:12.04 | jonpry | GL_TEXTURE_EXTERNAL_OES |
| 03:12.10 | toastcfh | jonpry, but ive nuked all that |
| 03:12.21 | jonpry | sort of. you nuked it in glBindTexture |
| 03:12.25 | toastcfh | just change it to the old |
| 03:12.40 | jonpry | but the stuff that creates it EGLImage, and then attempts to load it is not nooked |
| 03:12.46 | jonpry | nuked |
| 03:12.52 | arrrghhh | hrm |
| 03:12.59 | arrrghhh | i don't think i'll be able to kexec from .27 |
| 03:13.00 | arrrghhh | sad |
| 03:15.10 | toastcfh | jonpry, i mean i redefined it |
| 03:15.29 | toastcfh | its not 0x8D65 anymore |
| 03:15.51 | jonpry | yeah i know about the patch. you made GL_TEXTURE_EXTERNAL = GL_TEXTURE_2D |
| 03:16.00 | toastcfh | right |
| 03:16.28 | jonpry | but it doesn't do anything for the calls to glEGLImageTargetTexture2DOES |
| 03:16.44 | jonpry | or eglCreateImageKHR |
| 03:17.29 | jonpry | its really a miracle it works at all |
| 03:18.35 | jonpry | in gb flinger there is reference code on how to deal with lack of those extensions, but its slololo |
| 03:19.12 | toastcfh | lol what stubs |
| 03:22.20 | *** join/#htc-linux detule (~oliver@pool-96-234-141-27.bltmmd.east.verizon.net) |
| 03:22.33 | d3tul3 | er what's he doing here |
| 03:22.54 | arrrghhh | raping and pillaging, obviously. |
| 03:23.08 | toastcfh | jonpry, my gl supports those so idk |
| 03:23.37 | jonpry | if it supports those then GL_TEXTURE_EXTERNAL would work |
| 03:23.41 | jonpry | its all the same thing |
| 03:24.02 | *** join/#htc-linux Azuske|AFK (412036af@gateway/web/freenode/ip.65.32.54.175) |
| 03:24.06 | toastcfh | heh well it works. just something else is dering |
| 03:24.36 | toastcfh | been looking through the new elg blob thats throwing the error |
| 03:24.40 | toastcfh | in ida |
| 03:24.46 | Azuske|AFK | who are the HTC Linux devs |
| 03:25.20 | toastcfh | none they all rage quit ;/ |
| 03:26.34 | jonpry | fakker mostly |
| 03:27.38 | jonpry | and tiad8 |
| 03:28.10 | d3tul3 | i wasn't aware he's htc only |
| 03:28.29 | jonpry | lol |
| 03:28.45 | jonpry | toastcfh, isn't that error coming from SurfaceTexture.cpp? |
| 03:29.45 | toastcfh | no |
| 03:30.11 | toastcfh | E/Adreno200-EGLSUB( 333): SwapBuffers() Unable to dequeue native buffer |
| 03:30.25 | toastcfh | its coming from this new egl blob |
| 03:31.31 | jonpry | they change the NativeWindow prototype? |
| 03:31.44 | d3tul3 | arrrghhh, you got that autobuild kernel churning |
| 03:32.24 | toastcfh | well they are from HC 3.2 so thats like october so.... it should be right |
| 03:32.54 | arrrghhh | d3tul3, yea it's settled i think... doing testing now |
| 03:32.56 | toastcfh | id think if it was wrong it wouldnt work at all |
| 03:34.23 | jonpry | well who implements that? FrameBufferNativeWindow.cpp? |
| 03:34.48 | toastcfh | yeah the "name" has changed but its the same shit |
| 03:35.23 | jonpry | does it enter dequeueBuffer right before it fails to deqeue? |
| 03:36.26 | toastcfh | idk i havent got that far into debugging. mainly just seeing how it works. guess i could throw a line in to see |
| 03:37.17 | jonpry | i think the blob just wants somebody to return zero after it hopefully jumps somewhere |
| 03:37.35 | toastcfh | hehe |
| 03:37.46 | jonpry | if its working it must be hitting that |
| 03:38.49 | jonpry | strangely i am the only one not getting those errors |
| 03:40.43 | arrrghhh | WisTilt2, in case you're curious, the numbers are on-going ;) |
| 03:40.43 | arrrghhh | https://docs.google.com/spreadsheet/ccc?key=0AvCpm2u2mcfBdEFGVlNxcW44M2xTVDVXRkxGQW1sYkE |
| 03:41.33 | toastcfh | <PROTECTED> |
| 03:41.48 | toastcfh | looks like an issue waiting to happen |
| 03:45.35 | jonpry | arrrghhh, is that just a single kernel? |
| 03:45.40 | arrrghhh | no |
| 03:45.45 | arrrghhh | each tab is a different kernel |
| 03:45.54 | arrrghhh | i guess i need to be more descriptive in the tabs |
| 03:45.58 | WisTilt2 | arrrghhh: with gpu oc off my total is 458, 2d 76, 3d 192 |
| 03:46.04 | arrrghhh | .27 is 'vanilla' .27 acoustic |
| 03:46.04 | WisTilt2 | sorry was eating dinner |
| 03:46.15 | arrrghhh | .39 is vanilla .39 from 11/23 |
| 03:46.22 | arrrghhh | mem OC only is a test .39 kernel from wistilt2 |
| 03:46.32 | arrrghhh | and 10% gpu oc is another .39 test kernel from WisTilt2 |
| 03:46.42 | arrrghhh | Willd, np. hrm. |
| 03:46.42 | WisTilt2 | what you get on the memory only test? |
| 03:46.50 | d3tul3 | i think .27 vs .39 comparisons are probably somewhat useless because of the different clock structure, probably the relevant tabs are .39 vs .39 oc'ed |
| 03:46.50 | arrrghhh | i need to redo that one. |
| 03:47.02 | arrrghhh | WisTilt2, i originally tested that one without OC |
| 03:47.31 | WisTilt2 | mem on mine is 172, dont know what the baseline is with oc though |
| 03:47.34 | jonpry | looks like 39 is getting taken for a ride |
| 03:47.42 | arrrghhh | lol |
| 03:47.57 | arrrghhh | d3tul3, i think it's still an interesting distinction tho |
| 03:48.04 | arrrghhh | i'm not comparing anything else. just 2d/3d. |
| 03:48.09 | WisTilt2 | as fast as .39 is right now i cant believe the numbers are lower than .27 |
| 03:48.13 | arrrghhh | other metrics might be different. perhaps i need to add more columns lol |
| 03:48.19 | jonpry | obviously we need to engage in benchmark optimization |
| 03:48.23 | d3tul3 | not really, because of the different clock structre different tests i feel like will favor the different kernels |
| 03:48.38 | WisTilt2 | no kernel have i ever run that opens apps and has such fast response |
| 03:48.52 | arrrghhh | WisTilt2, yea i need to get back on the mem OC kernel |
| 03:48.59 | arrrghhh | do you know the timestamp on the highest one there? |
| 03:49.05 | arrrghhh | did you settle on 35%? |
| 03:49.13 | WisTilt2 | let me upload one without anything on the gpu, just 35% memory |
| 03:49.21 | arrrghhh | ok |
| 03:49.26 | d3tul3 | hah benchmark optimization |
| 03:49.28 | arrrghhh | i should label these |
| 03:49.33 | WisTilt2 | also d3tul3 i added pmem back to 32 and it looks like it may have helped |
| 03:50.06 | arrrghhh | d3tul3, well in theory it'll make for the best 2d/3d performance... but yea, i've always wondered about these benchmark tools. there's ways to trick 'em, obviously. |
| 03:50.16 | WisTilt2 | arrrghhh kernel is up |
| 03:50.18 | arrrghhh | k |
| 03:50.20 | d3tul3 | question is, are those 16MB more useful in the pool for the occasional 3d boost, or in ram where they might get used more often |
| 03:50.37 | WisTilt2 | d3tul3 im thinking yes from the way it looks |
| 03:50.54 | d3tul3 | :) that was not a yes/no question :) |
| 03:51.00 | arrrghhh | d3tul3, yea, and benchmarks are completely useless for real world tests... indeed :P |
| 03:51.31 | Azuske|AFK | Last warning |
| 03:51.38 | d3tul3 | oO |
| 03:51.41 | Azuske|AFK | woops wrong place |
| 03:51.41 | jonpry | pmem pool isn't for 3d |
| 03:51.43 | Azuske|AFK | sorry |
| 03:51.44 | arrrghhh | lol |
| 03:51.47 | d3tul3 | damnit jonpry |
| 03:51.53 | WisTilt2 | i think more ram would be better but even with pmem at 32, less ram now its still crazy fast |
| 03:52.04 | jonpry | :D |
| 03:52.04 | d3tul3 | what is gralloc using it for |
| 03:52.15 | jonpry | 2d android surfaces |
| 03:52.23 | jonpry | bitmaps or widgets, whatever |
| 03:52.25 | d3tul3 | oh there you go, i was close enough |
| 03:52.27 | d3tul3 | lol |
| 03:52.34 | toastcfh | jonpry, pretty strang shit |
| 03:52.38 | toastcfh | http://pastebin.com/cTDWhXe8 |
| 03:52.56 | toastcfh | so it is able to do it |
| 03:53.04 | toastcfh | it just errors anyow |
| 03:53.06 | toastcfh | ;/ |
| 03:53.14 | toastcfh | maybe the bish needs time |
| 03:53.33 | d3tul3 | ok so the 16MB in the pmem pool are more impotant than just "the ocasional 3d boost" |
| 03:53.52 | jonpry | toastcfh, it looks like it starts being able to do it? |
| 03:54.26 | jonpry | d3tul3, there is only so many apps we can keep resident on this little machine |
| 03:54.36 | toastcfh | jonpry, it gives the error then it goes throiugh with it anyhow |
| 03:54.51 | toastcfh | jonpry, i used LOGE out of lazyness |
| 03:55.08 | jonpry | isn't that like 16 deqeues that worked and only 1 failure? |
| 03:55.38 | toastcfh | i see no failure cept by the blob |
| 03:55.58 | jonpry | right |
| 03:56.01 | toastcfh | the blob is bitchign but going through with it anyhow |
| 03:56.23 | toastcfh | might be a race |
| 03:56.28 | toastcfh | sec |
| 03:56.35 | jonpry | on another note. those things have different PID |
| 03:56.37 | toastcfh | lock it a little |
| 03:56.53 | jonpry | guessing flinger is 138 |
| 03:57.08 | jonpry | 349 must be some other app trying to use 3d |
| 04:00.33 | toastcfh | app_30 349 139 272272 35412 ffffffff 00000000 S com.android.noisefield |
| 04:00.56 | jonpry | sounds important |
| 04:01.01 | toastcfh | hehe |
| 04:01.16 | d3tul3 | WisTilt2, by the way, not sure if your pm adjustments have anything to do with it, but I think you may have inadvertently helped alleviate the gp_timer issue....couple of times now i've been in a situation where i've tried to power off the screen and I notice the phone goes through this slow-mo screen power off sequence as if in a timer slow-down, but then at some point after the screen is off it actually manages to suspend ( |
| 04:01.16 | d3tul3 | green light) and upon resume everything is a-ok....it never managed to properly suspend during a slowdown before |
| 04:02.08 | toastcfh | and yeah flinger |
| 04:02.11 | toastcfh | system 138 1 96472 9756 ffffffff 00000000 S /system/bin/surfaceflinger |
| 04:02.39 | toastcfh | so its failing before it gets there |
| 04:03.28 | jonpry | deqeue is implemented by somebody else then |
| 04:03.35 | toastcfh | flinger is just taking over cuz of its fail |
| 04:04.59 | jonpry | probably SurfaceTexture |
| 04:05.31 | jonpry | or SurfaceTexture_client |
| 04:07.05 | WisTilt2 | d3tul3: that reminds me, there is another fix for pm i need to push. no telling what in pm would be fixing that slow down on power up again. i havent seen any slowdown for so long now. |
| 04:07.44 | WisTilt2 | or did i already push that? was a fix in sleep2 |
| 04:09.03 | d3tul3 | no idea i am just running my mouth here nothing scientific in all of this k i am out later everyone |
| 04:09.35 | arrrghhh | alright food tiem. moar #'s later |
| 04:09.43 | WisTilt2 | looks like that fix went in with the idle suspend/collapse commit so maybe that's what did it. |
| 04:15.22 | toastcfh | jonpry, hehe #define ALLOW_DEQUEUE_CURRENT_BUFFER false |
| 04:15.25 | toastcfh | lol |
| 04:15.32 | toastcfh | changes it |
| 04:15.40 | jonpry | hmm |
| 04:15.52 | toastcfh | in surfacetexture |
| 04:16.45 | *** join/#htc-linux rpierce99 (~rpierce99@96-42-102-103.dhcp.stcd.mn.charter.com) |
| 04:16.49 | jonpry | i really wish we did not have blobs |
| 04:19.37 | toastcfh | heh interesting result |
| 04:20.27 | toastcfh | no change cept it would give the error and only spam 8 of my messages between errors instead of 16 |
| 04:20.49 | *** join/#htc-linux rajkosto (~rajkosto@2001:470:d76b:da7a:4d12:e4cd:f00c:c899) |
| 04:21.04 | jonpry | i'm not sure if thats an improvement :p |
| 04:21.32 | toastcfh | lol |
| 04:21.35 | toastcfh | me either |
| 04:21.39 | toastcfh | but interesting |
| 04:54.31 | *** join/#htc-linux Rob2223 (~Miranda@p4FFF0387.dip.t-dialin.net) |
| 05:00.12 | *** join/#htc-linux GNUtoo (~gnutoo@host40-58-dynamic.116-80-r.retail.telecomitalia.it) |
| 05:16.38 | arrrghhh | WisTilt2, got some more numbers. was the memory overclocked in that 10% GPU OC kernel? |
| 05:17.33 | *** part/#htc-linux Azuske (412036af@gateway/web/freenode/ip.65.32.54.175) |
| 05:17.36 | WisTilt2 | the last one has gpu oc removed. i found some interesting things looking at this acpuclock oc'ing code. we could be wasting time here |
| 05:18.27 | WisTilt2 | if i follow this right it looks like when you set oc both the cpu and ebi memory get clocks increased. only thing that doesnt is smi memory and gpu's |
| 05:19.28 | arrrghhh | ah |
| 05:21.11 | WisTilt2 | if you take the stock .39 autobuild kernel and set oc to 614400 or whatever, you should see everything benchmark better except gpus, although if 2d goes up then smi is also clocking higher |
| 05:21.58 | WisTilt2 | haven't tried that but i bet thats what it will do. im still figuring out how this code works to see if we need to just move on to gpu1 |
| 05:22.16 | arrrghhh | ok |
| 05:27.40 | WisTilt2 | bah. well smi is also getting oc'd and since gpu0 is in smi it also is so you should see 2d scores higher. i do see 1 change we need to make to speed it up even more when oc'd though. check the stock one and ill make a change and you can compare to see if memory speed goes up even more. |
| 05:28.02 | arrrghhh | ok |
| 05:28.09 | arrrghhh | i'll add cpu and memory metrics to the table |
| 05:28.31 | WisTilt2 | k. this should be interesting |
| 05:29.24 | arrrghhh | indeed |
| 05:32.45 | WisTilt2 | ok kernel is up. this should give higher scores over the autobuild with the same oc freq you set hopefully |
| 05:33.50 | arrrghhh | alright |
| 05:33.54 | jonpry | i located the texture :) |
| 05:34.40 | arrrghhh | heh |
| 05:34.49 | jonpry | this is interesting |
| 05:34.54 | WisTilt2 | jonpry where was it hiding? |
| 05:35.18 | jonpry | i had to use it to get it flushed out to gpu |
| 05:35.39 | jonpry | texture memory apparently starts at gpu1+0x12c000 |
| 05:36.06 | jonpry | so if the framebuffer is really at gpu1 base, we have a serious problem |
| 05:36.38 | WisTilt2 | so texture is fixed to that offset? |
| 05:36.47 | jonpry | the first texture is |
| 05:36.55 | WisTilt2 | oh, in the gpu1 yeah |
| 05:37.12 | toastcfh | W/GraphicBufferAllocator( 138): free(...) failed -22 (Invalid argument) |
| 05:37.12 | toastcfh | E/guardedRun( 1175): guardedRun |
| 05:37.12 | toastcfh | E/guardedRun( 1175): java.lang.RuntimeException: eglSwapBuffers failed: EGL_BAD_ALLOC |
| 05:37.25 | toastcfh | hehe got angrybirds to play tho |
| 05:38.01 | jonpry | what did you do? |
| 05:38.31 | toastcfh | i added back copybit to gl |
| 05:40.03 | toastcfh | still derping on Unable to dequeue native buffer tho >_> |
| 05:43.00 | jonpry | WisTilt2, so this is likely the cause of that line i was seeing, and massive distortions with my compositor |
| 05:44.19 | *** join/#htc-linux kiozen (~kiozen@ppp-93-104-89-235.dynamic.mnet-online.de) |
| 05:45.55 | *** join/#htc-linux mitsutaka (~mitsutaka@p2057-ipbf202hodogaya.kanagawa.ocn.ne.jp) |
| 05:47.17 | WisTilt2 | yep sounds logical. looks like compositor is just around the corner |
| 05:50.28 | jonpry | this fix is needed for you guys too |
| 05:55.24 | jonpry | it totally got rid of tons of problems |
| 05:55.54 | jonpry | WisTilt2 you want the lib? |
| 05:56.40 | WisTilt2 | sure, email it if you can |
| 05:58.06 | jonpry | k, you are hooked up |
| 05:58.09 | WisTilt2 | thanks got it |
| 05:58.33 | WisTilt2 | so that would be the base addr in gpu1 for textures |
| 05:59.00 | jonpry | now its +0x2f0000 |
| 05:59.59 | bzo | jonpry: is this the cause of the missing textures in neocore gb? |
| 06:00.03 | WisTilt2 | question for you then, GB textures dont work in neocore but when i moved gpu1 into smi2 i got all the textures |
| 06:00.06 | jonpry | probably |
| 06:00.35 | jonpry | i got stuff to sporadically work as well |
| 06:01.37 | WisTilt2 | unless my alignment in smi2 happen to put it in the right place maybe. textures worked every time. so this with this lib in gb should work? |
| 06:02.11 | jonpry | its untested. but stuff should better now than before |
| 06:02.22 | WisTilt2 | bzo i have some acpuclock info for you also after i try this |
| 06:02.35 | bzo | ok |
| 06:02.46 | jonpry | i'm looking at some early dumps, ie barely used, from gpu0. seems to have some info in the first 0x100 |
| 06:02.53 | jonpry | then a stack like thing at the top |
| 06:03.43 | jonpry | about 256kb |
| 06:04.25 | jonpry | er. 512kb |
| 06:04.55 | jonpry | bzo you want the lib? |
| 06:05.06 | bzo | sure |
| 06:06.34 | jonpry | should have it |
| 06:06.52 | bzo | got it thx |
| 06:07.11 | bzo | what did you have to patch? |
| 06:08.58 | jonpry | couple bytes :p |
| 06:09.31 | jonpry | there was the weird bb800+bb800 > 12c000 thing |
| 06:09.50 | jonpry | and then this new one |
| 06:10.15 | bzo | oh, did we not patch one of the framebuffer size constants originally? |
| 06:10.47 | jonpry | somebody gave me this blob from frx7.1. i guess i can't really tell what was patched, but it never worked right for me |
| 06:11.18 | bzo | I think I patched that one, there was only one change which was to change the old fb size to 12c000 |
| 06:11.42 | bzo | er, I mean the 2f0000 |
| 06:12.06 | jonpry | i found two more 12c000's then |
| 06:12.44 | bzo | can't say I'm surprised, my disassembly skills are rudimentary |
| 06:13.14 | jonpry | ida does a good job with constants |
| 06:13.59 | bzo | heh, my ida skillz are rudimentary also |
| 06:14.40 | jonpry | did the old blob from froyo work with gb? |
| 06:14.48 | *** join/#htc-linux kiozen (~kiozen@ppp-93-104-89-235.dynamic.mnet-online.de) |
| 06:15.07 | bzo | that old blob dated back from the dream, so 1.5 or 1.6? |
| 06:15.26 | jonpry | the gles 1.0 one |
| 06:15.44 | bzo | yeah, it was extracted from one of the dream recovery images |
| 06:16.05 | bzo | the 1.1 I suppose was extracted from a newer device |
| 06:16.28 | jonpry | yeah cliq probably |
| 06:17.00 | jonpry | neither of those have neocore textures? |
| 06:17.19 | bzo | I thought they worked fine in froyo, just not in gb |
| 06:17.33 | arrrghhh | bzo is correct |
| 06:17.42 | arrrghhh | perhaps the lib in gb just needs to be swapped |
| 06:17.53 | arrrghhh | dunno if anyone really pursued the missing texture issue in neocore, lol |
| 06:17.57 | jonpry | w/ my new contraption? |
| 06:18.11 | arrrghhh | jonpry, no |
| 06:18.27 | arrrghhh | neocore is fine in froyo, but missing textures in gb. |
| 06:18.30 | jonpry | maybe froyo does not work with this strange egl double buffering |
| 06:18.34 | bzo | arrrghhh: I have a feeling jonpry's patched lib is the solution |
| 06:18.36 | rpierce99 | WisTilt2: with scbs running i've dropped ~10% in the last 1 1/2 hours |
| 06:18.44 | arrrghhh | bzo, perhaps. |
| 06:18.59 | jonpry | you need a copy arrrghhh? |
| 06:19.06 | bzo | arrrghhh: it seems the patch job the first time around was incomplete |
| 06:19.18 | arrrghhh | jonpry, sure lay it on me |
| 06:19.24 | arrrghhh | bzo, i see |
| 06:19.28 | arrrghhh | for Froyo as well? |
| 06:19.34 | WisTilt2 | jonpry: textures on neocore now with that lib however, its crawling slow and its the old test not the rocket on |
| 06:19.52 | bzo | arrrghhh: well, even in froyo angry birds was missing textures, maybe this will fix |
| 06:20.13 | arrrghhh | hrm. i guess i don't know what angry birds should look like. it always ran like a bag of ass for me. |
| 06:20.24 | jonpry | WisTilt2, that tends to happen when its working, lol |
| 06:20.30 | WisTilt2 | rpierce99 you must have some heavy hitting apps in the background. at least now with scbs you'll get a more accurate idea of the battery over many hours |
| 06:20.45 | WisTilt2 | looks excellent, all textures are there just fine |
| 06:20.53 | jonpry | cooel |
| 06:20.55 | bzo | arrrghhh: I don't think invisible hills are as designed |
| 06:21.01 | rpierce99 | got a score yet? |
| 06:21.05 | arrrghhh | hah |
| 06:21.41 | WisTilt2 | this is running way too slow for a score until tomorrow lol. looks like about 2fps atm |
| 06:21.49 | arrrghhh | hah |
| 06:21.54 | arrrghhh | nice |
| 06:22.08 | jonpry | hmm. maybe its not working right then |
| 06:22.30 | jonpry | i had to depatch the lib from something else |
| 06:22.46 | WisTilt2 | jonpry, even loading neocore once you hit run it takes about 15s before menu |
| 06:22.50 | jonpry | you get the "system process, deny" thingy in logcat? |
| 06:23.20 | jonpry | need that. my personal version has it removed |
| 06:23.51 | jonpry | WisTilt2, i think thats about the experience i've had |
| 06:24.39 | WisTilt2 | dont see any deny in logcat |
| 06:25.04 | jonpry | hrm. you see the stuff where surface flinger starts up? |
| 06:25.10 | jonpry | says like Renderer: and such? |
| 06:26.00 | WisTilt2 | maybe this is what you mean. i have a ton of these -> |
| 06:26.01 | WisTilt2 | W/PackageManager( 221): Not granting permission android.permission.STATUS_BAR to package com.android.vending (protectionLevel=3 flags=0xabec5) |
| 06:26.11 | jonpry | no not that |
| 06:26.58 | jonpry | D/EGL.oem ( 1023): system process, deny GL contex |
| 06:27.21 | WisTilt2 | I/pixelflinger( 703): Needs: n=0x03545444 p=0x00000177 t0=0x00008501 t1=0x00000000 |
| 06:27.26 | jonpry | but if it wasn't working. you would probably have no boot animation |
| 06:27.42 | WisTilt2 | bootani looked normal |
| 06:28.12 | jonpry | and i don't think neocore will run on pure software renderer |
| 06:31.35 | WisTilt2 | jonpry: quadrant errors out now with "This device does not support stencil buffers" |
| 06:32.55 | WisTilt2 | as much as i hate it, birds works fine |
| 06:33.13 | jonpry | what? this whole thing makes no sense |
| 06:34.00 | WisTilt2 | just reporting the facts:) anything else i need to change with fb? |
| 06:34.22 | jonpry | no |
| 06:34.47 | jonpry | what build are you running? |
| 06:34.47 | WisTilt2 | birds works but slow like the neocore was actually but it looks great |
| 06:35.00 | WisTilt2 | GB build or kernel? |
| 06:35.08 | jonpry | gb |
| 06:35.20 | jonpry | and you renamed the thing libGlES_qcom.so? |
| 06:35.26 | WisTilt2 | yes |
| 06:36.03 | WisTilt2 | build is 2.37 164458 |
| 06:36.06 | jonpry | nothing else to suggest |
| 06:36.09 | WisTilt2 | 2.3.7 |
| 06:36.22 | jonpry | i think your phone is out of control |
| 06:36.31 | jonpry | probably a partial meltdown |
| 06:37.26 | WisTilt2 | no idea. ill mess with it tomorrow at the office. |
| 06:37.31 | rpierce99 | did arrrghhh get the same results? |
| 06:37.59 | jonpry | i don't think anyone else tried |
| 06:38.13 | bzo | I'll give it a try momentarily |
| 06:38.40 | *** join/#htc-linux dobrin (~dobrin@85.91.150.26) |
| 06:39.01 | WisTilt2 | GB isnt signed so i shouldnt need to make a new data.img correct? |
| 06:39.33 | jonpry | it won't care about the 3d blob anyways |
| 06:40.00 | WisTilt2 | jonpry where do you have your fb if that matters. i have mine in smi1 right after gpu0 |
| 06:40.52 | jonpry | mine is in the normal git place. |
| 06:41.14 | WisTilt2 | that would be in ebi, maybe ill move it just to rule that out |
| 06:41.28 | jonpry | but i am not using this particular blob. or anything normal for that matter |
| 06:41.38 | bzo | hmm, my first attempt at kexec is fail. guess kernel must be in sd root... |
| 06:49.08 | WisTilt2 | same thing with neocore with fb in ebi. textures are looking good though so we'll see what bzo gets |
| 06:50.57 | *** join/#htc-linux Bry8Star (~Bry8Star@gateway/tor-sasl/bry8star) |
| 06:50.57 | jonpry | lolcat? |
| 06:52.54 | WisTilt2 | jonpry: http://pastebin.com/CZ4xuvmC |
| 06:53.41 | *** join/#htc-linux dr1337 (~textual@CPE-120-147-24-40.lflg2.win.bigpond.net.au) |
| 06:54.38 | dr1337 | I wonder if it's possible to use LK to chainload WP7 on a Nexus One... |
| 06:54.52 | jonpry | WisTilt2, that doesn't really show the startup of anything |
| 06:55.35 | WisTilt2 | scrolled off probably. let me capture it while i start neocore |
| 06:55.55 | bzo | LOL! I only see smoke and explosions now |
| 06:56.18 | jonpry | startup of flinger is more important than neocore i think |
| 06:56.37 | bzo | 28.4 fps of only textures |
| 06:56.50 | dr1337 | how's the porting going on jonpry? |
| 06:57.21 | jonpry | fixed some bugs. closing in on the texture external replacement |
| 06:57.36 | jonpry | i can locate a texture in gpu memory now |
| 06:57.48 | dr1337 | nic |
| 06:57.49 | dr1337 | nice |
| 06:58.09 | jonpry | yeah its gonna be cool. ultra speed |
| 07:03.09 | bzo | quadrant runs fine though |
| 07:04.07 | WisTilt2 | jonpry: this should have all the neocore part of logcat http://pastebin.com/Yeun96Jz |
| 07:04.55 | jonpry | nothing useful in there |
| 07:05.08 | jonpry | never seen this I/pixelflinger( 749): Needs: n=0x03313144 p=0x00000177 t0=0x00009501 t1=0x00000000 before |
| 07:05.54 | WisTilt2 | those dump in logcat frame by frame it appears. there are tons of them until i close neocore |
| 07:06.34 | WisTilt2 | bzo which neocore animation are you seeing the robot in space one or city? |
| 07:06.39 | jonpry | need logcat from boot |
| 07:06.54 | jonpry | don;t care about apps |
| 07:06.58 | bzo | WisTilt2: it's all black except for lights, smoke, fire and moon |
| 07:07.15 | WisTilt2 | but its the city scene? |
| 07:07.47 | bzo | you mean in the intro before the test? |
| 07:07.49 | WisTilt2 | jonpry you want boot up to running neocore ? |
| 07:08.09 | WisTilt2 | no when you start benchmark you have buildings or the space scene? |
| 07:08.24 | bzo | it's all black, hard to tell |
| 07:08.26 | jonpry | just need the early boot |
| 07:08.34 | jonpry | logcat at lockscreen will be fine |
| 07:08.48 | WisTilt2 | ok so no neocore gottcha |
| 07:09.41 | jonpry | do you know the file size of your old blob? |
| 07:09.51 | WisTilt2 | bzo the smoke you're seeing sounds like the one from the rockets. with this lib im now getting the old froyo neocore scene of the city with the tanks etc, no smoke until the explosion later |
| 07:10.03 | *** join/#htc-linux XirXes (~XirXes@67-2-21-13.slkc.qwest.net) |
| 07:12.38 | *** join/#htc-linux Sand_away (~Sandvold@213.236.244.131) |
| 07:12.54 | jonpry | i think there is still something wrong with it i get these strange allocator crashes. those should show up as FC's |
| 07:14.21 | WisTilt2 | jonpry: http://pastebin.com/j0FCFSzS |
| 07:15.26 | jonpry | it did not find the lib |
| 07:15.35 | jonpry | maybe wrong name, permissions. dunno |
| 07:15.48 | *** join/#htc-linux lamikr (lamikr@nat/nokia/x-zcgdzensjqmybksf) |
| 07:17.03 | WisTilt2 | im going to bed. ill be on tomorrow all day from office. later guys |
| 07:17.31 | jonpry | bzo so this is better or worse than it used to be? |
| 07:23.15 | dr1337 | jonpry what was the reason you think we get the dequeue buffer? |
| 07:23.26 | dr1337 | was working with a guy last night who had the same thing on a Droid 3 |
| 07:23.39 | dr1337 | which essentially has the same CPU and GPU type as the Galaxy Nexus |
| 07:24.02 | jonpry | those calls to the external texture api fail and send it down some weird path |
| 07:24.53 | dr1337 | i'm no expert in opengl, but do you think we could convert external textures to textures 2d? |
| 07:25.54 | jonpry | yeah it can be done. there is code in gb's TextureManager.cpp to do it. but its not super easy to integrate |
| 07:26.10 | jonpry | they like to use all the null's and stuff to encode states. ugh |
| 07:26.29 | dr1337 | yeah we were doing a bit of strace last night |
| 07:26.44 | dr1337 | managed to pin the thing down to somewhere in layer.cpp |
| 07:26.47 | dr1337 | onDraw |
| 07:27.14 | dr1337 | man the inheritence on Android is such a biatch |
| 07:27.38 | bzo | jonpry: so far worse I think. neocore is the opposite of before, and angry birds just dies |
| 07:27.48 | jonpry | hmm |
| 07:27.57 | bzo | not to say the patch is wrong, it may be exposing other problems |
| 07:27.59 | jonpry | and my compositor works great |
| 07:28.48 | jonpry | yeah i think the patch is right. but we haz serious issues |
| 07:29.47 | jonpry | we could always move to a single egl buffer or something |
| 07:30.45 | jonpry | dr1337, earlier we figured out dequeue happens in other apps. not flinger itself. looks like surfacetexture_client negotiates with surfacetexture |
| 07:31.06 | bzo | anyhow, I'm out, gn |
| 07:31.12 | jonpry | k, cya |
| 07:32.30 | dr1337 | jonpry interesting find |
| 07:33.01 | jonpry | dr1337, the method in texturemanager looks pretty good. it handles all kind of corner cases and stuff i hadn't really though about |
| 07:33.19 | jonpry | just jack it :p |
| 07:35.06 | dr1337 | hmm |
| 07:35.28 | jonpry | i think i can get ~4x performance from pmem hacked textures though |
| 07:35.40 | dr1337 | i wonder if we could intercept the call to bind the texture before it gets drawn and convert it to TEXTURE_2D |
| 07:36.23 | jonpry | binding it is not the problem. its updating the contents |
| 07:36.41 | jonpry | using nonexistant api's to update texture_2d is not a winner |
| 07:37.44 | *** join/#htc-linux kiozen (~kiozen@p54BB6AA9.dip.t-dialin.net) |
| 07:38.22 | dr1337 | hmm if you're going down the pmem road |
| 07:38.54 | dr1337 | maybe i might have to redo my kernel and force the gpu to use pmem instead of mmu |
| 07:39.07 | jonpry | thats the easy way |
| 07:40.11 | dr1337 | gahh that's what happens Google develops Android behind closed doors |
| 07:40.14 | Willd | arrrghhh: Hmm? |
| 07:41.12 | jonpry | mmu will make bypassing the driver somewhat more difficult |
| 07:41.50 | dr1337 | i'm tempted to give ION a go |
| 07:42.02 | dr1337 | except then I'd have to port the mahimahi stuff to 3.0 |
| 07:44.04 | *** join/#htc-linux bukington__ (~bukington@fac34-2-82-228-151-145.fbx.proxad.net) |
| 07:44.45 | *** join/#htc-linux bukington (~bukington@fac34-2-82-228-151-145.fbx.proxad.net) |
| 07:46.39 | *** join/#htc-linux mitsutaka (~mitsutaka@p2057-ipbf202hodogaya.kanagawa.ocn.ne.jp) |
| 07:54.41 | *** join/#htc-linux ychavan (ychavan@nat/redhat/x-negekhfvadbwphke) |
| 08:00.51 | *** join/#htc-linux jonpry (~jon@unaffiliated/jonpry) |
| 09:02.30 | *** join/#htc-linux gauner1986 (~Miranda@87.253.171.208) |
| 09:36.55 | *** join/#htc-linux lamikr (lamikr@nat/nokia/x-cxnxexxjfzdmnphl) |
| 09:47.25 | *** join/#htc-linux bukington_ (~bukington@fac34-2-82-228-151-145.fbx.proxad.net) |
| 09:53.10 | *** join/#htc-linux rajkosto (~rajkosto@2001:470:d76b:da7a:7152:110b:4751:4876) |
| 10:13.06 | *** join/#htc-linux Sandvold2 (~Sandvold@213.236.244.131) |
| 10:38.17 | *** join/#htc-linux Sand_away (~Sandvold@213.236.244.131) |
| 10:40.20 | *** join/#htc-linux GNUtoo (~gnutoo@host40-58-dynamic.116-80-r.retail.telecomitalia.it) |
| 10:44.51 | *** join/#htc-linux lamikr (lamikr@nat/nokia/x-rtmjqgbepkxozvhr) |
| 11:22.30 | *** join/#htc-linux Sand_away (~Sandvold@213.236.244.131) |
| 11:42.12 | *** join/#htc-linux lamikr (lamikr@nat/nokia/x-ienalqxruvqnsbpt) |
| 11:43.30 | *** join/#htc-linux rzk (~rzk@95-25-168-213.broadband.corbina.ru) |
| 12:25.04 | *** join/#htc-linux lamikr (lamikr@nat/nokia/x-dqrccxnppjhyvfvb) |
| 12:31.25 | *** join/#htc-linux rajkosto (~rajkosto@2001:470:d76b:da7a:a017:a804:1774:f3ed) |
| 13:01.57 | *** join/#htc-linux mitsutaka (~mitsutaka@g1-27-253-190-145.bmobile.ne.jp) |
| 13:07.52 | *** join/#htc-linux mitsutaka (~mitsutaka@g1-27-253-191-131.bmobile.ne.jp) |
| 13:17.24 | *** join/#htc-linux NetRipper (~netripper@tikkie.net) |
| 13:24.31 | *** join/#htc-linux Sand_away (~Sandvold@207.80-202-111.nextgentel.com) |
| 13:26.17 | *** join/#htc-linux mitsutaka (~mitsutaka@g1-27-253-191-21.bmobile.ne.jp) |
| 13:51.44 | *** join/#htc-linux helicopter88 (~helicopte@host187-199-dynamic.181-80-r.retail.telecomitalia.it) |
| 13:56.16 | *** join/#htc-linux balans (~server@82-170-217-205.ip.telfort.nl) |
| 14:11.08 | *** join/#htc-linux detule (~detule@hw-ma-6l13f61.mat.jhu.edu) |
| 14:37.54 | *** join/#htc-linux furtardo (~mks@nat/yahoo/x-xqlkkfobrlfsusei) |
| 14:52.38 | *** join/#htc-linux ccube (ccube@bnc.lukius.de) |
| 14:58.14 | *** join/#htc-linux skodde (~skodde@unaffiliated/skodde) |
| 15:03.02 | *** join/#htc-linux emwe (~mweirauch@cable-86-56-10-252.cust.telecolumbus.net) |
| 15:12.40 | *** join/#htc-linux stroughtonsmith (~steven@86-44-90-52-dynamic.b-ras2.bbh.dublin.eircom.net) |
| 15:16.17 | *** join/#htc-linux Alex[sp3dev] (~alexander@178.176.23.108) |
| 15:19.14 | *** join/#htc-linux mgross029 (c0234f46@gateway/web/freenode/ip.192.35.79.70) |
| 15:41.14 | *** join/#htc-linux kiozen (~kiozen@ppp-93-104-89-235.dynamic.mnet-online.de) |
| 15:59.24 | *** join/#htc-linux AstainHellbring (~AstainHel@unaffiliated/astainhellbring) |
| 16:31.55 | *** join/#htc-linux NeoMatrixJR (~chatzilla@173-20-63-62.client.mchsi.com) |
| 16:41.17 | *** join/#htc-linux Cotulla (~myfakemai@nat100-255-205-109.tvoe.tv) |
| 16:42.08 | Cotulla | hi |
| 16:45.28 | gauner1986 | hi |
| 16:45.38 | Blista | hi yerself! |
| 16:46.13 | Cotulla | wiped temp folder in Blista's brain |
| 16:51.54 | *** join/#htc-linux Rob2222 (~Miranda@p4FFF0387.dip.t-dialin.net) |
| 16:51.58 | *** join/#htc-linux paulk (~paulk@lib33-1-82-233-88-171.fbx.proxad.net) |
| 17:00.53 | *** join/#htc-linux WisTilt2 (~wisgreg@wireless251.wirelesstcp.net) |
| 17:06.14 | WisTilt2 | well bzo's thought about gsensor sucking power was correct. with it disabled my battery drain overnight was .58% per hour, and that's with scbs daemon still running. |
| 17:08.01 | WisTilt2 | jonpry: i looked more at this lib and it looks like GB is trying to only load libGLES_android.so, i dont see anywhere its loading the qcom one. |
| 17:08.33 | jonpry | it probably has wrong name, or permissions |
| 17:08.37 | Willd | WisTilt2: Is the config set to use hardware then? |
| 17:08.59 | jonpry | the .nosys on the filename needs to be removed |
| 17:09.14 | jonpry | libGLES_qcom.so exactly |
| 17:09.16 | WisTilt2 | it is changed to .so if that's what you mean |
| 17:09.16 | Alex[sp3dev] | WisTilt2: what about memory overclock? |
| 17:09.22 | WisTilt2 | yes thats how it is |
| 17:09.25 | jonpry | probably set it mode 666 |
| 17:09.34 | WisTilt2 | k ill try that |
| 17:09.48 | jonpry | check egl.cfg make sure it has both android and qcom entries |
| 17:09.49 | Cotulla | hi Alex |
| 17:09.53 | Cotulla | how is it? |
| 17:10.21 | WisTilt2 | Alex[sp3dev]: looks like using cmd line oc the cpu and memory already get oc'd from what i can tell. gpu1 is only thing that isnt |
| 17:10.26 | Alex[sp3dev] | Cotulla: hi.. it goes... |
| 17:11.15 | *** join/#htc-linux vinceweis_ (4463ed13@gateway/web/freenode/ip.68.99.237.19) |
| 17:11.18 | Cotulla | to unversal interface for everything? ^^ |
| 17:11.37 | Alex[sp3dev] | WisTilt2: i tried overclocking the grp_3d, but seems like it ignores the divider and the only way to gain moar speed is to overclock the entire pll |
| 17:14.40 | jonpry | this 3d blob is a piece |
| 17:16.30 | WisTilt2 | jonpry: cfg has 0 0 android and 0 1 qcom |
| 17:17.19 | jonpry | assuming the permissions are ok. the only real possibility is a type in the filename |
| 17:17.53 | WisTilt2 | Alex[sp3dev]: im going to attempt to oc gpu1 a different way today. what you're saying about the divider might be what i saw last night, seemed the more i oc'd it the worst the scores for gpu1 were with the benchmark |
| 17:18.41 | WisTilt2 | lol, well perms on my qcom.so is 600 so guess ill try that at 666 now:) |
| 17:19.22 | WisTilt2 | the original qcom.so was 644 |
| 17:21.10 | jonpry | guess it depends who its owned by |
| 17:28.50 | WisTilt2 | jonpry: well that was the problem but now its back to the normal neocore scene but no textures. neocore loaded fast again also and fps was 29.5 |
| 17:29.28 | jonpry | smoke and flames? |
| 17:29.37 | WisTilt2 | yep |
| 17:30.09 | WisTilt2 | checking logcat |
| 17:30.13 | jonpry | i don |
| 17:30.22 | jonpry | 't really know what to do about the textures |
| 17:30.47 | WisTilt2 | yeah its loading your lib now |
| 17:31.19 | WisTilt2 | gralloc is allocating 770048 size |
| 17:32.15 | WisTilt2 | should gralloc be allocating that twice in 2 different locations? |
| 17:32.24 | jonpry | yes |
| 17:32.31 | jonpry | double buffer |
| 17:32.40 | WisTilt2 | D/gralloc ( 221): allocating GPU size=770048, offset=0 |
| 17:32.40 | WisTilt2 | D/gralloc ( 221): allocating GPU size=770048, offset=770048 |
| 17:33.19 | jonpry | the usefulness of the double buffer is highly debatable. but atm i don't see a way to stop it |
| 17:33.40 | WisTilt2 | im not seeing any of those pixelflinger lines now either |
| 17:34.25 | jonpry | maybe put the gpu1 in smi2 and see if the texture appear? |
| 17:35.02 | WisTilt2 | ill try that with this lib. got textures with the other lib but only in smi |
| 17:42.33 | *** join/#htc-linux Ondalf (~ondalf@unaffiliated/ondalf) |
| 17:48.47 | *** join/#htc-linux furtardo (~mks@nat/yahoo/x-cmvbltfboxqhcytl) |
| 17:55.03 | *** join/#htc-linux mgross029 (c0234f46@gateway/web/freenode/ip.192.35.79.70) |
| 17:57.24 | *** join/#htc-linux furtardo (~mks@nat/yahoo/x-myisfcejpmumgorr) |
| 18:02.38 | WisTilt2 | jonpry no 3d at all now just black screen. whats interesting is i changed back to the original qcom lib and it works fine. This is where gpu1 is now, ebi is just the name -> |
| 18:02.39 | WisTilt2 | D/EGL.oem ( 772): ebi: offset=00000000, len=00800000, phys=0x2800000 |
| 18:03.46 | jonpry | urg |
| 18:03.57 | *** join/#htc-linux |Jeroen| (~jeroen@d5152B25B.access.telenet.be) |
| 18:04.28 | WisTilt2 | with orig qcom textures all work and i get 28.7fps most of the time |
| 18:04.45 | WisTilt2 | move gpu1 back to ebi and no textures with same lib so i have no idea |
| 18:04.50 | jonpry | fire and flames? |
| 18:05.16 | WisTilt2 | fire/flames only in ebi. in smi2 rockets and robot are there also |
| 18:05.46 | WisTilt2 | i dont see how smi should be any different for textures |
| 18:06.35 | *** join/#htc-linux LordDeath (~LordDeath@cable-81-173-164-108.netcologne.de) |
| 18:06.49 | jonpry | dunno. textures in general work great using this blob |
| 18:07.05 | jonpry | for me on cm7. can't try neocore |
| 18:09.13 | jonpry | might be able to debug it with this gpu memory dump thing. make sure other stuff is not being allocated in the wrong place. vertex buffers or something |
| 18:14.17 | WisTilt2 | i just moved gpu0,fb, and ram console to ebi and put gpu1 in smi1 and neither lib has textures, just smoke and flames so now i really have no idea now. |
| 18:18.09 | *** join/#htc-linux stroughtonsmith (~steven@86-44-111-163-dynamic.b-ras2.bbh.dublin.eircom.net) |
| 18:24.44 | jonpry | me neither. no interesting EGL.oem errors? |
| 18:25.29 | WisTilt2 | nope no errors at all. it all looks like it should be working |
| 18:27.31 | jonpry | dur http://android.modaco.com/topic/342526-cyanogenmod-71-rc-released/page__st__200 |
| 18:27.41 | jonpry | sun ibx patched libEGL and then everything works |
| 18:27.54 | jonpry | doesn't say with what :( |
| 18:30.24 | WisTilt2 | ill give that a try but would like to know what they did. the fact i get textures in smi2 makes we wonder about some offset in gpu1 that isnt aligned in the right place where we have it stuck in memory. |
| 18:31.52 | jonpry | i have a totally different libEGL than you. may already have the patch |
| 18:33.59 | *** join/#htc-linux balans (~server@82-170-217-205.ip.telfort.nl) |
| 18:35.57 | Cotulla | jonpry, how is it? |
| 18:36.00 | Cotulla | hi |
| 18:38.39 | WisTilt2 | jonpry that fixed it totally. running your lib still also and have gpu1 in ebi again. looks fantastic and smooth. getting only 20.5fps but looks nice |
| 18:39.16 | jonpry | cooel |
| 18:39.27 | jonpry | you just used the binary w/ unknown patch? |
| 18:39.35 | jonpry | hi Cotulla |
| 18:39.37 | WisTilt2 | now im going to stick gpu1 back in smi and see if it speeds it up at all |
| 18:40.18 | WisTilt2 | i used that egl and still have your qcom lib |
| 18:40.49 | jonpry | hopefully we can do better than some random egl blob. for another day i guess |
| 18:50.07 | *** join/#htc-linux rob_w (~bob@ppp-188-174-31-129.dynamic.mnet-online.de) |
| 18:54.01 | WisTilt2 | jonpry: not that it matters since no one can used it but me:) but gpu1 in smi2+8 works like a dream. popped me up to 27fps in neocore instead of 20.5 in ebi so i guess smi is much faster than ebi. |
| 18:54.14 | arrrghhh | damn |
| 18:54.19 | arrrghhh | and hi |
| 18:54.20 | arrrghhh | :D |
| 18:54.23 | WisTilt2 | hi arrrghhh |
| 18:54.39 | WisTilt2 | 27fps with full rendering is not bad imo |
| 18:54.47 | arrrghhh | that's really damned good in fact |
| 18:54.52 | arrrghhh | for our phones |
| 18:55.12 | WisTilt2 | if i can get gpu1 oc'd in ebi we might get up there |
| 18:58.52 | *** join/#htc-linux vinceweis_ (4463ed13@gateway/web/freenode/ip.68.99.237.19) |
| 19:03.11 | jonpry | can't we all do gpu1 at smi2 base? |
| 19:04.39 | WisTilt2 | smi2 base should be ok but didnt you see some quirks there? the bottom 8mb should be good on all rhods afaik |
| 19:05.49 | jonpry | quirk could have been from the bugs in the blob |
| 19:06.25 | WisTilt2 | thats true. ill whip one up that arrrghhh and/or rpierce99 can give a try |
| 19:06.32 | arrrghhh | sounds good |
| 19:06.44 | arrrghhh | i'll be in-and-out. back to the grind for moi.. |
| 19:10.00 | jonpry | what clock rate is the adreno running at? |
| 19:15.59 | WisTilt2 | jonpry: black screen in 3d with gpu1 at smi2 base. this makes no sense |
| 19:17.01 | jonpry | try setting fb==gpu1. sometimes its just not blitting |
| 19:17.25 | WisTilt2 | so overlap fb at gpu1 base? |
| 19:17.34 | jonpry | yeah |
| 19:20.09 | *** join/#htc-linux detule (~detule@hw-ma-6l13f61.mat.jhu.edu) |
| 19:23.58 | WisTilt2 | jonpry: no difference |
| 19:26.25 | WisTilt2 | jonpry: http://pastebin.com/0AV9b2N4 |
| 19:27.31 | jonpry | that seems ok. but i haven't tried smi2 since i saw the line thing |
| 19:28.08 | *** join/#htc-linux litzi0815 (~dl@f051225032.adsl.alicedsl.de) |
| 19:28.21 | WisTilt2 | is this normal locked_open_wait_for_gpu: has client, waiting |
| 19:28.44 | jonpry | don't think so |
| 19:29.48 | WisTilt2 | nothing unusual showing up on display, no lines etc. maybe fb needs to be offset into gpu1 at that 0x2f0000 whatever base? |
| 19:30.13 | jonpry | no. definitely as base |
| 19:30.37 | jonpry | you have any hw3d interrupts? |
| 19:30.48 | WisTilt2 | bah, just rebooting now |
| 19:31.15 | WisTilt2 | let me boot this back up. was going to move gpu1 back to ebi with fb at base and see if it works |
| 19:31.56 | jonpry | yeah i haven't done any testing with that lately because it all of a sudden started blitting for me |
| 19:32.10 | *** part/#htc-linux litzi0815 (~dl@f051225032.adsl.alicedsl.de) |
| 19:32.15 | jonpry | we can make it work w/ a little bit of effort |
| 19:33.23 | jonpry | the biggest issue is that i don't know how to stop it from blitting. so i think it does memcopy from src == dst |
| 19:33.48 | jonpry | until that stops there is not even any performance gain |
| 19:35.48 | WisTilt2 | no hw3d ints at al |
| 19:36.25 | jonpry | then its just broken |
| 19:36.49 | WisTilt2 | going to try fb overlap in ebi then ill move on |
| 19:38.42 | *** join/#htc-linux NetRipper (~netripper@tikkie.net) |
| 19:47.06 | WisTilt2 | jonpry: this fb overlap works when gpu1 is in ebi but it flakes out the screen while its running. like its flipping fb and 3d back and forth on display but it didnt affect the benchmark scores. |
| 19:48.18 | jonpry | yeah we can't probably fix that somehow. but i'm not sure how at the moment |
| 19:49.07 | WisTilt2 | well im moving back to working on oc'ing gpu for now. let me know if you need me to try anything else. |
| 19:49.16 | jonpry | ok. thanks |
| 19:49.44 | *** part/#htc-linux Cotulla (~myfakemai@nat100-255-205-109.tvoe.tv) |
| 19:50.22 | detule | hey WisTilt2 |
| 19:50.29 | WisTilt2 | yo |
| 19:50.30 | *** part/#htc-linux Alex[sp3dev] (~alexander@178.176.23.108) |
| 19:50.50 | detule | i have the same problem on .39 and 3.0 I was hoping you could help me out with |
| 19:51.17 | WisTilt2 | sure whats up |
| 19:51.24 | detule | .39 from the autobuild -> i let the my phone fall in suspend (green light) then i plug any kind of charger wall or usb and i can't wake it up |
| 19:51.32 | detule | green light stays on |
| 19:52.13 | arrrghhh | detule, i mentioned that... i was told to just make sure it's on before i plug in :P |
| 19:52.15 | detule | if i press rapidly on the power button i will eventually get orange led and screen will come back on, but i have to rapid/press perhaps 10-20 times |
| 19:52.19 | arrrghhh | .27 is the same way |
| 19:52.20 | WisTilt2 | you have sleep mode set to 0 or 1? |
| 19:52.48 | detule | hm i guess i haven't checked/changed my startup.txt in a loooong time |
| 19:52.53 | detule | my guess is pm.sleep_mode =1 |
| 19:53.03 | WisTilt2 | i think that only happens in mode 0 which ive been against forever:) |
| 19:53.18 | detule | well if i revert your recent PM commits it doesn't happen |
| 19:53.32 | arrrghhh | what about that insta-plug ISR or whatever? |
| 19:53.38 | detule | so perhaps we need a new thing in startup.txt? |
| 19:53.47 | WisTilt2 | which ones the idle suspend/collapse stuff? |
| 19:53.53 | arrrghhh | ACL has it working swimmingly on NAND. i know enabling it on HaRET caused SOD's in the past. |
| 19:53.53 | detule | yes |
| 19:54.16 | WisTilt2 | hmm, let me try mine. i run mode 1 full collapse and dont think i have that issue, standby |
| 19:54.29 | detule | my pm.pm_sleep_mode=1 |
| 19:54.32 | detule | in startup.txt |
| 19:54.48 | arrrghhh | detule, is that the command verbatim? |
| 19:54.53 | detule | pm.sleep_mode |
| 19:54.53 | WisTilt2 | arrrghhh you're probably right, i dont think we have any insta plug in .39 |
| 19:55.03 | arrrghhh | detule, ok. |
| 19:55.12 | arrrghhh | WisTilt2, yea when i asked you about this you said just make sure it's turned on before plugging in |
| 19:55.28 | arrrghhh | what's odd is on .27, it won't recognize the plug in - but it also doesn't have issues waking if you do plug in when sleeping. |
| 19:55.59 | detule | yeah something is not 100% ok with the recent work |
| 19:56.47 | WisTilt2 | detule you reverted the idle suspend/collapse and it doesnt happen is what you're saying? |
| 19:56.52 | detule | yes |
| 19:57.16 | WisTilt2 | ok i think i know why thats happening then. need to take a look |
| 19:57.18 | detule | with idle suspend/collapse it's reproducible 10 out of 10 both on wall and usb charger |
| 19:58.55 | detule | also i was thinking about usb/adb terminating in idle, and i know you had a workaround, but i was wondering if initing this wakelock for IDLE https://gitorious.org/linux-msm-rhod/linux-msm-rhod/blobs/htc-msm-2.6.39/arch/arm/mach-msm/htc_battery.c#line1863 would make a difference |
| 20:00.23 | WisTilt2 | yes, the temp workaround isnt the way it should really be done permanently and that appears to be whats causing the sod when in sleep. otg is supposed to be preventing idle modes from happening but it isnt |
| 20:00.54 | detule | how about that wake_lock in htc_battery isn't that preventing sleep/idle while a power source is present |
| 20:01.35 | detule | if it's init'ed to IDLE that is |
| 20:01.53 | WisTilt2 | supposed to be but problem is in pm's idle code that nevers see those wakelocks |
| 20:02.03 | detule | ah |
| 20:02.32 | WisTilt2 | this idle code really needs reworking since no one has really ever enabled it to find out it has issues:) |
| 20:03.52 | arrrghhh | heh |
| 20:04.05 | jonpry | need to add idle wakelocks |
| 20:04.18 | detule | i thought allow_sleep in pm.c |
| 20:04.24 | detule | checks for idle wake_locks |
| 20:04.32 | WisTilt2 | i did in otg, maybe they are needed in udc also |
| 20:04.45 | jonpry | probably does. then just need to change the vbus wakelock type |
| 20:04.51 | detule | it's in there |
| 20:04.53 | detule | in htc_battery |
| 20:04.59 | detule | just re-init that wake_lock for idle |
| 20:05.29 | WisTilt2 | isnt htc_battery disabled with scbs though? |
| 20:06.10 | jonpry | no |
| 20:06.11 | detule | i would think the interrupts are still firing |
| 20:08.09 | *** join/#htc-linux bzo (~chatzilla@c-174-62-79-238.hsd1.ca.comcast.net) |
| 20:09.39 | *** join/#htc-linux emwe (~mweirauch@cable-86-56-10-252.cust.telecolumbus.net) |
| 20:09.50 | bzo | WisTilt2: I don't the the acpuclock OC code changes the memory speed |
| 20:09.52 | WisTilt2 | ok this should fix it, building and trying now, brb |
| 20:10.28 | bzo | jonpry: that other lib_egl fixes my 3d as well |
| 20:10.56 | WisTilt2 | bzo it is according to memory benchmarks by a large amount |
| 20:11.31 | bzo | hmm, I would think the mem bus is independent of the cpu freq |
| 20:11.44 | bzo | afaik, pll2 is only used for certain freqs for the cpu |
| 20:12.08 | *** join/#htc-linux kiozen (~kiozen@ppp-93-104-89-69.dynamic.mnet-online.de) |
| 20:12.12 | WisTilt2 | ebi is off axi and axi is being stepped up with oc |
| 20:12.50 | jonpry | ultra turbo |
| 20:13.13 | bzo | so the OC code is changing the same registers you were doing for the mem OC? |
| 20:13.24 | WisTilt2 | bzo yes in a round about way |
| 20:13.50 | bzo | so you were changing the axi dividers? |
| 20:14.05 | WisTilt2 | the axi calcs are wrong though in oc, you can actually step axi up to 192mhz, oc now only goes to 160 |
| 20:14.05 | *** join/#htc-linux rzk (~rzk@95-24-54-101.broadband.corbina.ru) |
| 20:14.29 | bzo | in that case, I guess we only need to tweak the freq tables a bit to make that happen |
| 20:14.33 | WisTilt2 | i was using our clock setup we use on our device but yes regs and dividers directly setup |
| 20:14.55 | WisTilt2 | yes, i wanted to go over my suggestions with you about that |
| 20:15.12 | WisTilt2 | let me finish testing this wakelock first |
| 20:15.43 | jonpry | the meltdown saga continues |
| 20:29.08 | *** join/#htc-linux kiozen (~kiozen@ppp-93-104-89-69.dynamic.mnet-online.de) |
| 20:31.07 | detule | WisTilt2, with that wake_lock redefined, and without the usb_connected business, my adb connection persists past screen off, though still the same problems with resume after plugging in cable while in suspend |
| 20:31.22 | WisTilt2 | detule: just to verify what you're doing, phone is in sleep and you plug in either charger or usb. locks at that point or when you try to power up? i added vbus wakelock check in pm and now if phone is in sleep and you plug usb in it wakes up after 10s or so and doesnt sod at all |
| 20:31.39 | WisTilt2 | hehe |
| 20:31.47 | WisTilt2 | guess we were typing at same time |
| 20:32.22 | WisTilt2 | until we get insta-plug it has to wait on battery time to poll the usb |
| 20:32.25 | detule | i wonder why it's having these issues powering back the device from suspend after plugging in a power source |
| 20:33.20 | WisTilt2 | timer in battery code, sometimes its right away, sometimes up to 10s before it knows it plugged in. |
| 20:33.37 | *** join/#htc-linux mastermerlin (~Adium@pD9E2EF4B.dip.t-dialin.net) |
| 20:33.47 | detule | but why would that make the device not responsive when pressing the power button |
| 20:34.13 | detule | it does a very good SOD impersionation |
| 20:35.38 | *** join/#htc-linux kiozen (~kiozen@ppp-93-104-89-69.dynamic.mnet-online.de) |
| 20:36.43 | *** join/#htc-linux Bry8Star (~Bry8Star@gateway/tor-sasl/bry8star) |
| 20:40.20 | detule | i have a sneaky suspicion it's that enable_irq_wake call in _udc |
| 20:46.33 | WisTilt2 | need to test a couple more things with this wakelock later. lunch is here shortly so bzo let me grab you before you get out of here |
| 20:46.57 | *** join/#htc-linux kiozen (~kiozen@ppp-93-104-89-69.dynamic.mnet-online.de) |
| 20:47.10 | WisTilt2 | unless you're tied up we can hookup later |
| 20:47.10 | bzo | if this ebi clocking is happening, it is new for 39 |
| 20:47.40 | bzo | looking at 27, in the set clock code, it just exits if ebi is requested |
| 20:47.46 | bzo | but the new 39 code may be doing something |
| 20:48.52 | bzo | in any case though, it doesn't seem like the OC code touches the ebi table freq |
| 20:48.57 | WisTilt2 | it is. run memory benchmark in normal mode then try oc. huge memory speed increase |
| 20:49.25 | bzo | must be an unintended consequence :) |
| 20:49.51 | WisTilt2 | where does memory get its clocks in .27? |
| 20:50.09 | bzo | doesn't, never changed from bootup afaict |
| 20:51.27 | bzo | this alone could be why 39 feels so much faster than 27 |
| 20:52.46 | WisTilt2 | yes, even without oc it seems so. we were seeing similar benchmarks with my hardcoded memory oc against .27 in oc mode though with arrrghhh so .27 has to be stepping it up also i'd think |
| 20:53.59 | bzo | judging from the axi table freqs, it can derive them from pll0 or pll1 |
| 20:54.04 | bzo | maybe it does from pll2 as well |
| 20:54.20 | WisTilt2 | i havent looked but are we using reg 0x14 off msm clk base at all? |
| 20:55.01 | jonpry | isn't there some kind of acpuclock problem w/ idle collapse? |
| 20:55.25 | WisTilt2 | not that i know of, like what? |
| 20:55.28 | bzo | WisTilt2: not sure |
| 20:55.47 | jonpry | we have that patch that sets acpuclock resume speed to minimum frequency |
| 20:56.04 | jonpry | which is probably a good idea for suspend collapse |
| 20:56.07 | WisTilt2 | didnt i take that out, or at least go around it so its not used now? |
| 20:59.30 | jonpry | hmm. i don't see it |
| 21:00.21 | *** join/#htc-linux EdLin (~EdLin@securabit/listener/edlin) |
| 21:24.57 | detule | hm how comm our proc_comm_wince looks so skimpy |
| 21:27.16 | *** join/#htc-linux kiozen (~kiozen@ppp-88-217-4-4.dynamic.mnet-online.de) |
| 21:28.31 | WisTilt2 | lunch wasn't such a good idea, now im sluggish. |
| 21:29.01 | WisTilt2 | bzo: you also need to change max_axi_khz=200000 in board file for it to step up higher |
| 21:29.11 | arrrghhh | WisTilt2, this benchmark testing i fear is inconclusive. |
| 21:29.21 | WisTilt2 | i forgot i have that bypassed in acpuclock for testing |
| 21:29.41 | WisTilt2 | arrrghhh between .27 and .39 or what? |
| 21:29.45 | arrrghhh | everything |
| 21:29.57 | arrrghhh | i still need to do vanilla .39 with cpu and memory tho |
| 21:29.59 | arrrghhh | just finished up .27 |
| 21:30.25 | WisTilt2 | yeah .39 stock and oc'd will tell you right away |
| 21:30.32 | arrrghhh | probably need to redo all the tests with a fresh data.img, but it'll probably still be inconclusive |
| 21:30.37 | arrrghhh | all tests are on 614400 |
| 21:30.45 | arrrghhh | oh well. take a look if you want |
| 21:30.47 | WisTilt2 | good |
| 21:30.50 | arrrghhh | i made a handy comparison chart |
| 21:30.56 | WisTilt2 | sure email it |
| 21:31.03 | arrrghhh | so you can easily see how it's not conclusive :P |
| 21:31.09 | arrrghhh | https://docs.google.com/spreadsheet/ccc?key=0AvCpm2u2mcfBdEFGVlNxcW44M2xTVDVXRkxGQW1sYkE |
| 21:31.15 | arrrghhh | anyone can view my horrors |
| 21:31.17 | jonpry | probably should use the new gl lib and egl for any 3d benches |
| 21:31.27 | WisTilt2 | yes |
| 21:31.42 | arrrghhh | jonpry, sounds good. i will redo the tests on a fresh data.img and with that new lib. |
| 21:31.54 | arrrghhh | for now.... i must go install things off-site. cya guys |
| 21:32.27 | WisTilt2 | later arrrghhh |
| 21:32.40 | WisTilt2 | i wonder why .27 2d is so much higher than .39 |
| 21:33.12 | jonpry | is it the same GB build? |
| 21:33.33 | WisTilt2 | good question |
| 21:33.55 | WisTilt2 | that i dont know. best 2d i get is 98 compared to 135 damn |
| 21:34.50 | detule | hey you guys seen any problems with half the stuff missing out of proc_comm_wince in .39 |
| 21:35.04 | WisTilt2 | whats missing? |
| 21:35.48 | detule | all the suspend/resume hooks |
| 21:36.27 | detule | all the DEX interrupt flags (perhaps they were moved somewhere) |
| 21:37.05 | WisTilt2 | i think they were. |
| 21:37.40 | detule | the msm_proc_comm_wince_irq is not there |
| 21:37.41 | WisTilt2 | jonpry: in PM are you talking about that hard value for acpuclock where we set it like 128mhz or so? |
| 21:38.26 | detule | which i guess is only relevant if we decide to go with instant plug notification (i think that uses that irq) |
| 21:38.55 | jonpry | WisTilt2, yes |
| 21:39.21 | jonpry | we don't want dex irq |
| 21:39.33 | jonpry | i forked it before that madness came along |
| 21:40.42 | WisTilt2 | we had that set to cpu minimum yeah, wonder if we still need that. i think the way its setup now the cpu resumes at the lowest freq anyway and thats why we got rid of that. |
| 21:43.56 | WisTilt2 | detule did you say you added a wakelock for this usb problem? if so, what exactly did you do. i added vbus wake check in pm but looks like we really should have idle wakelock in battery code. |
| 21:44.45 | detule | WisTilt2, I didn't add any wakelocks to pm, there is a wakelock in htc_battery, it just init's to be defined for IDLE rather than suspend |
| 21:45.16 | emwe | guys, look at what i did to htc_battery_smem.c on .35 back months ago and what i reverted to recently. |
| 21:45.17 | WisTilt2 | ah |
| 21:45.19 | emwe | i had the very same. |
| 21:45.45 | emwe | arm11 suspended/resumed several times a second on usb... which then somehow broke it. |
| 21:46.03 | emwe | then some weeks ago i had to revert that back after those massive longterm patches to .35.14 |
| 21:46.07 | jonpry | is there a way we can increase gpu1, like mega? |
| 21:46.11 | emwe | whatever it was it is now so like it was on .27. |
| 21:46.21 | detule | WisTilt2, http://pastebin.com/6MkgPvBR this should prevent IDLEing with power source present |
| 21:46.59 | WisTilt2 | yep that will do it i believe |
| 21:47.13 | detule | though i don't think it solves the issue with the apparent sod when trying to power on the device |
| 21:47.23 | detule | from suspend after plugging a power source |
| 21:47.50 | detule | emwe apparently redefining this wake lock to idle is needed with these recent PM changes |
| 21:48.01 | WisTilt2 | emwe did that fix the sod in sleep with usb or is this just to keep it awake? |
| 21:48.19 | detule | emwe, had to revert it to SUSPEND from IDLE because he had sods |
| 21:48.48 | WisTilt2 | idle is what we want but only if idle code is enabled in PM i guess |
| 21:48.54 | emwe | it did try to suspend resume several times a second. with SUSPEND and after some time (minutes) froze. |
| 21:49.04 | emwe | then somehow i reverted that back to ILDE and is ok now. |
| 21:49.18 | emwe | i dunno what made it change the behaviour. |
| 21:49.46 | WisTilt2 | do you have idle suspend/collapse enabled in smd? |
| 21:50.12 | detule | emwe, you currently have that wake lock to SUSPEND right? |
| 21:50.38 | emwe | detule: yes, back to SUSPEND some weeks ago as mgross029 had it reported to cause trouble again. |
| 21:50.41 | emwe | WisTilt2: smd? |
| 21:51.46 | *** join/#htc-linux rpierce99 (~rpierce99@96-42-102-103.dhcp.stcd.mn.charter.com) |
| 21:52.30 | emwe | rpierce99: the 40% overnight drain-companion ;) |
| 21:52.40 | rpierce99 | you too? :) |
| 21:52.54 | emwe | ofc RHOD400 GSM with... well syncs |
| 21:53.03 | emwe | google and k9mail |
| 21:53.28 | emwe | but all RHODW have the two VREGS not toggled on panel suspend because they were said to be data-connection-breakers. |
| 21:53.40 | emwe | i will test again over night and see. |
| 21:54.16 | WisTilt2 | emwe, sorry got 10 people talking at once to me at the office. do you have smsm_interrupt_info changed in smd_private so idle is enabled? |
| 21:54.36 | rpierce99 | so today i've been off charger for 8.5 hours and i'm at 47 according to android, now it's already given me a "you should plug in your power cord" so take that with a grain of salt, it'll probably die any minute :) |
| 21:54.42 | emwe | WisTilt2: i gave you the hint, so yeah, it is enabled since the early beginnings of .35 :P |
| 21:55.03 | WisTilt2 | i know:) wonder if with it enabled if idle wake works instead of suspend |
| 21:55.39 | *** join/#htc-linux furtardo (~mks@nat/yahoo/x-muhwxhdiivhphjrq) |
| 21:56.37 | WisTilt2 | ill be back in a bit, need to bang some heads around here |
| 21:56.39 | emwe | IDLE will for sure do for you guys. |
| 21:57.33 | emwe | please don't ask me what made it "revert" to the original behaviour and just work again. |
| 21:57.49 | jonpry | anyone try with gpu1 larger than 8mb, 13 perhaps? |
| 21:59.39 | rpierce99 | <PROTECTED> |
| 22:00.00 | rpierce99 | want to make sure to mention, it doesn't hard lock, after like 5 minutes of button mashing i can get it to wake up again |
| 22:00.04 | rpierce99 | but the clock is stopped |
| 22:00.08 | rpierce99 | had it happen last night |
| 22:00.13 | rpierce99 | clock was still stopped in the morning |
| 22:06.45 | *** join/#htc-linux kiozen (~kiozen@ppp-88-217-4-4.dynamic.mnet-online.de) |
| 22:08.38 | detule | yes, that about sums it up though my clock picks up after I manage to resuscitate |
| 22:09.16 | rpierce99 | i rescued mine around 1am, but the clock still said 1am at like 7am when i got up |
| 22:09.19 | mgross029 | I didn't do it. :p |
| 22:09.26 | rpierce99 | i might not have rescued it enough |
| 22:09.48 | detule | I think the vbus wake_lock to IDLE will solve the issue with losing adb/usb connection after going to sleep, without the need for any _udc/pm.c additions, however it does not alleviate the issue with these bouts of unresponsiveness |
| 22:10.01 | detule | rpierce99, the sleep debugging comes in handy |
| 22:10.15 | detule | not rescued completely until it manages to go back to sleep again |
| 22:10.28 | mgross029 | emwe, I've found better call respond if I turn on bt, because the phone doesn't go to sleep fully. :) |
| 22:10.45 | mgross029 | s/turn on/turn off |
| 22:10.52 | emwe | lol |
| 22:11.14 | mgross029 | I thought you may find that funny. heh |
| 22:14.20 | *** join/#htc-linux kiozen (~kiozen@ppp-88-217-4-4.dynamic.mnet-online.de) |
| 22:15.44 | *** join/#htc-linux ftoz (~root@cst-prg-93-5.cust.vodafone.cz) |
| 22:37.21 | *** join/#htc-linux TheXev (~user@166.sub-174-252-201.myvzw.com) |
| 22:38.29 | *** join/#htc-linux [acl] (~abel@96.246.167.90) |
| 22:38.46 | [acl] | cotula ? |
| 22:38.49 | [acl] | nope ? |
| 22:38.50 | [acl] | boo |
| 22:49.53 | *** join/#htc-linux rajkosto (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
| 22:51.02 | *** join/#htc-linux Bry8Star (~Bry8Star@gateway/tor-sasl/bry8star) |
| 23:03.46 | WisTilt2 | <jonpry> anyone try with gpu1 larger than 8mb, 13 perhaps? <- need to to try that? what we looking for |
| 23:14.55 | *** join/#htc-linux mitsutaka (~mitsutaka@rt.miraclelinux.com) |
| 23:26.39 | WisTilt2 | jonpry: gpu1 @ 13mb stops 3d from working also. gpu1 must be 8mb for whatever reason. |
| 23:29.10 | *** join/#htc-linux arif-ali (~arif-ali@94-192-24-56.zone6.bethere.co.uk) |
| 23:35.34 | *** join/#htc-linux ftoz (~root@85.162.196.208) |
| 23:41.53 | arrrghhh | WisTilt2, jonpry to answer your question the tests were all done on the same gb system image, with the same apps installed/data.img |
| 23:42.57 | WisTilt2 | mucho |
| 23:43.12 | arrrghhh | i did my best to keep all the tests equal ;) |
| 23:43.47 | WisTilt2 | im getting nice high numbers but dont know why .27 2d is so much higher than .39 |
| 23:44.00 | arrrghhh | higher than what i was scoring? |
| 23:44.07 | arrrghhh | i still need to go and do .39 vanilla |
| 23:44.23 | WisTilt2 | yep but best 2d is 98, far from what you got in .27 |
| 23:44.31 | arrrghhh | strange. |
| 23:44.42 | rpierce99 | did we rule out the 16m/32m thing as the cause of that? |
| 23:44.49 | WisTilt2 | 3d running up in the 215 area |
| 23:45.05 | WisTilt2 | this is with pmem at 32mb now |
| 23:45.14 | WisTilt2 | which seemed to increase it a bit |
| 23:45.38 | *** join/#htc-linux bartman (~bart@2607:f2c0:a000:175:2e0:81ff:fe47:3d01) |
| 23:46.34 | WisTilt2 | arrrghhh im also using the other lib's that fixed textures |
| 23:46.42 | arrrghhh | o right |
| 23:47.21 | WisTilt2 | wow my total quadrant core was 494, not bad at all |
| 23:56.00 | *** join/#htc-linux Bry8Star (~Bry8Star@gateway/tor-sasl/bry8star) |
| 23:56.02 | WisTilt2 | rpierce99: your earlier comment about battery today, is that better than before? |
| 23:56.40 | WisTilt2 | and is that with scbs running |
| 23:57.53 | rpierce99 | scbs is running, but i honestly don't think my model is very good, so I don't know how accurate the meter is |
| 23:58.16 | rpierce99 | it was 92 when i took it off the charger this morning, and i just watched it in the last 15 seconds drop from 45 to 22 |
| 23:58.27 | arrrghhh | oO |
| 23:58.27 | rpierce99 | now back up to 30 |
| 23:58.31 | rpierce99 | 35 |
| 23:58.38 | arrrghhh | you already ran the app, built the model, etc? |
| 23:58.40 | WisTilt2 | need to fully charge, reboot then discharge to say 30% or so, charge back up then use that for the model. |
| 23:58.55 | rpierce99 | yeah that's what i'm doing, going to let it drain tonight |
| 23:58.59 | arrrghhh | ah |
| 23:59.12 | WisTilt2 | that should be good to go then |
| 23:59.17 | rpierce99 | i didn't know which of my old logs was a complete battery cycle, so i just picked the biggest one |
| 23:59.52 | arrrghhh | old logs might be pretty useless. battery's gone thru quite a bit since the last one was taken (i'd imagine) |