| 00:37.19 | *** join/#htc-linux TheXev (~user@122.sub-174-252-212.myvzw.com) |
| 00:56.59 | *** join/#htc-linux rzk (~rzk@95-27-68-96.broadband.corbina.ru) |
| 01:12.12 | *** join/#htc-linux Bry8Star (~Bry8Star@gateway/tor-sasl/bry8star) |
| 01:25.28 | *** join/#htc-linux TheXev (~user@122.sub-174-252-212.myvzw.com) |
| 01:49.02 | *** join/#htc-linux hardwalker (~hardwalke@122-117-115-146.HINET-IP.hinet.net) |
| 02:13.21 | jonpry | i sort of see how to do it |
| 02:13.31 | jonpry | whoops |
| 02:17.57 | TheXev | thats either about coding... or its code. j/k XD |
| 02:18.29 | jonpry | i think ics could actually work |
| 02:18.43 | jonpry | serious gas in the tank |
| 02:20.48 | *** join/#htc-linux |lippa| (~lippa@ppp118-209-198-87.lns20.mel6.internode.on.net) |
| 02:38.10 | *** join/#htc-linux AstainHellbring (AstainHell@unaffiliated/astainhellbring) |
| 03:25.52 | *** join/#htc-linux TheXev (~user@122.sub-174-252-212.myvzw.com) |
| 03:40.37 | jonpry | detule, ping |
| 03:54.35 | *** join/#htc-linux TheXev (~user@122.sub-174-252-212.myvzw.com) |
| 03:55.11 | *** join/#htc-linux WisTilt2 (~wisgreg@wireless248.wirelesstcp.net) |
| 04:00.23 | jonpry | WisTilt2! |
| 04:00.37 | jonpry | i figured out the pmem thing |
| 04:01.13 | jonpry | at least i know what the problem is. not exactly clear on how to fix it. but should be a small matter of trial and error |
| 04:01.15 | WisTilt2 | hey. |
| 04:01.33 | WisTilt2 | which problem we talking about? i have 112mb free now after booting:) |
| 04:01.46 | jonpry | the adsp, camera, whatever it is |
| 04:02.17 | jonpry | added smi2 to the pool? |
| 04:02.21 | WisTilt2 | what did you figure out? then i have an odd question for you |
| 04:02.30 | jonpry | look at this real quick https://gitorious.org/xdandroid-eclair/xdandroid-hardware_msm7k/blobs/gingerbread/libgralloc/gralloc.cpp#line270 |
| 04:02.39 | *** join/#htc-linux Rob2223 (~Miranda@p5DE4BDEE.dip.t-dialin.net) |
| 04:02.44 | jonpry | starting at line 197 |
| 04:03.14 | jonpry | this whole function just opens up pmem, and mmaps 8mb of it. or whatever it can get |
| 04:03.31 | jonpry | with absolutely no regard to what pmem section it is that gets mapped |
| 04:04.09 | jonpry | in our case it ends up being adsp that will be completely overwritten w/ graphics data |
| 04:04.41 | jonpry | this is not good for adsp :p |
| 04:04.49 | WisTilt2 | interesting... that makes sense as to why we keep getting random memory areas overlapping even though they are supposed to be already assigned |
| 04:05.05 | WisTilt2 | adsp is where i have the problem narrowed to, you just found the cause:) |
| 04:05.11 | jonpry | so apparently the order is important. which is defined in devices_htc.c |
| 04:05.38 | jonpry | i'm guessing since it wants 8mb. it wants gpu1 |
| 04:06.10 | jonpry | or maybe it needs its own pmem. this stuff is actually a hack. its for copybit capable bitmaps. for software gl |
| 04:07.13 | jonpry | so in theory we could just patch gralloc to use that high tech malloc stuff |
| 04:08.29 | WisTilt2 | let me try something based on that. before that i have an odd question- |
| 04:08.41 | WisTilt2 | pull up mach-msm/pmem.c |
| 04:08.56 | jonpry | ok |
| 04:09.34 | WisTilt2 | i wish i have 2 monitors like at my office, this would be easier so bear with me putting all this together |
| 04:10.20 | WisTilt2 | in rhodium case of course, where pmem_setting.pmem_size is set, 32mb currently... |
| 04:11.10 | WisTilt2 | each additional pmem such as adsp, camera, fb are all created AFTER that block with their own size, follow me so far |
| 04:11.10 | jonpry | yeah |
| 04:11.12 | WisTilt2 | ? |
| 04:11.54 | jonpry | i think thats ok |
| 04:11.56 | WisTilt2 | ok now tell my why are we even creating pmem_size then? that region never gets used, at least i have found nowhere it ever is |
| 04:12.08 | jonpry | it is not used |
| 04:12.41 | WisTilt2 | it appears to me its 32mb wasted unless i haven't found where it is used, which is possible. only the additional regions are used |
| 04:13.13 | WisTilt2 | reason i say this is i set pmem_size down to 4mb, allocated remainder to the pool and everything still works fine |
| 04:13.42 | jonpry | it only wasted if the kernel regions are not wrapper around the real data enough |
| 04:13.45 | WisTilt2 | im now at 112mb free after boot and everything ive tried still works like it should |
| 04:14.23 | WisTilt2 | no, that 32mb is taken away from available memory though in the fixup in board file so we lose that memory |
| 04:15.20 | jonpry | that 32mb is what gralloc is getting then |
| 04:15.34 | jonpry | so 0x24E00000 is not adsp |
| 04:15.35 | WisTilt2 | from where? at 4mb it still works though |
| 04:15.59 | jonpry | gralloc mmaps the first pmem base |
| 04:16.05 | jonpry | which is this 32mb thingy |
| 04:16.24 | WisTilt2 | ah, then it doesnt alloc based on what that size is really set to then? |
| 04:16.47 | jonpry | yeah it will |
| 04:16.54 | WisTilt2 | otherwise it would only alloc 4mb when i set it to that size |
| 04:17.20 | jonpry | thats how it should work |
| 04:17.36 | jonpry | but we can just patch gralloc to not use it |
| 04:17.43 | jonpry | then you can have all 32mb! |
| 04:18.26 | WisTilt2 | where does gralloc get its memory from then, available ram only? |
| 04:19.00 | jonpry | it can use malloc. there is no need for physical buffers unless we switch to dma |
| 04:19.10 | WisTilt2 | cool |
| 04:20.25 | jonpry | i don't have an xdandroid tree to compile it though |
| 04:22.51 | jonpry | looks like there is a copybit.msm7k.so |
| 04:23.33 | WisTilt2 | im not 100% following this i think. is pmem camera,adsp, etc gone then or just the 32mb pmem now in malloc? |
| 04:24.00 | jonpry | can't use malloc because of copybit |
| 04:24.03 | WisTilt2 | looks like just that 32mb block would be |
| 04:24.37 | jonpry | the 32mb is for android graphics |
| 04:25.02 | jonpry | but if we weren't using copybit, it could really just be replaced my malloc |
| 04:26.30 | WisTilt2 | ok then working around that cant we locate adsp where it wont be clobbered? that explains why when i increased pmem to 48 in 1 test i didnt have problems until several camera snapshots later |
| 04:26.47 | jonpry | i don't think it is being clobbered |
| 04:27.10 | jonpry | adsp should be at 0x24E00000 + 32mb |
| 04:27.14 | WisTilt2 | yeah it is, there are numerous regions within adsp that keep getting clashes |
| 04:27.21 | WisTilt2 | ok |
| 04:27.42 | WisTilt2 | thats not where it is right now |
| 04:28.18 | jonpry | looks like it to me |
| 04:28.36 | WisTilt2 | yeah you're right, im looking at my changed code that only has 16mb pmem size |
| 04:29.16 | jonpry | it won't be necessary for ics fwiw |
| 04:33.16 | WisTilt2 | im going to try something, back shortly |
| 04:38.14 | *** join/#htc-linux TheXev (~user@122.sub-174-252-212.myvzw.com) |
| 04:55.30 | *** join/#htc-linux dobrin (~dobrin@85.91.150.26) |
| 05:05.08 | *** join/#htc-linux fyodor_ (~cn.fyodor@218.94.136.179) |
| 05:07.15 | *** join/#htc-linux d3tul3 (~oliver@pool-96-234-141-27.bltmmd.east.verizon.net) |
| 05:07.23 | d3tul3 | jonpry, |
| 05:07.41 | jonpry | hey |
| 05:07.53 | jonpry | false alarm. i though i had it figured out |
| 05:08.06 | d3tul3 | right it takes it out hw3d ebi |
| 05:08.15 | d3tul3 | not random |
| 05:08.44 | d3tul3 | that's kind of what i was talking to you the other day |
| 05:08.54 | jonpry | umm. i think it takes it out of the big 32mb unnamed zone |
| 05:09.18 | d3tul3 | FB_ARENA = hw3d_ebi |
| 05:10.00 | d3tul3 | it lists all the regions |
| 05:10.08 | d3tul3 | but allocates out of ebi |
| 05:10.20 | jonpry | it doesn't specify an arena in init_pmem_area_locked() |
| 05:12.50 | d3tul3 | i see i was looking at that line 270 you pointed to |
| 05:12.58 | d3tul3 | but again not smi |
| 05:13.15 | d3tul3 | what's the hw3d smi region for? |
| 05:16.42 | jonpry | dunno. gpu stuff. pbuffer, textures, vbos |
| 05:17.59 | jonpry | i pretty much know how to make a hw compositor now. and it will be fast enough. the hw renderer is not necessary |
| 05:18.08 | d3tul3 | ok ok just caught up with the logs, would've been nice to be able to use malloc |
| 05:21.46 | WisTilt2 | jonpry interesting find here. i moved gpu1 up to ebin and moved adsp down to ebi, swapped them, and the memory clashes are following pmem_adsp wherever i put it. pmem_gpu1 addys never see clashes. |
| 05:22.42 | jonpry | what if you register them in a different order in devices_htc? |
| 05:23.12 | WisTilt2 | i tried that also, registered adsp last, no diff, registered gpu1 before and after adsp, same thing |
| 05:23.46 | WisTilt2 | it looks like that 8mb adsp block is being used by name no matter where it is located |
| 05:23.50 | d3tul3 | did you try a 3d animation |
| 05:24.09 | d3tul3 | is gpu1 = hw3d_ebi? |
| 05:24.18 | WisTilt2 | yes |
| 05:24.24 | *** join/#htc-linux bzo (~chatzilla@c-174-62-79-238.hsd1.ca.comcast.net) |
| 05:24.46 | WisTilt2 | didnt try 3d, just fired camera which causes the memory clash. its not cameras fault im sure at this point |
| 05:24.56 | d3tul3 | perhaps any messages would show up during boot animation or something |
| 05:25.09 | WisTilt2 | where are these virtual addys created? 0x40000000+ |
| 05:26.18 | WisTilt2 | dmesg is totally clean until adsp is used |
| 05:27.04 | jonpry | mmap makes those |
| 05:27.23 | WisTilt2 | jonpry this is the last region clash when in had adsp in ebi and gpu1 in ebin |
| 05:27.25 | WisTilt2 | region (vaddr 4029c000 len 524288) clashes with registered region (vaddr 402f8000 paddr 16312000 len 4096) |
| 05:27.33 | WisTilt2 | notice paddr |
| 05:28.08 | WisTilt2 | the clashes are the vaddr's |
| 05:28.23 | jonpry | but its not true |
| 05:28.54 | WisTilt2 | may not be but dream/pmem.c think it is |
| 05:29.11 | WisTilt2 | during the pmem_add is where this is happening wrong |
| 05:29.31 | jonpry | er. i guess it is |
| 05:30.46 | WisTilt2 | so im kind of stumped now. i'd be happier if moving adsp started showing clashes from gpu1 instead |
| 05:31.08 | WisTilt2 | bzo any more ideas? |
| 05:31.35 | jonpry | those various shifts and things are highly suspect as i wrote them |
| 05:31.43 | jonpry | the page align stuff |
| 05:32.13 | bzo | nah, not I. Right now just struggling to get a stable setup |
| 05:32.42 | WisTilt2 | bzo you're gsm aren't you? |
| 05:32.53 | bzo | no, rhod400 |
| 05:33.01 | WisTilt2 | oh, well there's the problem:) |
| 05:33.07 | d3tul3 | ok so no place in kernel that i could find references 'pmem_adsp" |
| 05:33.12 | d3tul3 | but userland does |
| 05:33.42 | bzo | d3tul3: u running .39 or 3.0 lately? |
| 05:34.04 | d3tul3 | er, .39 currently but i've been switching back and forth |
| 05:34.36 | bzo | is your tree current? |
| 05:34.51 | bzo | I'm getting constant sod |
| 05:36.20 | d3tul3 | where did you compile from, linux-msm-rhod? |
| 05:37.09 | bzo | yeah |
| 05:38.56 | d3tul3 | there's an acoustic related patch from .39 that hasn't made its way over but that's only related to adc, not sure how that would be causing issues....i ran 3.0 for about 30hrs in succession without an issue but that's the longest i've had it on |
| 05:39.09 | d3tul3 | is it like a proper sod? can you turn on the sleep led debugging |
| 05:39.38 | bzo | I'm on .39 actually, think I should try reverting the new sleep stuff |
| 05:40.42 | WisTilt2 | jonpry i meant adsp_driver.c is where the problem is, too many things opened ive been looking through. |
| 05:51.30 | bzo | WisTilt2: is this normal? |
| 05:51.35 | bzo | make ARCH=arm msm_defconfig |
| 05:51.37 | bzo | arch/arm/configs/msm_defconfig:286:warning: override: MSM7X00A_SLEEP_MODE_POWER_COLLAPSE changes choice state |
| 05:51.39 | bzo | arch/arm/configs/msm_defconfig:292:warning: override: MSM7X00A_IDLE_SLEEP_MODE_POWER_COLLAPSE changes choice state |
| 05:52.01 | WisTilt2 | yes, i changed the defaults in config |
| 05:52.16 | bzo | but why is it throwing a warning? |
| 05:52.47 | WisTilt2 | whats your cmd line in startup.txt, might be conflict from sleep_mode |
| 05:53.12 | bzo | this is just when I do a defconfig |
| 05:53.27 | WisTilt2 | this during compile oh. hmm dont know |
| 05:53.37 | bzo | can you pastebin your .config for me so I can compare? |
| 05:54.29 | WisTilt2 | bzo: http://pastebin.com/Ek47uNLx |
| 05:54.36 | bzo | thanks |
| 05:55.19 | WisTilt2 | might have some diff's from git due to testing ive been doing today but should still build fine |
| 05:56.41 | d3tul3 | bzo after doing defconfig |
| 05:56.48 | d3tul3 | copy .config to arch/arms/configs |
| 05:56.50 | d3tul3 | and do a diff |
| 05:57.05 | d3tul3 | copy .config as msm_defconfig that is |
| 05:57.22 | d3tul3 | it will show you what it auto-changed due to incompatible dependencies |
| 06:04.02 | bzo | hmm, defconfig was changed to set the COLLAPSE_SUSPENDs to yes |
| 06:04.19 | bzo | however, it does not apply it to .config |
| 06:04.37 | bzo | WisTilt2: your .config doesn't have these enabled either |
| 06:07.14 | WisTilt2 | looks like when i pushed that i had both enabled where it should only have the suspend on idle and collapse on sleep. change defconfig to comment out each of those and ill push a revised defconfig |
| 06:10.18 | WisTilt2 | default modes are correct though. pushed if you want to get the correct one. thanks for catching that |
| 06:14.17 | WisTilt2 | jonpry: just for kicks i moved adsp to smi2 and clashes following right along to those regions. wanted to rule out both ebi's being the problem |
| 06:15.23 | jonpry | gotta checkout those shifts |
| 06:23.24 | WisTilt2 | well gpu1 runs in smi2 now, maybe i messed it up when i tried it earlier today |
| 06:27.03 | jonpry | weird |
| 06:28.15 | d3tul3 | hm i think we should just patch libcamera to use the general pmem pool rather than pmem_adsp |
| 06:28.30 | d3tul3 | there's 32MB there right? |
| 06:28.36 | WisTilt2 | yep |
| 06:30.34 | WisTilt2 | whoa, are we using this define anywhere crucial? #define MSM_PMEM_ADSP_SIZE0x1C00000 that's not 32mb, close but no cigar |
| 06:30.48 | WisTilt2 | far from 8mb |
| 06:38.49 | *** join/#htc-linux YataroX (~user@122.sub-174-252-212.myvzw.com) |
| 06:39.12 | d3tul3 | it could also be that whatever internal mechanism that adsp is using to track pmem is broken, and it errors out without needing to |
| 06:40.05 | d3tul3 | actually it might not be a bad idea to disable that adsp_pmem_check call for testing purposes |
| 06:41.44 | WisTilt2 | good idea, cant hurt it any more than it already is. you going to try that or i can. im just mapping out the non modem areas in smi2 |
| 06:42.55 | d3tul3 | i can give it a go tomorrow i am checking out for the night, good night |
| 06:43.12 | WisTilt2 | ok nite. |
| 06:56.57 | *** join/#htc-linux kiozen (~kiozen@p5DDF1B54.dip.t-dialin.net) |
| 06:59.06 | WisTilt2 | bzo you get it to build? |
| 06:59.29 | bzo | yes, just waiting for the battery to charge to do another idle test |
| 07:00.43 | WisTilt2 | are you running scbs also? |
| 07:14.07 | *** join/#htc-linux rpierce99 (~rpierce99@96-42-102-103.dhcp.stcd.mn.charter.com) |
| 07:19.59 | *** join/#htc-linux balans2 (~user@82-170-217-205.ip.telfort.nl) |
| 07:55.22 | *** join/#htc-linux rpierce99 (~rpierce99@96-42-102-103.dhcp.stcd.mn.charter.com) |
| 08:10.46 | *** join/#htc-linux ychavan (ychavan@nat/redhat/x-brdtvrofzjmsviir) |
| 08:43.35 | *** join/#htc-linux gauner1986 (~Miranda@87.253.171.201) |
| 08:51.16 | *** join/#htc-linux leviathan (~quassel@2001:470:26:484:6ef0:49ff:fee6:8dca) |
| 09:12.04 | *** join/#htc-linux lamikr (lamikr@nat/nokia/x-fuqfpplaogztgzjo) |
| 09:49.43 | *** part/#htc-linux ali1234 (~ajbuxton@robotfuzz.co.uk) |
| 09:50.15 | *** join/#htc-linux ali1234 (~ajbuxton@robotfuzz.co.uk) |
| 09:58.28 | *** join/#htc-linux mitsutaka (~mitsutaka@p2004-ipbf2206marunouchi.tokyo.ocn.ne.jp) |
| 10:27.40 | *** join/#htc-linux arif-ali (~arif-ali@ip-81-23-53-226.ask4internet.com) |
| 10:30.58 | *** join/#htc-linux balans (~server@82-170-217-205.ip.telfort.nl) |
| 10:35.55 | *** join/#htc-linux balans (~server@82-170-217-205.ip.telfort.nl) |
| 10:50.29 | *** join/#htc-linux XeKToReX (~xTx@CPE-124-188-18-211.hdbq1.win.bigpond.net.au) |
| 11:00.37 | *** join/#htc-linux mygadgetgeek (~mygadgetg@host86-129-198-159.range86-129.btcentralplus.com) |
| 11:05.04 | mygadgetgeek | hi all whats the news today |
| 11:06.31 | *** join/#htc-linux MethoS- (~clemens@134.102.106.250) |
| 11:06.39 | *** join/#htc-linux rzk (~rzk@89.178.165.56) |
| 11:08.36 | *** join/#htc-linux bartman (~bart@2607:f2c0:a000:175:2e0:81ff:fe47:3d01) |
| 11:13.03 | mygadgetgeek | can someone tell me if i was to start delevloping for mobiles whould i start leaning c ++ |
| 11:25.56 | ali1234 | no |
| 11:26.18 | ali1234 | not unless you want to develop for symbian anyway |
| 11:27.01 | ali1234 | android -> java, apple -> objective-c, wp7 -> .net languages |
| 11:29.18 | *** join/#htc-linux MethoS- (~clemens@134.102.106.250) |
| 11:31.38 | *** join/#htc-linux Bry8Star (~Bry8Star@gateway/tor-sasl/bry8star) |
| 11:38.22 | *** join/#htc-linux TheXev (~user@122.sub-174-252-212.myvzw.com) |
| 11:50.52 | *** join/#htc-linux rajkosto (~rajkosto@2001:470:d76b:da7a:3138:3641:a927:1dd0) |
| 12:42.09 | *** join/#htc-linux mgross029 (~mgross@cpe-107-10-11-218.neo.res.rr.com) |
| 12:55.49 | *** join/#htc-linux lippa (~lippa@ppp118-209-183-24.lns20.mel6.internode.on.net) |
| 13:41.25 | *** join/#htc-linux helicopter88 (~helicopte@host134-112-dynamic.43-79-r.retail.telecomitalia.it) |
| 13:53.00 | *** join/#htc-linux rzk_ (~rzk@95-28-194-44.broadband.corbina.ru) |
| 14:48.29 | *** join/#htc-linux AstainHellbring (AstainHell@unaffiliated/astainhellbring) |
| 14:57.08 | *** join/#htc-linux NeoMatrixJR (~chatzilla@173-20-63-62.client.mchsi.com) |
| 15:00.12 | *** join/#htc-linux rob_w (~bob@host-188-174-172-122.customer.m-online.net) |
| 15:04.11 | *** join/#htc-linux DJWillis (~djwillis@cpc1-bath5-2-0-cust122.aztw.cable.virginmedia.com) |
| 15:22.11 | *** join/#htc-linux rpierce99 (~rpierce99@96-42-102-103.dhcp.stcd.mn.charter.com) |
| 15:40.36 | *** join/#htc-linux d3tul3 (~detule@pool-96-234-141-27.bltmmd.east.verizon.net) |
| 15:44.21 | *** join/#htc-linux Cotulla (~myfakemai@nat100-255-205-109.tvoe.tv) |
| 15:46.08 | *** join/#htc-linux helicopter88 (~helicopte@host134-112-dynamic.43-79-r.retail.telecomitalia.it) |
| 15:49.30 | *** join/#htc-linux AstainHellbring (~AstainHel@unaffiliated/astainhellbring) |
| 15:56.45 | *** join/#htc-linux paulk (~paulk@lib33-1-82-233-88-171.fbx.proxad.net) |
| 15:59.22 | *** join/#htc-linux NeoMatrixJR (~chatzilla@173-20-63-62.client.mchsi.com) |
| 16:10.00 | *** join/#htc-linux WisTilt2 (~wisgreg@wireless251.wirelesstcp.net) |
| 16:12.16 | *** join/#htc-linux balans2 (~user@82-170-217-205.ip.telfort.nl) |
| 16:18.43 | *** join/#htc-linux jonpry (~jon@unaffiliated/jonpry) |
| 16:18.56 | *** join/#htc-linux gnutoo (~gnutoo@host40-58-dynamic.116-80-r.retail.telecomitalia.it) |
| 16:19.02 | *** join/#htc-linux emwe (~mweirauch@cable-86-56-10-252.cust.telecolumbus.net) |
| 16:35.28 | d3tul3 | hey WisTilt2 |
| 16:38.49 | WisTilt2 | hi d3tule3, in the middle of a big test with some major pmem changes:) back in a bit with the results |
| 16:39.16 | d3tul3 | sure |
| 16:39.28 | d3tul3 | by the way camera is working over here |
| 16:39.31 | rpierce99 | so we should start taking bets on which version of the RHOD will not boot afterwards :) |
| 16:39.55 | WisTilt2 | what you do to fix camera? try removing that pmem check? |
| 16:40.26 | WisTilt2 | rpierce99 should work on all rhods if i have this setup correctly |
| 16:40.44 | rpierce99 | i have faith |
| 16:40.47 | WisTilt2 | just that the gsm rhods will have move available memory hehe |
| 16:40.48 | d3tul3 | yeah not only did it "fix" the camera -> it also seems to have straightned this lingering routing issue i've been having where my spekear would not play a ringtone on an incoming call |
| 16:40.51 | rpierce99 | in you, not in HTC |
| 16:41.33 | WisTilt2 | d3tul3 really? so is this just some incorrect error in pmem check you think and we really dont have overlaps happening? |
| 16:42.10 | d3tul3 | no idea what's happening, not entirely sure how pmem_adsp interacts with adsp_driver and what exactly is the point of adsp_driver keeping this internal check-routing of pmem |
| 16:42.27 | d3tul3 | s/check-routing/check-routine/ |
| 16:44.04 | d3tul3 | but yeah i am 10/10 in photos this morning |
| 16:53.35 | *** join/#htc-linux furtardo (~mks@nat/yahoo/x-xajbbjpldmqyyqkb) |
| 17:09.27 | *** join/#htc-linux infernix (nix@unaffiliated/infernix) |
| 17:23.38 | WisTilt2 | which gpu does what anyone know? |
| 17:27.05 | Cotulla | Adreno130? |
| 17:28.01 | WisTilt2 | tp2:) |
| 17:28.25 | Cotulla | it's there |
| 17:28.29 | Cotulla | Adreno 130 |
| 17:28.37 | gauner1986 | hi |
| 17:28.46 | Cotulla | hi |
| 17:28.46 | Cotulla | 200 in QSD8250/LEO |
| 17:29.05 | Cotulla | or what u means? (maybe I got ur question wrong) |
| 17:30.40 | WisTilt2 | Cotulla, gpu0 and gpu1. which is used for 3d, camera etc or how does that work? |
| 17:31.45 | Cotulla | GPU0 & GPU1 are used for ATI Adreno only |
| 17:31.53 | Cotulla | memory for textures and vertex buffers |
| 17:32.16 | Cotulla | camera is using other memory which works with QDSP5 / VFE |
| 17:32.28 | Cotulla | but they are not related, 3D and camera |
| 17:32.50 | Cotulla | there is also GPU2 which is IMEM 256Kb I remember |
| 17:32.52 | emwe | if I may chime in, what does VFE stand for? what does it do? |
| 17:33.21 | *** join/#htc-linux |lippa| (~lippa@ppp118-209-127-16.lns20.mel4.internode.on.net) |
| 17:33.28 | WisTilt2 | video front end |
| 17:33.46 | Cotulla | VFE (Video Front End) |
| 17:34.06 | Cotulla | it's primary data capture from camera interface? |
| 17:34.28 | Cotulla | so it should be something like camera -> VFE -> QSDP5 -> file |
| 17:34.52 | emwe | aha. thanks. |
| 17:35.46 | Cotulla | the main issue ofcourse that HW wants PA addresses and allocations inside OS are not PA continuous |
| 17:36.01 | Cotulla | it's why this PMEM stuffs exist |
| 17:36.59 | d3tul3 | camera != pmem_gpu*, rather pmem_adsp right? |
| 17:37.24 | Cotulla | GPU is 3D and it's separate stuffs |
| 17:37.34 | Cotulla | pmem_adsp used during camera encoding |
| 17:37.39 | Cotulla | as I remember |
| 17:38.30 | Willd | But pmem_gpu isn't used anymore right? |
| 17:38.38 | Willd | hw3d does that by itself? |
| 17:38.56 | Cotulla | Android SO call IOCTL to get regions |
| 17:38.59 | Cotulla | it's main thing |
| 17:39.12 | Cotulla | there 3 regions SMI EBI and IMEM |
| 17:39.51 | Cotulla | all other stuffs inside kernel - it just detail of implementation, how to store values in good form, isn't it? |
| 17:39.55 | WisTilt2 | hw3d registers the gpu's |
| 17:40.09 | Cotulla | you can even hardcode addresses inside this IOCTL |
| 17:40.27 | Cotulla | there are 7 + 8 mb |
| 17:40.30 | WisTilt2 | im trying to figure out why gpu1 cannot run correctly in smi memory like gpu0 does |
| 17:41.08 | Cotulla | but on RHO there are no free place for that? |
| 17:41.21 | Cotulla | there only around 8 mb? |
| 17:41.23 | Cotulla | *is |
| 17:41.29 | Cotulla | in SMI for APPS |
| 17:41.34 | WisTilt2 | there is now:) |
| 17:42.03 | WisTilt2 | i have another 16mb of smi available. everything else i stick in there is working great but gpu1 doesn't like anywhere in smi |
| 17:42.31 | Cotulla | hm, where u found other 16mb? |
| 17:42.45 | rpierce99 | something else is hard coded to find gpu1 where it is? |
| 17:43.02 | Cotulla | there only 32 mb: 1 mb busy by boot. then 1-8 mb - GPU0, then 1 + 1 are OEMSBL and QCSBL |
| 17:43.03 | WisTilt2 | unlocked smi2 and using region that modem doesn't use |
| 17:43.08 | Cotulla | then should be amss |
| 17:43.32 | Cotulla | u sure it's exist there? maybe it just "loopback" to first 32 mb |
| 17:43.41 | Cotulla | or question why HTC never used it |
| 17:43.58 | WisTilt2 | nope. its assigned to the modem |
| 17:44.23 | Cotulla | hm |
| 17:44.38 | Cotulla | there was register SMI size isn't it? |
| 17:44.44 | Cotulla | did u read it? |
| 17:45.11 | WisTilt2 | huh? dont get your question? |
| 17:45.25 | Cotulla | 0xa8250000 |
| 17:46.50 | WisTilt2 | still dont know what you're asking |
| 17:46.54 | Cotulla | ok |
| 17:46.57 | Cotulla | which are is extra free? addresses? |
| 17:47.00 | Cotulla | in SMI |
| 17:47.13 | Cotulla | *area |
| 17:48.46 | WisTilt2 | guess you're talking about 0x00000000 and 0x02000000? |
| 17:48.57 | Cotulla | yes |
| 17:49.04 | Cotulla | :) |
| 17:49.45 | emwe | Cotulla: is there a way to trace vregs with haret except tracing dex comm memory? |
| 17:50.05 | Cotulla | no, vregs are controlled via ssbi bus |
| 17:50.31 | Cotulla | maybe WM debug log can show information |
| 17:52.08 | Cotulla | so in RHO AMSS starts at 00A0 0000 |
| 17:53.09 | emwe | WM debug log? how was that accessed? ;) |
| 17:53.43 | Cotulla | and I am looking to some AMSS version |
| 17:54.23 | WisTilt2 | so Cotulla, example for what im asking: i move gpu1 to a working smi area, why does it not like that? it only works in ebi or ebin. btw, i did changed the hw3d resource names to match the move, made no difference. |
| 17:54.34 | emwe | Cotulla: 0x16f00000 << that? |
| 17:54.49 | Cotulla | enwe, looks like yes |
| 17:54.55 | emwe | ah ok, thx. |
| 17:55.25 | Cotulla | WisTilt2, honestly I don't understand where you found free SMI. can you explain a bit? |
| 17:55.59 | WisTilt2 | 0x00000000-0x1fffffff = 32 correct? |
| 17:56.23 | Cotulla | yes |
| 17:56.48 | WisTilt2 | so what is 0x20000000-0x3fffffff |
| 17:57.44 | Cotulla | unused? some MSM7200A has 32Mb SMI and some has 64Mb SMI? like Diamond 1 has 128 EBI + 64 SMI, Raphael - 256 EBI +32 SMI |
| 17:57.58 | WisTilt2 | base address 0x20000000 is 32mb smi that the modem uses |
| 17:58.22 | WisTilt2 | modem has the top 24mb locked |
| 17:59.19 | Cotulla | and on 64SMI AMSS fully fits inside SMI, isn't it? but RHO has EBI AMSS part at 16D0 0000 - 1800 0000 |
| 17:59.27 | Cotulla | it looks strange |
| 18:01.11 | WisTilt2 | there is a 16mb region within this that is not used by modem, at least not on the rhod gsm's. thats where i currently have adsp,camera,and fb running |
| 18:01.25 | WisTilt2 | camera i have set to 6mb btw since 4.5 is all it needs |
| 18:01.41 | Cotulla | hm intersting |
| 18:01.54 | WisTilt2 | anyway, im puzzled why gpu1 has to run only in ebi |
| 18:02.05 | Cotulla | maybe it's only MSM7600A with 64SMI? |
| 18:02.08 | WisTilt2 | i thought it was working in smi last night but i was wrong |
| 18:02.32 | Willd | Cotulla: Yeah, it is |
| 18:02.45 | Willd | or.. hmm, no |
| 18:03.14 | Cotulla | because MAGLDR halts when I try to dump at 0200 0000 on RHO |
| 18:03.18 | Cotulla | on GSM RHO |
| 18:03.33 | Willd | There are two versions of msm7200a |
| 18:03.37 | Willd | isch |
| 18:03.38 | WisTilt2 | on gsm rhod you can actually use the bottom 8mb of 02000000 |
| 18:03.56 | WisTilt2 | at least on the rhod 300, i am doing it currently:) |
| 18:04.18 | Willd | Hmm, the othrr 8mb out of the 16 then |
| 18:04.19 | Willd | ? |
| 18:04.25 | Cotulla | so u have GSM one now? |
| 18:04.32 | Willd | Where are they? |
| 18:04.34 | WisTilt2 | i have 15 rhod 300's |
| 18:04.50 | Cotulla | ohh |
| 18:04.52 | Cotulla | :) |
| 18:05.00 | WisTilt2 | phone brb |
| 18:05.04 | Cotulla | can u dump value at 0xa8250000? |
| 18:09.49 | Cotulla | no seems it doesn't related |
| 18:15.12 | Cotulla | do u try to put all memory to GPU0 and nothing to GPU1? |
| 18:16.25 | *** join/#htc-linux swc|666 (~gecko@unaffiliated/swc666/x-4934821) |
| 18:17.48 | d3tul3 | i am pretty sure gralloc wants to find hw3d_ebi which runs inside gpu1 memory |
| 18:18.46 | Cotulla | but WisTilt2 said that he changed only address not name? |
| 18:19.01 | WisTilt2 | i changed name also |
| 18:19.17 | Cotulla | hm why? can u try only replace EBI address by SMI? |
| 18:19.40 | fakker | 15?! |
| 18:19.41 | WisTilt2 | hw3d has ebi and smi named |
| 18:20.49 | WisTilt2 | cotulla, dump 0xb0100000 and see what you have. |
| 18:21.01 | Cotulla | or maybe ATI doesn't support same memory for both |
| 18:21.09 | Cotulla | 0xb0100000 - PA? |
| 18:21.11 | WisTilt2 | btw, you guys know these are 7201a's not 7200a's correct? |
| 18:21.21 | Cotulla | we can read HW IDs |
| 18:22.57 | WisTilt2 | d3tul3 is gralloc looking specifically for hw3d_ebi? |
| 18:23.22 | *** join/#htc-linux NeoMatrixJR (~chatzilla@173-20-63-62.client.mchsi.com) |
| 18:23.32 | d3tul3 | yeah currently it is, though the OEM binary i guess could be also using hw3d_smi |
| 18:24.24 | WisTilt2 | trying something to verify that... |
| 18:24.52 | Cotulla | 0xa9000270 should be part num |
| 18:25.10 | Cotulla | will dump it now |
| 18:26.20 | Cotulla | A9000270: E1 00 17 30 |
| 18:29.16 | Cotulla | hm my is 7200A? |
| 18:30.57 | *** join/#htc-linux GNUtoo (~GNUtoo@host40-58-dynamic.116-80-r.retail.telecomitalia.it) |
| 18:31.20 | WisTilt2 | d3tul3: gralloc must be hardcoded to hw3d_ebi. changed name and no workie |
| 18:31.46 | d3tul3 | yeah gralloc.cpp specifically looks for hw3d_ebi |
| 18:32.05 | d3tul3 | what's more mysterious is how hw3d_smi gets used |
| 18:32.22 | Cotulla | inside SO? |
| 18:32.53 | d3tul3 | yeah i guess it's inside the binary |
| 18:37.18 | WisTilt2 | i wonder if hw3d_smi actually gets used. last night i changed its size down to 1mb while messing around and nothing changed. although i didnt try any 3d stuff |
| 18:39.09 | WisTilt2 | cotulla what phone you have that has 7200a? |
| 18:39.16 | WisTilt2 | thats a real old chip |
| 18:40.01 | Cotulla | RHO, GSM only, without frontal camera |
| 18:40.03 | Cotulla | let me look |
| 18:40.43 | Cotulla | can u dump A9000270 to compare? |
| 18:40.59 | WisTilt2 | not currently. im in pmem test mode atm |
| 18:41.17 | WisTilt2 | whats at that address? |
| 18:41.30 | Cotulla | revision? |
| 18:42.57 | Cotulla | http://pdadb.net/index.php?m=pdacomparer&id1=1913&id2=1989&id3=1751&id4=1931&id5=1792&id6=1766&id7=2016&del_id=1931 |
| 18:43.45 | Cotulla | so my is RHO100 seems |
| 18:54.17 | jonpry | dur. my compositor is semi working but i think it does not get a hardware context. i think its that libegl.oem system process denying deal |
| 18:56.15 | Cotulla | patch it |
| 19:01.45 | jonpry | might be able to force it with some patch to surfaceflinger but i need to a better way to tell if a context is hardware besides rendering things and checking for interrupts |
| 19:02.04 | WisTilt2 | whats the normal fps from neocore on the tp2? |
| 19:02.09 | jonpry | 22? |
| 19:02.25 | WisTilt2 | i moved both gpu0 and 1 into smi and im getting 29.5fps |
| 19:02.32 | jonpry | whoa |
| 19:02.53 | jonpry | i think its vsync locked at 30 for reasons i don't understand |
| 19:03.14 | WisTilt2 | i only have 7mb assigned to gpu0 still and 5mb to gpu1 right now |
| 19:03.22 | d3tul3 | WisTilt2, neocore on gb? |
| 19:03.23 | Cotulla | where was a problem? |
| 19:03.30 | d3tul3 | neocore doesn't render all textures on GB for me |
| 19:03.31 | WisTilt2 | d3tul3 yes |
| 19:03.35 | d3tul3 | does it look ok? |
| 19:03.44 | d3tul3 | like i could see the smoke out of the rockets but not the rockets |
| 19:03.47 | WisTilt2 | looks like it does now, beautiful graphics |
| 19:04.01 | d3tul3 | damn, i could get 29fps with these omitted textures |
| 19:04.14 | d3tul3 | on froyo with full graphics i get 20.1 with alex's clocks, 15.5 with JB's clocks |
| 19:05.02 | WisTilt2 | lol, just tested it on our inspire 4g and neocore got 58.1fps jeeze |
| 19:05.18 | WisTilt2 | i still love the tp2 |
| 19:05.28 | jonpry | nothing can ever break 30 thought |
| 19:05.51 | d3tul3 | yeah that's what i thought it's hardcoded somehow right even in fps2d i get 29 |
| 19:06.43 | WisTilt2 | it does on the inspire. its running cm7.1.0 build gwk74 on 2.6.35.14 kernel |
| 19:07.05 | jonpry | so inspire is not locked to 30fps |
| 19:07.10 | WisTilt2 | nope |
| 19:08.09 | WisTilt2 | so do we really need 8mb for each gpu? this is running with gpu1 at 5mb |
| 19:08.36 | WisTilt2 | i guess in hd mode maybe, didnt do the math on that resolution |
| 19:09.16 | Cotulla | it should be question about amount of textures |
| 19:10.27 | WisTilt2 | bad news is this smi2 area looks like its only going to be usable on these rhod 300's so unless one of the gpu's can be reduced in size one will have to stay in ebi on the cdma devices |
| 19:12.59 | d3tul3 | just tried running neocore again, and it definitely does not render most of the textures |
| 19:13.39 | WisTilt2 | are you seeing the moon moving around? |
| 19:13.52 | d3tul3 | yeah i see the moon, but i can't see the robot i see only his green light |
| 19:14.32 | d3tul3 | i can't see the tanks or whatever they are |
| 19:14.43 | d3tul3 | just the smoke from the rockets they fire |
| 19:14.50 | WisTilt2 | let me make a test kernel and see if it will run on your cdma device |
| 19:15.05 | d3tul3 | still with most of the graphics unrendered it scores 28.5 |
| 19:21.45 | WisTilt2 | jonpry is it vsync on the panel locked at 30 or elsewhere in the code. wouldn't be that hard to add vsync value to the panel init's |
| 19:22.27 | WisTilt2 | d3tul3 im testing this build for you to try then ill upload it |
| 19:23.56 | *** join/#htc-linux LordDeath (~LordDeath@cable-81-173-164-108.netcologne.de) |
| 19:25.31 | WisTilt2 | that dropped me to an even 28.0fps |
| 19:26.26 | WisTilt2 | thats with gpu0 at 8mb in ebi and gpu1 at 6mb in smi along with fb in smi |
| 19:28.35 | d3tul3 | i think it'll be a nice accomplishment just to get everything to render on my phone |
| 19:29.30 | WisTilt2 | man youtube hd looks fantastic! guess we need gsensor for landscape mode though but its clear and smooth video |
| 19:29.58 | WisTilt2 | ah slid kbd out now it is full screen and beautiful |
| 19:30.21 | d3tul3 | so you reversed gpu0 and gpu1? |
| 19:30.26 | d3tul3 | in terms of location |
| 19:30.50 | WisTilt2 | yes, although i have everything in ebi and now ebin is full 128mb for rest of system |
| 19:31.16 | d3tul3 | this is the setup on the kernel i am testing> |
| 19:31.18 | d3tul3 | ? |
| 19:31.25 | WisTilt2 | yes |
| 19:31.52 | WisTilt2 | ebi=pmem,adsp,camera,gpu0,ramconsole for now |
| 19:32.21 | WisTilt2 | ebin=128mb, smi=gpu1@6mb and fb@2mb |
| 19:32.42 | d3tul3 | i see total emmory 177336 |
| 19:33.13 | WisTilt2 | yes, your device doesnt support the 16mb up in smi2:( |
| 19:34.26 | d3tul3 | no textures in neocore |
| 19:34.28 | WisTilt2 | nor the bottom 8mb of smi2 |
| 19:34.43 | WisTilt2 | hmm, no textures at all now? |
| 19:34.51 | d3tul3 | same as before |
| 19:35.12 | WisTilt2 | let me try it in this configuration |
| 19:35.13 | d3tul3 | 28.6 but that number is pretty meaningless |
| 19:36.30 | WisTilt2 | well now i dont see the rockets nor robot just smoke flames moon etc. everything is smooth still |
| 19:36.37 | WisTilt2 | 28.7fps |
| 19:37.50 | d3tul3 | yeah but it's rendering like a very minor portion of the graphics |
| 19:38.27 | WisTilt2 | play an hd video and see if its smooth |
| 19:38.29 | *** join/#htc-linux NeoMatrixJR (~chatzilla@173-20-63-62.client.mchsi.com) |
| 19:38.58 | WisTilt2 | i dont have that pmem check disabled in this btw, which shouldn't make any difference |
| 19:40.08 | d3tul3 | k something came up bbl |
| 19:40.18 | WisTilt2 | np |
| 19:40.50 | WisTilt2 | back with gpu's both in smi i have full rendering again, weird |
| 19:41.27 | WisTilt2 | something with surface textures must want to be in smi |
| 19:43.19 | *** join/#htc-linux bartman (~bart@2607:f2c0:a000:175:2e0:81ff:fe47:3d01) |
| 19:53.04 | *** join/#htc-linux kiozen (~kiozen@ppp-93-104-79-90.dynamic.mnet-online.de) |
| 19:58.00 | *** join/#htc-linux bartman (~bart@2607:f2c0:a000:175:2e0:81ff:fe47:3d01) |
| 20:06.30 | *** join/#htc-linux rob_w_ (~bob@host-188-174-172-122.customer.m-online.net) |
| 20:08.53 | *** join/#htc-linux lapin (~quassel@ppp-94-68-165-9.home.otenet.gr) |
| 20:22.12 | Willd | WisTilt2: You got both gpu's in smi now? |
| 20:22.37 | WisTilt2 | yep but only works on the rhod300 it looks like |
| 20:23.35 | Willd | Odd.. |
| 20:23.46 | Willd | I saw something about you unlocking smi2? |
| 20:25.03 | WisTilt2 | only on the 300. i still want to do some test with someone with 400-500 to see if there is any other smi that can be accessed though. only need 8mb more for both gpus to run there. |
| 20:30.41 | Willd | Hm, I should try this on my device.. |
| 20:30.51 | WisTilt2 | 400? |
| 20:31.02 | Willd | Na, actually a samsung galaxy |
| 20:31.06 | Willd | First generation |
| 20:31.23 | Willd | Basically same specs as 300 |
| 20:31.24 | WisTilt2 | .39 wont work on that will it? rhod only kernel |
| 20:31.39 | Willd | Don't know actually, we could give it a try |
| 20:31.47 | Willd | I reckon our rom differs some.. |
| 20:32.08 | WisTilt2 | let me finish this, im adding machine variants so this will work on any rhod |
| 20:32.18 | WisTilt2 | then ill upload and give you url to get the pack |
| 20:32.22 | Willd | WisTilt2: Thanks :) |
| 20:42.07 | *** part/#htc-linux Cotulla (~myfakemai@nat100-255-205-109.tvoe.tv) |
| 20:43.11 | rpierce99 | WisTilt2: is there some way i can help? |
| 20:43.28 | Willd | Hm |
| 20:44.26 | WisTilt2 | hi rpierce99, yes about to build and upload this so you can test on your 400. after lunch ill put some cdma test kernels together to check for further smi on that device if you're up to it? |
| 20:44.55 | rpierce99 | yep, i'm in and out, day before thanksgiving in retail web development, so doing some stuff but not too busy |
| 20:48.32 | Willd | Uhm, where do you get hold of android sources now a days? |
| 21:13.37 | *** join/#htc-linux mastermerlin (~Adium@p4FEE5C04.dip.t-dialin.net) |
| 21:16.20 | jonpry | WisTilt2, have to ask acl about the 30fps. something to do with his double buffering scheme. panel is actually 60pfs. he did something with triple buffering that got throughput up to 60fps again, but its slow motion or something when the rendering is not fast |
| 21:22.44 | emwe | wasn't that some gralloc experiments with NUM_BUFFERS set to 3? |
| 21:23.42 | emwe | the other experiment was with VPA and T2 register settings for panel init. |
| 21:24.57 | WisTilt2 | jonpry ok thanks, probably worth pursuing it we can get above 30fps limit |
| 21:25.06 | WisTilt2 | Willd: http://xdandroid.com/wiki/Source_Repositories kernel sources |
| 21:25.18 | WisTilt2 | for starters |
| 21:26.45 | Willd | WisTilt2: Splendid :) |
| 21:45.14 | *** join/#htc-linux NeoMatrixJR (~chatzilla@173-20-63-62.client.mchsi.com) |
| 21:45.59 | WisTilt2 | rpierce99 can you try this kernel on your 400 and see if it even boots? same url and name for the kernel pack |
| 21:46.06 | rpierce99 | k |
| 21:51.02 | *** join/#htc-linux mitsutaka (~mitsutaka@p2004-ipbf2206marunouchi.tokyo.ocn.ne.jp) |
| 21:52.24 | rpierce99 | haret froze up on my first attempt, trying again |
| 21:52.55 | WisTilt2 | no something wrong then. i thought it was my variant for the 300. give me a few ill have another to test |
| 21:53.39 | WisTilt2 | you didn't even get the double vibes did you? |
| 21:53.49 | rpierce99 | don't think so |
| 22:34.31 | jonpry | dur. hacked libGLES to allow system process opengl. but it hangs during eglInitialize |
| 22:43.50 | *** join/#htc-linux |lippa| (~lippa@ppp118-209-193-35.lns20.mel6.internode.on.net) |
| 23:11.09 | *** join/#htc-linux vinceweis (4463ed13@gateway/web/freenode/ip.68.99.237.19) |