IRC log for #htc-linux on 20111205

02:43.36*** join/#htc-linux apt (~apt@rikers.org)
02:43.36*** topic/#htc-linux is Welcome to the HTC Linux project | Community portal & WiKi http://htc-linux.org | For IRC logs, HaRET & kernel mailing lists etc. see http://htc-linux.org/wiki/index.php?title=Contact | The htc-linux.org project is not affiliated with the HTC Corporation | This channel is for development purposes - Join #htc-linux-chat for offtopic
03:11.14*** join/#htc-linux mitsutaka (~mitsutaka@219.143.36.82)
03:18.37*** join/#htc-linux jonpry_ (~jon@c-24-17-200-206.hsd1.wa.comcast.net)
03:21.27jonpry_detule, want to make us a 2d allocator?
03:29.54*** join/#htc-linux mitsutak_ (~mitsutaka@219.143.36.82)
03:35.05d3tul3jonpry_, if i had any inkling of what the hell was goign on i would love to
03:35.48jonpry_its not difficult to understand
03:37.44arrrghhhd3tul3, did you get an answer on the evo4g/tp2 battery thing?
03:38.20d3tul3i got some, but i would love to hear yours as well
03:38.21jonpry_they fit. assuming that is the question
03:38.25arrrghhhthey do fit
03:38.30d3tul3where do you guys get yours?
03:38.34arrrghhhwhen i got my tp2 in, they threw an evo battery in it
03:38.44arrrghhhi used to buy shitty ebay ones, WisTilt2's site sounds better
03:38.48arrrghhhhi btw ;)
03:39.04jonpry_i had a whole pile of $3 ebay ones
03:39.09arrrghhhyea
03:39.14arrrghhh$3 ebay ones is what i used to buy
03:39.15arrrghhhthey worked
03:39.29arrrghhhhaven't bought a batt in a while tho
03:39.39arrrghhhthe donor i got came with a nice seidio
03:39.58arrrghhhbut it doesn't fit quite right, and quite often it would power off & on me
03:40.30jonpry_pretty sure you get the most W/h per $ w/ ebay. but maybe not the most W/h per battery
03:40.57arrrghhhyea
03:41.04arrrghhhthe ebay ones work, that's for sure.
03:41.26d3tul3jonpry_, friday is kind of last day at work for me, i can work with you on something, is there source of someting similar to what you are trying to build
03:41.39jonpry_they are primarily cheaper because they avoid paying the patent licensing
03:42.08jonpry_d3tul3 i'm not sure. its pretty simple. but i don't know what its normally called
03:42.13d3tul3i am just confused coz the ebay ones are advertised as OEM and the photos are of 'htc' branded batteries, but they obviously can't be oem for 3$
03:42.37jonpry_chinese knock offs
03:43.01arrrghhh^^
03:43.08arrrghhhthey'll knock-off anything
03:43.12arrrghhhruthless
03:43.17jonpry_lol
03:43.28arrrghhhtheir iOS knockoffs are always the best
03:43.37arrrghhhi swear foxconn employees just sell the crap
03:43.48arrrghhhthey're usually really good knock-offs.  until you try to use them.
03:44.38jonpry_i considered starting a clandestine battery factory. smuggling batteries is like a many million dollar industry
03:44.52arrrghhhlol
03:46.49jonpry_probably gets confiscated by customs if it has a chinese brand
03:47.50d3tul3later folks gotta make a run to the airport
03:47.59jonpry_cya
03:49.26arrrghhhmake a run eh
03:50.02arrrghhhWisTilt2, you thar?
03:53.37*** join/#htc-linux mitsutaka (~mitsutaka@219.143.36.82)
03:57.45jonpry_arrrghhh, what kind of laptop do you have?
04:00.00arrrghhhi have a cr-48 and an hp pavilion dv6
04:00.23jonpry_which is the 12gb one?
04:00.28*** join/#htc-linux mitsutaka (~mitsutaka@219.143.36.82)
04:00.30arrrghhhdv6
04:00.43arrrghhhcore i7
04:00.58arrrghhh2820QM
04:01.08arrrghhhhas a radeon 6770M w/2gb of video memory too
04:01.43jonpry_do you know what the rest of the model number is by chance?
04:01.53arrrghhhyea 1 sec
04:02.23jonpry_is it 1080p?
04:02.28arrrghhhyea
04:02.33arrrghhhi got the matte screen
04:02.38arrrghhhwhich i really wanted....
04:03.21arrrghhhLM720AV
04:03.23arrrghhhis the product code
04:03.35arrrghhhdv6t Quad Ed
04:03.47jonpry_i'm looking at an asus n53sv-dh72
04:03.51arrrghhhasus is good
04:04.09arrrghhhi was seriously considering one, until i found out it's impossible to get matte on their consumer displays.
04:04.22arrrghhhi'm a picky bastard.
04:05.01arrrghhhthe dual graphics is kinda shitty too
04:05.05arrrghhhi would avoid it if you can...
04:05.21jonpry_<PROTECTED>
04:05.24arrrghhhyea
04:05.26arrrghhhmy lappy has it
04:05.39jonpry_the intel hd + radeon?
04:05.42arrrghhhthey finally released a BIOS update that mostly fixes it
04:05.52arrrghhhyea, the core i7 sandy bridge poop has the on-board gfx
04:05.58arrrghhhand then a dedicated 2gb radeon
04:06.10jonpry_i kind of like the asus because its an nvidia. i had lots of trouble with the radeon hd stuff
04:06.11arrrghhhit can dynamically switch too, but only for Direct3D apps.
04:06.15arrrghhhyea
04:06.20arrrghhhi used to be all about nv...
04:06.30arrrghhhthat was one thing i was leery about
04:06.40jonpry_my 6570m won't run catia properly
04:06.44arrrghhhbut since they've been absorbed by AMD, i think they've gotten better
04:06.51arrrghhhthat's a pretty new card, damn.
04:07.39jonpry_just like linux drivers are not engineering capable. firegl kind of thing
04:07.57arrrghhhyea
04:08.15jonpry_does nv still make the quadro's?
04:08.20arrrghhhyea
04:08.24arrrghhhfor 'workstations'
04:08.33arrrghhhusually business line laptops
04:08.47WisTilt2hey arrrghhh im here now. grand kids just left so all is quiet again.
04:08.57jonpry_used to be you could turn a geforce into a quadro by removing a resistor
04:09.48arrrghhhheh, nice.
04:10.40WisTilt2whats up, you ping me?
04:10.56arrrghhhyea, just wondering if you made any progress on that monster kernel
04:12.08WisTilt2didnt work on it at all since we left it friday night.  this weekend was our annual company toy drive so spent the weekend doing that.
04:12.32arrrghhhoh, that's cool
04:12.40arrrghhhdid the toy drive go well?
04:12.41WisTilt2beautiful weather, 55degs sunny.  last year was miserable cold fog
04:12.50arrrghhhmy company's raised sooo much money with all the drives they did this year...
04:13.02WisTilt2yeah we took in nearly 10k toys, tons of canned food etc.
04:13.08arrrghhhawesome!
04:13.54WisTilt2we deliver it later this week to unfortunate families around the county.
04:14.08arrrghhhvery cool
04:15.35WisTilt2ill mess with the clocks more tomorrow at the office.  too tired tonight and the grand kids wore down what energy i had left:)
04:16.05arrrghhhhaha, fair enough.
04:16.16arrrghhhjust very strange that neocore would randomly score so well
04:16.39arrrghhhbut other apps didn't really seem to show it
04:17.08WisTilt2yeah i looked at the divisors and they are being changed by something with no logical value so need to figure that out.
04:17.15arrrghhhhrm
04:17.16arrrghhhok
04:19.24WisTilt2was that 36fps you got on the #59 or #60 build you remember?
04:19.48arrrghhhuhm
04:20.11arrrghhhi think 60
04:20.13arrrghhh36.3
04:20.19arrrghhhinsane
04:20.32arrrghhhif it would be that consistently, i'm sure most 3D apps would be fine
04:20.36WisTilt2then you got stuck at 27 or so and back down to 20-21?
04:22.31jonpry_did you try birds?
04:22.31arrrghhhback down to 20-22
04:22.37arrrghhhjonpry_, some rio version
04:22.40arrrghhhit was choppy
04:22.44arrrghhhAFAIK the same
04:22.54arrrghhhplus quadrant scored the exact same as 'normal'.
04:24.44WisTilt2on you on kernel #60 right now?
04:26.47arrrghhhyessir
04:26.51arrrghhhbeen on it since friday
04:26.55arrrghhhworks well, smooth for sure
04:27.03arrrghhhthis has mem OC as well rigth?
04:27.05arrrghhhright*
04:27.08WisTilt2how long ago since you booted it?
04:27.18WisTilt2yes 30% oc
04:27.25arrrghhhlemme see
04:27.31arrrghhhoh i dropped it this morning
04:27.35arrrghhhbattery popped out :S
04:27.51arrrghhhonly been up about 10 hrs
04:27.59arrrghhhbatt @ 93% :D
04:28.00WisTilt2see if dmesg still has the PLL table at the beginning of bootup.  i need to take a look at that again on your device
04:28.03arrrghhhbattery is awesome.
04:28.12arrrghhhok
04:28.13WisTilt2yeah battery life should be very good
04:28.14arrrghhhit probably won't
04:28.15arrrghhhbut i'll look
04:28.34arrrghhhyea, batt is amazing...
04:28.47WisTilt2you running scbs on that ?
04:29.08arrrghhhno, i haven't mucked with that rootfs stuff or done a calibration in very long...
04:29.50WisTilt2k. scbs only draws another 2ma which is not all that much.  best i've got with scbs and this pm setup is .58% hr overnight
04:30.10WisTilt2thats with gsensor turned off which helps a bunch
04:30.19arrrghhhyou don't want the dmesg if it doesn't have that pll table right?
04:30.37arrrghhhit appears to have scrolled off the buffer
04:30.50WisTilt2no, need the table, the one that shows the 4 PLL's not the actual clock freq table
04:30.58arrrghhhi can reboot
04:31.02WisTilt2ok
04:31.28WisTilt2its different on cdma for sure, just want to verify that 1 more time with another 400
04:32.19arrrghhhk rebootin now
04:33.42arrrghhhWisTilt2, i think scbs in the kernel helps too
04:33.49arrrghhhwinmo was pretty close on the %
04:33.57arrrghhh88%
04:36.01WisTilt2without the daemon in rootfs it shouldn't be doing anything though. i know my battery readings are dead on reality with scbs. i wont leave home without it:)
04:36.19arrrghhhWisTilt2, http://pastebin.com/E7gEcfRn
04:36.27arrrghhhhahaha
04:36.41arrrghhhyea, i probably should take a peek back on that thread and do the dance to get it workin again
04:36.47arrrghhhit did help a ton.
04:37.06arrrghhhlast time i used it, it seemed to create other issues... but that was a while ago.
04:37.10WisTilt2oh you running oc'd.  did you get the 36fps oc'd or at 528mhz?
04:37.21arrrghhhuhm
04:37.23arrrghhhprobably oc'd
04:37.30arrrghhhbut it went all over
04:39.00WisTilt2try turning of acpu oc and run neocore again.  i think you had it off.  with acpu oc'ing i think that is what is changing my clocks.
04:39.22arrrghhhhrm
04:39.23arrrghhhok
04:39.34WisTilt2then let me see that dmesg, or just the pll table
04:39.39arrrghhhsure
04:41.31arrrghhhthe table right after ACPU running at 614400 KHz?
04:42.07WisTilt2no, the one with PLL0 @ PLL1 @ etc
04:43.24WisTilt2just paste it here, its only 4 lines
04:43.37arrrghhhah i see it
04:43.43arrrghhhok
04:45.08arrrghhh12-04 21:34:04.165 INFO : PLL0 @ f8005300: MODE=00000007 L=0000000c M=00000004 N=00000005 freq=245760000 Hz (245 MHz)12-04 21:34:04.165 INFO : PLL1 @ f800531c: MODE=00000007 L=00000032 M=00000000 N=00000001 freq=960000000 Hz (960 MHz)12-04 21:34:04.165 INFO : PLL2 @ f8005338: MODE=00000007 L=00000020 M=00000000 N=00000001 freq=614400000 Hz (614 MHz)12-04 21:34:04.165 INFO : PLL3 @ f8005354: MODE=00000000 L=0000000a M=00000006 N=00000019 freq=
04:45.08arrrghhh196608000 Hz (196 MHz)
04:45.11arrrghhhOo
04:45.14arrrghhhthat pasted like shite
04:45.20WisTilt2thats ok i can read it
04:45.25arrrghhhlol ok
04:45.30WisTilt2you're still oc'd
04:45.52arrrghhhcrap i am.
04:46.03arrrghhhi thought i saved that startup...
04:46.04arrrghhhwth
04:46.21WisTilt2removed the cmd line?
04:46.49*** join/#htc-linux Rob2223 (~Miranda@p4FFF098F.dip.t-dialin.net)
04:47.43arrrghhhyea
04:47.47arrrghhhlemme make sure i saved it
04:48.13arrrghhhok now i'm really confused
04:48.23arrrghhhdid #60 have OC hardcoded?
04:48.31arrrghhhi did save the startup.  there's no OC statements in my startup
04:48.59WisTilt2no, hardcoded was many kernels back until i got the right clocks
04:49.03arrrghhhHRM
04:49.04arrrghhhoops
04:49.05arrrghhhhrm
04:49.07arrrghhhlemme boot again
04:50.08WisTilt2memory is oc'd and gpu is running off its own pll in this one (i think).  we did so many tests lol
04:50.18arrrghhhhahaha
04:50.20arrrghhhgood times ;)
04:50.33WisTilt2yeah they are
04:51.37arrrghhhACPU running at 528000 KHz
04:51.38arrrghhhboom
04:51.42arrrghhhPLL0 @ f8005300: MODE=00000007 L=0000000c M=00000004 N=00000005 freq=245760000 Hz (245 MHz)
04:51.45WisTilt2now we're talking
04:51.48arrrghhhPLL1 @ f800531c: MODE=00000007 L=00000032 M=00000000 N=00000001 freq=960000000 Hz (960 MHz)
04:51.53arrrghhhPLL2 @ f8005338: MODE=00000007 L=00000037 M=00000000 N=00000001 freq=1056000000 Hz (1056 MHz)
04:51.58arrrghhhPLL3 @ f8005354: MODE=00000000 L=0000000a M=00000006 N=00000019 freq=196608000 Hz (196 MHz)
04:52.03arrrghhhPLL3 is the GPU now right?
04:52.27WisTilt2yep but 196mhz is only at boot.  i set it up when hw3d inits
04:52.34arrrghhhah
04:52.43WisTilt2this build its running at 250
04:53.07WisTilt2now see what you get in neocore
04:53.36arrrghhhok
04:53.38jonpry_why would they run the gpu at 1/5 of its power?
04:53.56arrrghhhcuz it's winmo
04:54.03arrrghhhwhat is the gpu used for thar
04:54.05arrrghhhnothing.
04:54.30jonpry_our 3d scores are different from hero etc?
04:54.33WisTilt2the way the regular code is, gpu is running off pll0/4 jonpry.  so i think thats just a coding error that never got looked into
04:54.49WisTilt2or never notice i dont know
04:55.03WisTilt2should be off pll1/4, that would be 240mhz
04:55.04arrrghhhjonpry_, never really looked
04:55.32arrrghhhlooks like 34-35
04:55.45WisTilt2you're getting 34+ again now?
04:55.51arrrghhhWisTilt2, sorry
04:55.57arrrghhhgoogling for hero scores
04:56.03arrrghhhwaiting for it to settle ;)
04:56.23WisTilt2before you run it do you kill all apps you can?
04:56.37arrrghhhwell i don't have many installed
04:56.38arrrghhhbut i can try
04:56.56jonpry_if you believe in scores getting locked into zones. then 34 would mean a great deal of frames are better than 1/60 sec, and the rest are probably  very close
04:57.33WisTilt2too bad neocore doesn't show fps in realtime
04:57.40arrrghhh34.0 running cm6.1, kernel #589, oc'd to 750mhz
04:57.42arrrghhhWisTilt2, no joke.
04:57.48arrrghhhi was thinking the same thing lol
04:58.25jonpry_or is this a 70hz panel?
04:58.33WisTilt2what device is that 34.0 on?
04:58.41arrrghhhhero ^^
04:58.49arrrghhhWisTilt2, 21.5...
04:58.50WisTilt2yes our panels are 50-70hz thats it
04:59.02WisTilt2so we're never going higher than 35
04:59.09WisTilt2give or take a couple
04:59.21jonpry_i still don't understand that
04:59.31jonpry_why can't we go to like 70
05:00.24WisTilt2i never understood that either but framerate is always going to be 1/2 refresh rate.
05:00.47jonpry_until we fix it maybe
05:02.02arrrghhh20.6 w/sound
05:02.24WisTilt2should be fixable.  70hz is still 70 times per second no matter which part of the waveform you trigger on so makes no sense
05:02.50WisTilt2arrrghhh what did you do friday night that got you back up to 27.7 or so after it dropped from 36fps?
05:03.02arrrghhhi don't know, honestly
05:03.14arrrghhhtypically neocore would score great if i ran it first thing
05:03.16arrrghhhthen it wouldn't again.
05:03.38jonpry_i think they have some stupid thing that like doesn't start drawing until a vsync pulse comes. so you have to finish drawing by the time the next one comes or you'll miss it
05:03.38arrrghhhi don't know what brought it back up, perhaps a sleep/wake cycle...
05:03.59WisTilt2well tomorrow ill make a kernel with lots of logging for the divisors so maybe i can find what is changing them and when.
05:04.06arrrghhhcool
05:04.44arrrghhhtomorrow's gonna be nuts.
05:04.50arrrghhhso is tuesday....
05:04.55jonpry_there shouldn't be any problem with starting the draw whenever the last one is done. provided we don't actually draw faster than 70hz at any point
05:05.12WisTilt2jonpry that is probably whats happening.  almost acts like there is some deliberate delay to skip 1 vsync each time.
05:06.37WisTilt2np arrrghhh.  im in the office tomorrow but tue-wed im out overseeing an interesting project we got into.  maybe in the evening we can hit it again.
05:07.27arrrghhhsounds good
05:07.32arrrghhhgoing to be working late mon/tue
05:07.37arrrghhhmight have some downtime, not sure when tho lol
05:07.57arrrghhhDR testing/component fail testing monday, then cutting the next business unit to the new call center tuesday.
05:08.01WisTilt2ping me if you get on, if not it will wait
05:08.12WisTilt2damn, sounds like fun
05:08.15arrrghhhsounds like a plan
05:08.26arrrghhhgood times indeed.  if only i was hourly, lol
05:08.45WisTilt2at&t is turning up another couple gigabit lines for us on thursday also so that should be fun
05:09.25arrrghhhnice
05:09.33WisTilt2easier than moving to a new call center im sure
05:09.40arrrghhhyea we got some 2gbit backhaul to our DR site now
05:09.47arrrghhhmetroethernet i think?
05:09.58arrrghhhour 24hr dept is in house
05:09.59WisTilt2at&t optiman or what?
05:10.05arrrghhhi'm actually not sure.
05:10.10arrrghhhthey don't let me touch a lot of the core stuff
05:10.19arrrghhhi ask questions and look at things, still learning :P
05:10.34WisTilt2smart.  let someone else break it:)
05:10.41arrrghhhthey mostly pulled me onto this team for my server/linux experience.
05:10.42arrrghhhheh
05:16.31WisTilt2jonpry you dont think this has anything to do with this fake_vsync function do you? i really dont know what thats for.
05:17.27jonpry_i don't either
05:17.45jonpry_i think we are using real vsync though
05:19.02WisTilt2we have a vsync irq handler but also this fake vsync that sets up hrtimer
05:20.01WisTilt2looks like the fake vsync is what triggers the interrupt that the handler works off so no telling what timer value that is set to
05:24.20jonpry_are 2d apps pegged at 30 as well?
05:24.44arrrghhhjonpry_, fps2d seems to say so
05:24.49*** join/#htc-linux mitsutaka (~mitsutaka@219.143.36.82)
05:24.51arrrghhhbut if you turn off the screen it goes to like 90 or something
05:29.00jonpry_<PROTECTED>
05:29.01jonpry_<PROTECTED>
05:29.01jonpry_<PROTECTED>
05:29.41jonpry_this is how gralloc updates the screen. in theory it should return immediately. not sure if it does, or even how it calls msm_fb code
05:32.07jonpry_probably calls msmfb_pan_update()
05:33.58jonpry_function should block if the old buffer isn't dma'd yet. but it doesn't need to block for vsync or anything
05:34.10WisTilt2im looking at pan update and dont know about this 50ms wait on vsync.
05:34.37jonpry_shouldn't wait at all
05:35.22jonpry_but i don't see what in that code would actually wait for anything
05:35.35WisTilt2why does pan update call request vsync?  the callback that was setup should trigger that on vsync
05:36.51WisTilt2the 50ms supposedly is the wake lock/4 but that doesnt delay anything
05:37.22jonpry_request_vsync probably does it
05:37.22WisTilt2i mean wakelock/20 not 4
05:37.22*** join/#htc-linux rajkosto (~rajkosto@2001:470:d76b:da7a:e53a:7443:ff9d:8299)
05:40.25jonpry_and that fake vsync should probably happen asap
05:40.35arrrghhhoh well.  bedtime, talk to you gents tomorrow.
05:40.43WisTilt2nite arrrghhh
05:41.24WisTilt2that hrtimer is going to delay that to whatever timer value is in it though.  shouldnt have any timer at all i'd think
05:41.42jonpry_for now it gets us a new thread
05:41.49jonpry_can't just remove it
05:42.07WisTilt2i mean remover timer and just make the fake call right away
05:42.42jonpry_i dunno. i think the code won't be run in the correct context
05:42.50jonpry_might work, maybe not
05:43.14jonpry_easier to just set the timer to expire now
05:43.20*** join/#htc-linux kiozen (~kiozen@ppp-93-104-68-92.dynamic.mnet-online.de)
05:43.39WisTilt2job for tomorrow.  im beat and going to hit the sack.
05:44.12jonpry_k, good night
05:44.46WisTilt2catch you tomorrow
05:50.33*** join/#htc-linux Rob2222 (~Miranda@p4FFF28BE.dip.t-dialin.net)
05:57.30*** join/#htc-linux Alex[sp3dev] (~AndChat@82.179.218.138)
06:23.03toastcfhjonpry_, seen the display code still supports 7k and none overlay devices
06:23.27toastcfhthink u gotta use ashmem tho (if ur not already
06:24.57toastcfhidunno if 7k would support ion tho
06:37.15*** join/#htc-linux rzk (~rzk@95-24-54-101.broadband.corbina.ru)
06:42.54jonpry_toastcfh, different thing going on. trying to use glTexImage2d to allocate pmem
06:56.46*** join/#htc-linux kiozen (~kiozen@p5DDF1133.dip.t-dialin.net)
07:43.40*** join/#htc-linux balans2 (~user@82-170-217-205.ip.telfort.nl)
07:45.46*** join/#htc-linux kiozen (~kiozen@p5DDF1133.dip.t-dialin.net)
07:56.51*** join/#htc-linux kiozen (~kiozen@p5DDF1133.dip.t-dialin.net)
08:01.24*** join/#htc-linux mitsutaka (~mitsutaka@219.143.36.82)
08:04.44*** join/#htc-linux mitsutaka (~mitsutaka@219.143.36.82)
08:05.02*** join/#htc-linux LjL (~ljl@unaffiliated/ljl)
08:08.11*** join/#htc-linux mitsutaka (~mitsutaka@219.143.36.82)
08:09.46*** join/#htc-linux mitsutaka (~mitsutaka@219.143.36.82)
08:10.09*** join/#htc-linux kiozen (~kiozen@p5DDF1133.dip.t-dialin.net)
08:11.29*** join/#htc-linux mitsutaka (~mitsutaka@219.143.36.82)
08:12.27*** join/#htc-linux mitsutaka (~mitsutaka@219.143.36.82)
08:13.39*** join/#htc-linux kiozen (~kiozen@p5DDF1133.dip.t-dialin.net)
08:29.14*** join/#htc-linux lamikr (lamikr@nat/nokia/x-ewkdwufghurvlqod)
08:42.53*** join/#htc-linux ychavan (ychavan@nat/redhat/x-jeevdnuatgkurrbq)
08:45.05*** join/#htc-linux kiozen (~kiozen@p5DDF1133.dip.t-dialin.net)
08:50.52*** join/#htc-linux unilinky (~unilinky@wikipedia/harddisk/bot/unilinky)
08:58.34*** join/#htc-linux kiozen (~kiozen@p5DDF1133.dip.t-dialin.net)
08:59.53*** join/#htc-linux kiozen (~kiozen@p5DDF1133.dip.t-dialin.net)
09:11.12*** join/#htc-linux dr1337 (~textual@112.97.96.58.static.exetel.com.au)
09:35.52*** join/#htc-linux kiozen (~kiozen@p5DDF1133.dip.t-dialin.net)
09:55.21*** join/#htc-linux lardman (~lardman@Maemo/community/contributor/lardman)
10:05.20*** join/#htc-linux rajkosto (~rajkosto@2001:470:d76b:da7a:717c:8d4a:8b07:3e7f)
10:29.32*** join/#htc-linux LjL (~ljl@unaffiliated/ljl)
10:40.40*** join/#htc-linux dr1337 (~textual@112.97.96.58.static.exetel.com.au)
10:57.39*** join/#htc-linux Andreyxxl[HD2EU] (~Andreyxxl@94.52.236.39)
11:44.39*** join/#htc-linux markuskon (~markuskon@212.201.135.109)
11:47.40*** join/#htc-linux mickeyl (~mickey@80.81.242.146)
12:28.27*** join/#htc-linux d3tul3 (~detule@pool-96-234-141-27.bltmmd.east.verizon.net)
12:51.32*** join/#htc-linux LjL (~ljl@unaffiliated/ljl)
12:59.48*** join/#htc-linux rajkosto (~rajkosto@cable-94-189-246-148.dynamic.sbb.rs)
13:02.52*** join/#htc-linux markuskon (~markuskon@dslb-188-109-213-168.pools.arcor-ip.net)
13:04.03*** join/#htc-linux mgross029 (c0234f46@gateway/web/freenode/ip.192.35.79.70)
13:04.33*** join/#htc-linux Rajko (~rajkosto@2001:470:d76b:da7a:717c:8d4a:8b07:3e7f)
13:04.52*** join/#htc-linux GNUtoo (~gnutoo@host40-58-dynamic.116-80-r.retail.telecomitalia.it)
13:46.41*** join/#htc-linux MethoS- (~clemens@134.102.106.250)
13:53.51*** join/#htc-linux dobrin (~dobrin@85.91.150.26)
14:19.38*** join/#htc-linux NeoMatrixJR (~chatzilla@173-20-63-62.client.mchsi.com)
14:22.06*** join/#htc-linux rpierce99 (~rpierce99@96-42-102-103.dhcp.stcd.mn.charter.com)
15:02.36*** join/#htc-linux balans2 (~user@82-170-217-205.ip.telfort.nl)
15:10.28*** join/#htc-linux Cotulla (~myfakemai@nat100-255-205-109.tvoe.tv)
15:23.30*** join/#htc-linux Alex[sp3dev] (~alexander@178.176.115.155)
15:32.24*** join/#htc-linux kiozen (~kiozen@p5DDF1133.dip.t-dialin.net)
15:34.19*** join/#htc-linux dobrin (~dobrin@85.91.150.26)
15:52.02*** part/#htc-linux Alex[sp3dev] (~alexander@178.176.115.155)
15:52.48*** join/#htc-linux LordDeath (~LordDeath@cable-81-173-164-253.netcologne.de)
16:05.57*** join/#htc-linux kiozen (~kiozen@ppp-93-104-68-92.dynamic.mnet-online.de)
16:14.24*** join/#htc-linux emwe (~mweirauch@cable-86-56-10-252.cust.telecolumbus.net)
16:19.57*** join/#htc-linux AstainHellbring (~AstainHel@unaffiliated/astainhellbring)
17:20.08*** join/#htc-linux vincewies (4463ed13@gateway/web/freenode/ip.68.99.237.19)
17:22.09*** join/#htc-linux furtardo (~mks@nat/yahoo/x-gltixsgugnegseny)
17:27.43*** join/#htc-linux WisTilt2 (~wisgreg@wireless251.wirelesstcp.net)
17:28.10*** join/#htc-linux rob_w (~bob@ppp-188-174-111-104.dynamic.mnet-online.de)
17:28.11*** join/#htc-linux rob_w (~bob@unaffiliated/rob-w/x-1112029)
17:31.54*** join/#htc-linux rob_w (~bob@unaffiliated/rob-w/x-1112029)
17:38.39*** join/#htc-linux XirXes (~XirXes@67-2-1-110.slkc.qwest.net)
17:46.24*** join/#htc-linux |Jeroen| (~jeroen@d5152B25B.access.telenet.be)
17:50.16*** join/#htc-linux paulk (~paulk@lib33-1-82-233-88-171.fbx.proxad.net)
17:53.44*** join/#htc-linux helicopter88 (~helicopte@host100-231-dynamic.45-79-r.retail.telecomitalia.it)
18:12.26*** join/#htc-linux gnutoo_ (~GNUtoo@host40-58-dynamic.116-80-r.retail.telecomitalia.it)
18:26.51*** join/#htc-linux mastermerlin (~Adium@p4FEE5F43.dip.t-dialin.net)
18:27.45*** join/#htc-linux mastermerlin (~Adium@p4FEE5F43.dip.t-dialin.net)
18:36.40*** join/#htc-linux swc|666 (~gecko@173-10-106-161-BusName-Washington.hfc.comcastbusiness.net)
18:36.49*** join/#htc-linux swc|666 (~gecko@unaffiliated/swc666/x-4934821)
18:47.50*** join/#htc-linux LordDeath (~LordDeath@cable-81-173-164-253.netcologne.de)
18:53.13*** join/#htc-linux arrrghhh (~arrrghhh@unaffiliated/arrrghhh)
18:59.10Blistahya
18:59.50Blistadoes tytung from xda hang around here?
19:02.42*** join/#htc-linux rajkosto (~rajkosto@2001:470:d76b:da7a:717c:8d4a:8b07:3e7f)
19:08.24*** join/#htc-linux Echo31 (~olivier@lan31-9-88-177-158-48.fbx.proxad.net)
19:11.24jonpry_hey WisTilt2
19:11.37WisTilt2Morning
19:12.08jonpry_i tried turning off that request_vsync last night.
19:12.21WisTilt2messing with fb.  changed hrtimer to 1 and no difference.  something with number pixels though
19:12.26jonpry_sort of works but the framebuffer hangs randomly
19:12.49jonpry_i think it crashes mdp
19:13.13WisTilt2yeah off it doesnt like, set it to 1 which is monotonic and it stays happy.  im thinking we have a bits per pixel issue maybe, tracing that now
19:13.34WisTilt2does android default to 32bbp or what?
19:14.19jonpry_i dunno what xdandroid does. cm7 was trying to make a 32bpp fb. but i hacked the flinger to get it more or less running at 16
19:15.04*** join/#htc-linux sbryan12144 (ad514fc2@gateway/web/freenode/ip.173.81.79.194)
19:15.10jonpry_i have some newer msm_fb code that looks not terribly hard to integrate
19:15.19WisTilt2look at the dma section - what value is BYTES_PER_PIXEL?  panel is initialized to 16bpp
19:16.16jonpry_its 2 unless someone changes format to 32bpp
19:17.19WisTilt2this is somewhat confusing but i still dont see where hw vsync irq is really being serviced.  it all seems to only come from that fake vsync off the hrtimer
19:17.25jonpry_i think the most straightforward way to fix this is to just run pan_update in a workqueue
19:17.52WisTilt2thats an idea
19:17.53detulehey guys
19:18.06jonpry_hey
19:18.10detulejonpry_, i am about to refresh the 3.1 tree
19:18.27jonpry_i dunno what all this crud is for in pan_update but getting rid of it seems to cause lots of problems
19:18.44jonpry_to a new minor?
19:18.58detuleno no, just the gitorious 3.1 tree
19:19.12jonpry_oh pushing?
19:19.15detuleyeah
19:19.20jonpry_cool
19:19.45detulealso updated to 3.1.4 but made sure not to bring in the history (sorry i botched that with the 3.0 tree)
19:20.02jonpry_nice. yeah i think the history is not helpful
19:20.47jonpry_almost time for a 3.2 kernel :p
19:21.23detulelet them get out of rc
19:21.28jonpry_we probably need to switch to this clkdev driver. its going to get more and more complicated to run newer kernels
19:22.07detulepushed
19:22.24jonpry_i mostly got this threading disaster is surfaceflinger sorted out
19:24.29*** join/#htc-linux balans2 (~user@82-170-217-205.ip.telfort.nl)
19:36.09sbryan12144does anyone know anything about haret?
19:38.21*** join/#htc-linux x1o (57f54144@gateway/web/freenode/ip.87.245.65.68)
19:39.21*** part/#htc-linux x1o (57f54144@gateway/web/freenode/ip.87.245.65.68)
19:41.15*** join/#htc-linux markuskon (~markuskon@dslb-188-109-213-168.pools.arcor-ip.net)
19:41.54*** join/#htc-linux rzk (~rzk@95-24-54-101.broadband.corbina.ru)
20:36.40*** join/#htc-linux Alex[sp3dev] (~alexander@178.176.115.155)
20:43.20Alex[sp3dev]WisTilt2: hey. what about gpu clock resetting? fixed it? or maybe we should put a timer that will just set it to the desired value each N msec when hw3d file is open?
20:51.24*** join/#htc-linux avinashhm (~avinash-h@192.91.66.186)
20:55.24WisTilt2Alex[sp3dev]: i think we need to probably set the registers each time hw3d is opened.  it seems more of a problem when acpuclock is being oc'd from the cmd line also instead of using 1 static freq
21:22.16*** part/#htc-linux Alex[sp3dev] (~alexander@178.176.115.155)
21:36.10WisTilt2rpierce99: if you are bored, can you give this kernel a neocore test on your 400?
21:37.29rpierce99yep
21:39.45*** join/#htc-linux helicopter88 (~helicopte@host100-231-dynamic.45-79-r.retail.telecomitalia.it)
21:46.33*** join/#htc-linux LjL (~ljl@unaffiliated/ljl)
21:51.54rpierce9923.8
21:52.17WisTilt2not bad
21:52.21WisTilt2with or without sound?
21:52.23rpierce99my best
21:52.24rpierce99without
21:52.37WisTilt2should hang around 24fps +/-
21:52.38rpierce99and i do have the oc line in startup, i know there was some discussion of that
21:53.14WisTilt2how much oc?  that was my next thing to have you do, oc it up to maybe 672 no higher and see if fps changes
21:53.21rpierce99614400
21:54.04WisTilt2614 up to 672 should increase it i think
21:54.37WisTilt2at 614 your best was around 21?
21:54.46rpierce99previously 21.8 or so
21:58.58detulei take it this new kernel has the ondemand adjustments
21:59.05detuleperhaps you are seeing ondemand increase + cmd line oc
21:59.15detulei score ~23 with no oc
21:59.38WisTilt2detule is that on this new kernel?  i assume you dl'd it:)
21:59.50detuleno no, i mean stock autobuild
22:00.21WisTilt2hmm, try this one if you can.  should be around 24 or so without any oc.  not sure if oc'ing will increase it at this point
22:00.24detulei am saying 23.8 is not significantly over 23, it could be just his cmd line OC that's causing it
22:00.48rpierce99is 676800 the proper multiple?
22:01.13detulei will later tonight when i get home I am about to punch out of the office
22:01.13WisTilt2672000
22:01.21WisTilt2id go with that
22:01.34WisTilt2next jump would be 691200
22:02.35detulewhat i can try though is stock + oc for comparison
22:02.52WisTilt2detule: ok np.  yes im setting the gpu registers at hw3d enable now so seeing if it will keep things at a constant rate now
22:03.06WisTilt2yes try that if you can for a baseline
22:03.16detulerpierce99, what's your cmdline oc parameter?
22:03.43rpierce99it was 614400, i just changed it to 672000
22:03.49rpierce99i'll try stock next
22:04.04detulei mean the syntax :)
22:04.11detulei've never oc-ed android
22:04.18rpierce99haha yeah i had to google it
22:04.55rpierce99acpuclok.oc_freq_khz=
22:04.58rpierce99oops
22:05.03rpierce99acpuclock
22:06.32detulerpierce99,  shouldn't  it be acpuclock-arm11
22:06.58emwe.35 stock, no oc (because not added), 22.7fps w/o sound. just fyi.
22:07.28rpierce99http://xdandroid.com/wiki/FAQ#How_do_I_overclock.3F
22:07.35detulethat's not relevant to .39
22:07.42rpierce99no one told me that :)
22:07.45detuleperhaps WisTilt2 can chime in
22:09.26detuleshould be able to check the sysfs entry right
22:09.28WisTilt2acpuclock-arm11.oc_freq_khz=
22:09.38rpierce99facepalm
22:09.53WisTilt2thats for .39 and up, .27 i thik is still like rpierce99 has it
22:10.21rpierce99that explains the 23.9 i just pulled
22:11.33detulethat's still very good for stock freq, better than anything i've seen on the autobuild so whatever WisTilt's doing is working
22:12.28detulei dont think my phone likes 672
22:12.33detuleit's dragging
22:12.39detulestutter stutter
22:13.09WisTilt2need to let it settle down well after boot probably.  i usually wait 30s or so after i get the green bars then it flys
22:13.29detulewell it just rebooted me to winmo
22:13.35detulek calling it a day later folks
22:13.42WisTilt2yeah that sounds like it doesnt like that much oc
22:13.51WisTilt2cul
22:14.35WisTilt2rpierce99 so sounds like you haven't been oc'd on .39 so if 672 gives you probs then go back to 614 and check it.  you've been at 528 all this time
22:17.07jonpry_dur. looks like i can only open and mmap /dev/pmem_gpu1 a single time
22:19.34*** part/#htc-linux Cotulla (~myfakemai@nat100-255-205-109.tvoe.tv)
22:19.40jonpry_i'm very confused as to how your supposed to use this pmem driver
22:21.39rpierce9924.3fps
22:21.58rpierce99@672
22:22.35*** join/#htc-linux jonpry (~jon@unaffiliated/jonpry)
22:23.16rpierce9924.6fps on second run
22:24.19detulejonpry, what if you change that no_allocator =0
22:24.46jonprythe pmem pool has no_allocator=1
22:25.13detuleso that means one thing at a time
22:25.15detuleright?
22:26.30jonprygralloc normally uses this PMEM_CONNECT thing to do it
22:28.07detuleyeah but it also does PMEM_MAP
22:28.45jonpryso i want the same effect as however it does it. but not out of the pool.
22:28.46jonpryhttp://gitorious.org/xdandroid-eclair/xdandroid-hardware_msm7k/blobs/froyo/libgralloc/gralloc.cpp#line344
22:29.03jonpryi am rewriting the if(){} block at that location
22:29.08WisTilt2rpierce99 so it didn't make a huge jump oc'd thats good and what i was hoping to see
22:29.57WisTilt2jonpry doesn't no_allocator only need to be set if its cached?
22:30.53jonpryi have no clue. i think gpu1 is setup the right way. actually we probably want to switch to cached and use explicit flushes.
22:31.22jonpryso i'm wondering if ioctl(fd, PMEM_CONNECT, gpu1_fd); would even work
22:31.37jonpryunfortunately its difficult to try
22:32.27detulei don't think no_allocator has to do with cached or not
22:32.31detuleit just means that pmem doesn't manage it
22:32.43detulewhenever someone requests that pmem -> pmem driver just gives it all up
22:32.48detuleand sets a flag that says allocated
22:32.54detulenothing else can request anything from it
22:33.00detuleon release it unsets the allocated flag
22:33.10jonpryunless you use connect and map?
22:34.12jonpryalso would fd = open("/dev/pmem", O_RDWR, 0); be correct or would it also open /dev/pmem_gpu1 ?
22:34.24WisTilt2no_allocator is an indicator whethere maps of that region should be cached or not
22:35.06jonprythats not .cached = 1
22:35.08detuleWisTilt2, that's the wrong line
22:35.11detuleit's this "/* indicates the region should not be managed with an allocator */"
22:35.15*** join/#htc-linux [acl] (~abel@96.246.167.90)
22:35.33*** join/#htc-linux Echo31 (~olivier@lan31-9-88-177-158-48.fbx.proxad.net)
22:35.45detulei think map goes through pmem_allocate, and this is the relevant bit https://gitorious.org/~detule/linux-msm-rhod/detules-linux-msm-rhod/blobs/htc-msm-2.6.39/drivers/staging/dream/pmem.c#line391
22:37.00WisTilt2guess im reading this wrong but this is the line im talking about->
22:37.01WisTilt2unsigned no_allocator;
22:37.01WisTilt2/* indicates maps of this region should be cached, if a mix of
22:37.01WisTilt2<PROTECTED>
22:37.01WisTilt2<PROTECTED>
22:37.26WisTilt2ah, comment is above that you're saying?
22:37.30detuleyes
22:37.39WisTilt2im going back to gpu work, you guys sort that out
22:38.28detuleno_allocator=1 is an easy out for pmem.c
22:38.34WisTilt2rpierce99 can you try that at 614 and see how little it drops also.  i think we got the registers staying like i want them
22:38.40jonpryurg
22:48.41rpierce9924.0 on the first run @ 614400
22:49.52rpierce9924.3 second run
22:50.05detulejonpry, so this PMEM_MAP is what managing the memory within that one file/fd
22:50.27WisTilt2rpierce99 what was it without oc'ing?
22:50.44rpierce9924.8
22:50.45rpierce99err
22:50.46rpierce9923.8
22:51.24WisTilt2not much change good.  you're seeing increase only from memory and cpu getting bumped up with oc'ing, gpu is staying the same freq
22:51.57WisTilt2now i can work from here since nothing is jacking with the gpu now
23:01.52*** join/#htc-linux Rajko (~rajkosto@2001:470:d76b:da7a:717c:8d4a:8b07:3e7f)
23:07.24*** join/#htc-linux jonpry (~jon@unaffiliated/jonpry)
23:08.54*** join/#htc-linux LordDeath (~LordDeath@cable-81-173-164-253.netcologne.de)
23:09.09*** join/#htc-linux ali1234 (~ajbuxton@robotfuzz.co.uk)
23:10.50jonprydetule, i just don't understand how to makes its offset and stuff work with gpu1 instead of the pool
23:11.21*** join/#htc-linux rajkosto (~rajkosto@2001:470:d76b:da7a:717c:8d4a:8b07:3e7f)
23:15.25*** join/#htc-linux d3tul3 (~detule@pool-96-234-141-27.bltmmd.east.verizon.net)
23:22.02d3tul3jonpry, so what all the work is done by the userland allocator
23:22.47jonprythat has always been the case
23:22.55d3tul3that pmem_connect and pmem_map operation just informs pmem.c that we are allocating new information at a particular offset with a particular size
23:23.31jonpryso how do i say that the offset is relative to gpu1?
23:24.00d3tul3isn't that automatic from the fact that you are requesting from pmem/gpu1?
23:24.40jonprythe existing gralloc takes it from the 32mb deal. i am unsure how to explain that i want it from gpu1
23:24.57jonpryi already have a thing that calculates the correct value of offset relative to gpu1 base
23:26.43d3tul3i don't get it you do one mmap operation on gpu1 that returns a base and store a FD
23:27.30d3tul3then you use sAllocator.allocate(size); which returns an offset particular to that base
23:27.46jonpryi have an fd
23:27.56jonpryand sAllocator is not used anymore
23:28.30d3tul3no userland allocator?
23:28.49jonprylibGLES is doing it
23:29.11jonpryso just open("/dev/pmem"); ioctl(fd,PMEM_CONNECT, gpu1_fd) ?
23:31.41d3tul3open will return a fd, not sure what pmem_connect does but perhaps it points the file descriptor to the file on that pm
23:31.47d3tul3em
23:34.17*** join/#htc-linux lamikr (lamikr@nat/nokia/x-nganwugxuuljaimi)
23:38.30d3tul3"open will return a fd" <- lol deep words of wisdom
23:39.25rpierce99that's the kind of wisdom we keep you around for d3tul3
23:39.58jonprysomehow this seems to work. fd = open("/dev/null", O_RDONLY);
23:40.13jonpryso i am officially confused
23:43.57jonpryfigure that out later i guess. everything is now running out of gpu1. fb and surfaces. just need to patch up TexureManager and it should be hitting warpspeed
23:49.19*** join/#htc-linux markuskon (~markuskon@dslb-188-109-213-168.pools.arcor-ip.net)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.