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.27 | jonpry_ | detule, want to make us a 2d allocator? |
03:29.54 | *** join/#htc-linux mitsutak_ (~mitsutaka@219.143.36.82) |
03:35.05 | d3tul3 | jonpry_, if i had any inkling of what the hell was goign on i would love to |
03:35.48 | jonpry_ | its not difficult to understand |
03:37.44 | arrrghhh | d3tul3, did you get an answer on the evo4g/tp2 battery thing? |
03:38.20 | d3tul3 | i got some, but i would love to hear yours as well |
03:38.21 | jonpry_ | they fit. assuming that is the question |
03:38.25 | arrrghhh | they do fit |
03:38.30 | d3tul3 | where do you guys get yours? |
03:38.34 | arrrghhh | when i got my tp2 in, they threw an evo battery in it |
03:38.44 | arrrghhh | i used to buy shitty ebay ones, WisTilt2's site sounds better |
03:38.48 | arrrghhh | hi btw ;) |
03:39.04 | jonpry_ | i had a whole pile of $3 ebay ones |
03:39.09 | arrrghhh | yea |
03:39.14 | arrrghhh | $3 ebay ones is what i used to buy |
03:39.15 | arrrghhh | they worked |
03:39.29 | arrrghhh | haven't bought a batt in a while tho |
03:39.39 | arrrghhh | the donor i got came with a nice seidio |
03:39.58 | arrrghhh | but it doesn't fit quite right, and quite often it would power off & on me |
03:40.30 | jonpry_ | pretty sure you get the most W/h per $ w/ ebay. but maybe not the most W/h per battery |
03:40.57 | arrrghhh | yea |
03:41.04 | arrrghhh | the ebay ones work, that's for sure. |
03:41.26 | d3tul3 | jonpry_, 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.39 | jonpry_ | they are primarily cheaper because they avoid paying the patent licensing |
03:42.08 | jonpry_ | d3tul3 i'm not sure. its pretty simple. but i don't know what its normally called |
03:42.13 | d3tul3 | i 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.37 | jonpry_ | chinese knock offs |
03:43.01 | arrrghhh | ^^ |
03:43.08 | arrrghhh | they'll knock-off anything |
03:43.12 | arrrghhh | ruthless |
03:43.17 | jonpry_ | lol |
03:43.28 | arrrghhh | their iOS knockoffs are always the best |
03:43.37 | arrrghhh | i swear foxconn employees just sell the crap |
03:43.48 | arrrghhh | they're usually really good knock-offs. until you try to use them. |
03:44.38 | jonpry_ | i considered starting a clandestine battery factory. smuggling batteries is like a many million dollar industry |
03:44.52 | arrrghhh | lol |
03:46.49 | jonpry_ | probably gets confiscated by customs if it has a chinese brand |
03:47.50 | d3tul3 | later folks gotta make a run to the airport |
03:47.59 | jonpry_ | cya |
03:49.26 | arrrghhh | make a run eh |
03:50.02 | arrrghhh | WisTilt2, you thar? |
03:53.37 | *** join/#htc-linux mitsutaka (~mitsutaka@219.143.36.82) |
03:57.45 | jonpry_ | arrrghhh, what kind of laptop do you have? |
04:00.00 | arrrghhh | i have a cr-48 and an hp pavilion dv6 |
04:00.23 | jonpry_ | which is the 12gb one? |
04:00.28 | *** join/#htc-linux mitsutaka (~mitsutaka@219.143.36.82) |
04:00.30 | arrrghhh | dv6 |
04:00.43 | arrrghhh | core i7 |
04:00.58 | arrrghhh | 2820QM |
04:01.08 | arrrghhh | has a radeon 6770M w/2gb of video memory too |
04:01.43 | jonpry_ | do you know what the rest of the model number is by chance? |
04:01.53 | arrrghhh | yea 1 sec |
04:02.23 | jonpry_ | is it 1080p? |
04:02.28 | arrrghhh | yea |
04:02.33 | arrrghhh | i got the matte screen |
04:02.38 | arrrghhh | which i really wanted.... |
04:03.21 | arrrghhh | LM720AV |
04:03.23 | arrrghhh | is the product code |
04:03.35 | arrrghhh | dv6t Quad Ed |
04:03.47 | jonpry_ | i'm looking at an asus n53sv-dh72 |
04:03.51 | arrrghhh | asus is good |
04:04.09 | arrrghhh | i was seriously considering one, until i found out it's impossible to get matte on their consumer displays. |
04:04.22 | arrrghhh | i'm a picky bastard. |
04:05.01 | arrrghhh | the dual graphics is kinda shitty too |
04:05.05 | arrrghhh | i would avoid it if you can... |
04:05.21 | jonpry_ | <PROTECTED> |
04:05.24 | arrrghhh | yea |
04:05.26 | arrrghhh | my lappy has it |
04:05.39 | jonpry_ | the intel hd + radeon? |
04:05.42 | arrrghhh | they finally released a BIOS update that mostly fixes it |
04:05.52 | arrrghhh | yea, the core i7 sandy bridge poop has the on-board gfx |
04:05.58 | arrrghhh | and then a dedicated 2gb radeon |
04:06.10 | jonpry_ | i kind of like the asus because its an nvidia. i had lots of trouble with the radeon hd stuff |
04:06.11 | arrrghhh | it can dynamically switch too, but only for Direct3D apps. |
04:06.15 | arrrghhh | yea |
04:06.20 | arrrghhh | i used to be all about nv... |
04:06.30 | arrrghhh | that was one thing i was leery about |
04:06.40 | jonpry_ | my 6570m won't run catia properly |
04:06.44 | arrrghhh | but since they've been absorbed by AMD, i think they've gotten better |
04:06.51 | arrrghhh | that's a pretty new card, damn. |
04:07.39 | jonpry_ | just like linux drivers are not engineering capable. firegl kind of thing |
04:07.57 | arrrghhh | yea |
04:08.15 | jonpry_ | does nv still make the quadro's? |
04:08.20 | arrrghhh | yea |
04:08.24 | arrrghhh | for 'workstations' |
04:08.33 | arrrghhh | usually business line laptops |
04:08.47 | WisTilt2 | hey arrrghhh im here now. grand kids just left so all is quiet again. |
04:08.57 | jonpry_ | used to be you could turn a geforce into a quadro by removing a resistor |
04:09.48 | arrrghhh | heh, nice. |
04:10.40 | WisTilt2 | whats up, you ping me? |
04:10.56 | arrrghhh | yea, just wondering if you made any progress on that monster kernel |
04:12.08 | WisTilt2 | didnt 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.32 | arrrghhh | oh, that's cool |
04:12.40 | arrrghhh | did the toy drive go well? |
04:12.41 | WisTilt2 | beautiful weather, 55degs sunny. last year was miserable cold fog |
04:12.50 | arrrghhh | my company's raised sooo much money with all the drives they did this year... |
04:13.02 | WisTilt2 | yeah we took in nearly 10k toys, tons of canned food etc. |
04:13.08 | arrrghhh | awesome! |
04:13.54 | WisTilt2 | we deliver it later this week to unfortunate families around the county. |
04:14.08 | arrrghhh | very cool |
04:15.35 | WisTilt2 | ill 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.05 | arrrghhh | haha, fair enough. |
04:16.16 | arrrghhh | just very strange that neocore would randomly score so well |
04:16.39 | arrrghhh | but other apps didn't really seem to show it |
04:17.08 | WisTilt2 | yeah i looked at the divisors and they are being changed by something with no logical value so need to figure that out. |
04:17.15 | arrrghhh | hrm |
04:17.16 | arrrghhh | ok |
04:19.24 | WisTilt2 | was that 36fps you got on the #59 or #60 build you remember? |
04:19.48 | arrrghhh | uhm |
04:20.11 | arrrghhh | i think 60 |
04:20.13 | arrrghhh | 36.3 |
04:20.19 | arrrghhh | insane |
04:20.32 | arrrghhh | if it would be that consistently, i'm sure most 3D apps would be fine |
04:20.36 | WisTilt2 | then you got stuck at 27 or so and back down to 20-21? |
04:22.31 | jonpry_ | did you try birds? |
04:22.31 | arrrghhh | back down to 20-22 |
04:22.37 | arrrghhh | jonpry_, some rio version |
04:22.40 | arrrghhh | it was choppy |
04:22.44 | arrrghhh | AFAIK the same |
04:22.54 | arrrghhh | plus quadrant scored the exact same as 'normal'. |
04:24.44 | WisTilt2 | on you on kernel #60 right now? |
04:26.47 | arrrghhh | yessir |
04:26.51 | arrrghhh | been on it since friday |
04:26.55 | arrrghhh | works well, smooth for sure |
04:27.03 | arrrghhh | this has mem OC as well rigth? |
04:27.05 | arrrghhh | right* |
04:27.08 | WisTilt2 | how long ago since you booted it? |
04:27.18 | WisTilt2 | yes 30% oc |
04:27.25 | arrrghhh | lemme see |
04:27.31 | arrrghhh | oh i dropped it this morning |
04:27.35 | arrrghhh | battery popped out :S |
04:27.51 | arrrghhh | only been up about 10 hrs |
04:27.59 | arrrghhh | batt @ 93% :D |
04:28.00 | WisTilt2 | see 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.03 | arrrghhh | battery is awesome. |
04:28.12 | arrrghhh | ok |
04:28.13 | WisTilt2 | yeah battery life should be very good |
04:28.14 | arrrghhh | it probably won't |
04:28.15 | arrrghhh | but i'll look |
04:28.34 | arrrghhh | yea, batt is amazing... |
04:28.47 | WisTilt2 | you running scbs on that ? |
04:29.08 | arrrghhh | no, i haven't mucked with that rootfs stuff or done a calibration in very long... |
04:29.50 | WisTilt2 | k. 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.10 | WisTilt2 | thats with gsensor turned off which helps a bunch |
04:30.19 | arrrghhh | you don't want the dmesg if it doesn't have that pll table right? |
04:30.37 | arrrghhh | it appears to have scrolled off the buffer |
04:30.50 | WisTilt2 | no, need the table, the one that shows the 4 PLL's not the actual clock freq table |
04:30.58 | arrrghhh | i can reboot |
04:31.02 | WisTilt2 | ok |
04:31.28 | WisTilt2 | its different on cdma for sure, just want to verify that 1 more time with another 400 |
04:32.19 | arrrghhh | k rebootin now |
04:33.42 | arrrghhh | WisTilt2, i think scbs in the kernel helps too |
04:33.49 | arrrghhh | winmo was pretty close on the % |
04:33.57 | arrrghhh | 88% |
04:36.01 | WisTilt2 | without 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.19 | arrrghhh | WisTilt2, http://pastebin.com/E7gEcfRn |
04:36.27 | arrrghhh | hahaha |
04:36.41 | arrrghhh | yea, i probably should take a peek back on that thread and do the dance to get it workin again |
04:36.47 | arrrghhh | it did help a ton. |
04:37.06 | arrrghhh | last time i used it, it seemed to create other issues... but that was a while ago. |
04:37.10 | WisTilt2 | oh you running oc'd. did you get the 36fps oc'd or at 528mhz? |
04:37.21 | arrrghhh | uhm |
04:37.23 | arrrghhh | probably oc'd |
04:37.30 | arrrghhh | but it went all over |
04:39.00 | WisTilt2 | try 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.22 | arrrghhh | hrm |
04:39.23 | arrrghhh | ok |
04:39.34 | WisTilt2 | then let me see that dmesg, or just the pll table |
04:39.39 | arrrghhh | sure |
04:41.31 | arrrghhh | the table right after ACPU running at 614400 KHz? |
04:42.07 | WisTilt2 | no, the one with PLL0 @ PLL1 @ etc |
04:43.24 | WisTilt2 | just paste it here, its only 4 lines |
04:43.37 | arrrghhh | ah i see it |
04:43.43 | arrrghhh | ok |
04:45.08 | arrrghhh | 12-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.08 | arrrghhh | 196608000 Hz (196 MHz) |
04:45.11 | arrrghhh | Oo |
04:45.14 | arrrghhh | that pasted like shite |
04:45.20 | WisTilt2 | thats ok i can read it |
04:45.25 | arrrghhh | lol ok |
04:45.30 | WisTilt2 | you're still oc'd |
04:45.52 | arrrghhh | crap i am. |
04:46.03 | arrrghhh | i thought i saved that startup... |
04:46.04 | arrrghhh | wth |
04:46.21 | WisTilt2 | removed the cmd line? |
04:46.49 | *** join/#htc-linux Rob2223 (~Miranda@p4FFF098F.dip.t-dialin.net) |
04:47.43 | arrrghhh | yea |
04:47.47 | arrrghhh | lemme make sure i saved it |
04:48.13 | arrrghhh | ok now i'm really confused |
04:48.23 | arrrghhh | did #60 have OC hardcoded? |
04:48.31 | arrrghhh | i did save the startup. there's no OC statements in my startup |
04:48.59 | WisTilt2 | no, hardcoded was many kernels back until i got the right clocks |
04:49.03 | arrrghhh | HRM |
04:49.04 | arrrghhh | oops |
04:49.05 | arrrghhh | hrm |
04:49.07 | arrrghhh | lemme boot again |
04:50.08 | WisTilt2 | memory is oc'd and gpu is running off its own pll in this one (i think). we did so many tests lol |
04:50.18 | arrrghhh | hahaha |
04:50.20 | arrrghhh | good times ;) |
04:50.33 | WisTilt2 | yeah they are |
04:51.37 | arrrghhh | ACPU running at 528000 KHz |
04:51.38 | arrrghhh | boom |
04:51.42 | arrrghhh | PLL0 @ f8005300: MODE=00000007 L=0000000c M=00000004 N=00000005 freq=245760000 Hz (245 MHz) |
04:51.45 | WisTilt2 | now we're talking |
04:51.48 | arrrghhh | PLL1 @ f800531c: MODE=00000007 L=00000032 M=00000000 N=00000001 freq=960000000 Hz (960 MHz) |
04:51.53 | arrrghhh | PLL2 @ f8005338: MODE=00000007 L=00000037 M=00000000 N=00000001 freq=1056000000 Hz (1056 MHz) |
04:51.58 | arrrghhh | PLL3 @ f8005354: MODE=00000000 L=0000000a M=00000006 N=00000019 freq=196608000 Hz (196 MHz) |
04:52.03 | arrrghhh | PLL3 is the GPU now right? |
04:52.27 | WisTilt2 | yep but 196mhz is only at boot. i set it up when hw3d inits |
04:52.34 | arrrghhh | ah |
04:52.43 | WisTilt2 | this build its running at 250 |
04:53.07 | WisTilt2 | now see what you get in neocore |
04:53.36 | arrrghhh | ok |
04:53.38 | jonpry_ | why would they run the gpu at 1/5 of its power? |
04:53.56 | arrrghhh | cuz it's winmo |
04:54.03 | arrrghhh | what is the gpu used for thar |
04:54.05 | arrrghhh | nothing. |
04:54.30 | jonpry_ | our 3d scores are different from hero etc? |
04:54.33 | WisTilt2 | the 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.49 | WisTilt2 | or never notice i dont know |
04:55.03 | WisTilt2 | should be off pll1/4, that would be 240mhz |
04:55.04 | arrrghhh | jonpry_, never really looked |
04:55.32 | arrrghhh | looks like 34-35 |
04:55.45 | WisTilt2 | you're getting 34+ again now? |
04:55.51 | arrrghhh | WisTilt2, sorry |
04:55.57 | arrrghhh | googling for hero scores |
04:56.03 | arrrghhh | waiting for it to settle ;) |
04:56.23 | WisTilt2 | before you run it do you kill all apps you can? |
04:56.37 | arrrghhh | well i don't have many installed |
04:56.38 | arrrghhh | but i can try |
04:56.56 | jonpry_ | 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.33 | WisTilt2 | too bad neocore doesn't show fps in realtime |
04:57.40 | arrrghhh | 34.0 running cm6.1, kernel #589, oc'd to 750mhz |
04:57.42 | arrrghhh | WisTilt2, no joke. |
04:57.48 | arrrghhh | i was thinking the same thing lol |
04:58.25 | jonpry_ | or is this a 70hz panel? |
04:58.33 | WisTilt2 | what device is that 34.0 on? |
04:58.41 | arrrghhh | hero ^^ |
04:58.49 | arrrghhh | WisTilt2, 21.5... |
04:58.50 | WisTilt2 | yes our panels are 50-70hz thats it |
04:59.02 | WisTilt2 | so we're never going higher than 35 |
04:59.09 | WisTilt2 | give or take a couple |
04:59.21 | jonpry_ | i still don't understand that |
04:59.31 | jonpry_ | why can't we go to like 70 |
05:00.24 | WisTilt2 | i never understood that either but framerate is always going to be 1/2 refresh rate. |
05:00.47 | jonpry_ | until we fix it maybe |
05:02.02 | arrrghhh | 20.6 w/sound |
05:02.24 | WisTilt2 | should 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.50 | WisTilt2 | arrrghhh what did you do friday night that got you back up to 27.7 or so after it dropped from 36fps? |
05:03.02 | arrrghhh | i don't know, honestly |
05:03.14 | arrrghhh | typically neocore would score great if i ran it first thing |
05:03.16 | arrrghhh | then it wouldn't again. |
05:03.38 | jonpry_ | 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.38 | arrrghhh | i don't know what brought it back up, perhaps a sleep/wake cycle... |
05:03.59 | WisTilt2 | well 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.06 | arrrghhh | cool |
05:04.44 | arrrghhh | tomorrow's gonna be nuts. |
05:04.50 | arrrghhh | so is tuesday.... |
05:04.55 | jonpry_ | 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.12 | WisTilt2 | jonpry that is probably whats happening. almost acts like there is some deliberate delay to skip 1 vsync each time. |
05:06.37 | WisTilt2 | np 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.27 | arrrghhh | sounds good |
05:07.32 | arrrghhh | going to be working late mon/tue |
05:07.37 | arrrghhh | might have some downtime, not sure when tho lol |
05:07.57 | arrrghhh | DR testing/component fail testing monday, then cutting the next business unit to the new call center tuesday. |
05:08.01 | WisTilt2 | ping me if you get on, if not it will wait |
05:08.12 | WisTilt2 | damn, sounds like fun |
05:08.15 | arrrghhh | sounds like a plan |
05:08.26 | arrrghhh | good times indeed. if only i was hourly, lol |
05:08.45 | WisTilt2 | at&t is turning up another couple gigabit lines for us on thursday also so that should be fun |
05:09.25 | arrrghhh | nice |
05:09.33 | WisTilt2 | easier than moving to a new call center im sure |
05:09.40 | arrrghhh | yea we got some 2gbit backhaul to our DR site now |
05:09.47 | arrrghhh | metroethernet i think? |
05:09.58 | arrrghhh | our 24hr dept is in house |
05:09.59 | WisTilt2 | at&t optiman or what? |
05:10.05 | arrrghhh | i'm actually not sure. |
05:10.10 | arrrghhh | they don't let me touch a lot of the core stuff |
05:10.19 | arrrghhh | i ask questions and look at things, still learning :P |
05:10.34 | WisTilt2 | smart. let someone else break it:) |
05:10.41 | arrrghhh | they mostly pulled me onto this team for my server/linux experience. |
05:10.42 | arrrghhh | heh |
05:16.31 | WisTilt2 | jonpry you dont think this has anything to do with this fake_vsync function do you? i really dont know what thats for. |
05:17.27 | jonpry_ | i don't either |
05:17.45 | jonpry_ | i think we are using real vsync though |
05:19.02 | WisTilt2 | we have a vsync irq handler but also this fake vsync that sets up hrtimer |
05:20.01 | WisTilt2 | looks 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.20 | jonpry_ | are 2d apps pegged at 30 as well? |
05:24.44 | arrrghhh | jonpry_, fps2d seems to say so |
05:24.49 | *** join/#htc-linux mitsutaka (~mitsutaka@219.143.36.82) |
05:24.51 | arrrghhh | but if you turn off the screen it goes to like 90 or something |
05:29.00 | jonpry_ | <PROTECTED> |
05:29.01 | jonpry_ | <PROTECTED> |
05:29.01 | jonpry_ | <PROTECTED> |
05:29.41 | jonpry_ | 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.07 | jonpry_ | probably calls msmfb_pan_update() |
05:33.58 | jonpry_ | 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.10 | WisTilt2 | im looking at pan update and dont know about this 50ms wait on vsync. |
05:34.37 | jonpry_ | shouldn't wait at all |
05:35.22 | jonpry_ | but i don't see what in that code would actually wait for anything |
05:35.35 | WisTilt2 | why does pan update call request vsync? the callback that was setup should trigger that on vsync |
05:36.51 | WisTilt2 | the 50ms supposedly is the wake lock/4 but that doesnt delay anything |
05:37.22 | jonpry_ | request_vsync probably does it |
05:37.22 | WisTilt2 | i mean wakelock/20 not 4 |
05:37.22 | *** join/#htc-linux rajkosto (~rajkosto@2001:470:d76b:da7a:e53a:7443:ff9d:8299) |
05:40.25 | jonpry_ | and that fake vsync should probably happen asap |
05:40.35 | arrrghhh | oh well. bedtime, talk to you gents tomorrow. |
05:40.43 | WisTilt2 | nite arrrghhh |
05:41.24 | WisTilt2 | that 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.42 | jonpry_ | for now it gets us a new thread |
05:41.49 | jonpry_ | can't just remove it |
05:42.07 | WisTilt2 | i mean remover timer and just make the fake call right away |
05:42.42 | jonpry_ | i dunno. i think the code won't be run in the correct context |
05:42.50 | jonpry_ | might work, maybe not |
05:43.14 | jonpry_ | 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.39 | WisTilt2 | job for tomorrow. im beat and going to hit the sack. |
05:44.12 | jonpry_ | k, good night |
05:44.46 | WisTilt2 | catch 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.03 | toastcfh | jonpry_, seen the display code still supports 7k and none overlay devices |
06:23.27 | toastcfh | think u gotta use ashmem tho (if ur not already |
06:24.57 | toastcfh | idunno if 7k would support ion tho |
06:37.15 | *** join/#htc-linux rzk (~rzk@95-24-54-101.broadband.corbina.ru) |
06:42.54 | jonpry_ | 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.10 | Blista | hya |
18:59.50 | Blista | does 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.24 | jonpry_ | hey WisTilt2 |
19:11.37 | WisTilt2 | Morning |
19:12.08 | jonpry_ | i tried turning off that request_vsync last night. |
19:12.21 | WisTilt2 | messing with fb. changed hrtimer to 1 and no difference. something with number pixels though |
19:12.26 | jonpry_ | sort of works but the framebuffer hangs randomly |
19:12.49 | jonpry_ | i think it crashes mdp |
19:13.13 | WisTilt2 | yeah 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.34 | WisTilt2 | does android default to 32bbp or what? |
19:14.19 | jonpry_ | 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.10 | jonpry_ | i have some newer msm_fb code that looks not terribly hard to integrate |
19:15.19 | WisTilt2 | look at the dma section - what value is BYTES_PER_PIXEL? panel is initialized to 16bpp |
19:16.16 | jonpry_ | its 2 unless someone changes format to 32bpp |
19:17.19 | WisTilt2 | this 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.25 | jonpry_ | i think the most straightforward way to fix this is to just run pan_update in a workqueue |
19:17.52 | WisTilt2 | thats an idea |
19:17.53 | detule | hey guys |
19:18.06 | jonpry_ | hey |
19:18.10 | detule | jonpry_, i am about to refresh the 3.1 tree |
19:18.27 | jonpry_ | i dunno what all this crud is for in pan_update but getting rid of it seems to cause lots of problems |
19:18.44 | jonpry_ | to a new minor? |
19:18.58 | detule | no no, just the gitorious 3.1 tree |
19:19.12 | jonpry_ | oh pushing? |
19:19.15 | detule | yeah |
19:19.20 | jonpry_ | cool |
19:19.45 | detule | also 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.02 | jonpry_ | nice. yeah i think the history is not helpful |
19:20.47 | jonpry_ | almost time for a 3.2 kernel :p |
19:21.23 | detule | let them get out of rc |
19:21.28 | jonpry_ | we probably need to switch to this clkdev driver. its going to get more and more complicated to run newer kernels |
19:22.07 | detule | pushed |
19:22.24 | jonpry_ | 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.09 | sbryan12144 | does 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.20 | Alex[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.24 | WisTilt2 | Alex[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.10 | WisTilt2 | rpierce99: if you are bored, can you give this kernel a neocore test on your 400? |
21:37.29 | rpierce99 | yep |
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.54 | rpierce99 | 23.8 |
21:52.17 | WisTilt2 | not bad |
21:52.21 | WisTilt2 | with or without sound? |
21:52.23 | rpierce99 | my best |
21:52.24 | rpierce99 | without |
21:52.37 | WisTilt2 | should hang around 24fps +/- |
21:52.38 | rpierce99 | and i do have the oc line in startup, i know there was some discussion of that |
21:53.14 | WisTilt2 | how 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.21 | rpierce99 | 614400 |
21:54.04 | WisTilt2 | 614 up to 672 should increase it i think |
21:54.37 | WisTilt2 | at 614 your best was around 21? |
21:54.46 | rpierce99 | previously 21.8 or so |
21:58.58 | detule | i take it this new kernel has the ondemand adjustments |
21:59.05 | detule | perhaps you are seeing ondemand increase + cmd line oc |
21:59.15 | detule | i score ~23 with no oc |
21:59.38 | WisTilt2 | detule is that on this new kernel? i assume you dl'd it:) |
21:59.50 | detule | no no, i mean stock autobuild |
22:00.21 | WisTilt2 | hmm, 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.24 | detule | i am saying 23.8 is not significantly over 23, it could be just his cmd line OC that's causing it |
22:00.48 | rpierce99 | is 676800 the proper multiple? |
22:01.13 | detule | i will later tonight when i get home I am about to punch out of the office |
22:01.13 | WisTilt2 | 672000 |
22:01.21 | WisTilt2 | id go with that |
22:01.34 | WisTilt2 | next jump would be 691200 |
22:02.35 | detule | what i can try though is stock + oc for comparison |
22:02.52 | WisTilt2 | detule: 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.06 | WisTilt2 | yes try that if you can for a baseline |
22:03.16 | detule | rpierce99, what's your cmdline oc parameter? |
22:03.43 | rpierce99 | it was 614400, i just changed it to 672000 |
22:03.49 | rpierce99 | i'll try stock next |
22:04.04 | detule | i mean the syntax :) |
22:04.11 | detule | i've never oc-ed android |
22:04.18 | rpierce99 | haha yeah i had to google it |
22:04.55 | rpierce99 | acpuclok.oc_freq_khz= |
22:04.58 | rpierce99 | oops |
22:05.03 | rpierce99 | acpuclock |
22:06.32 | detule | rpierce99, shouldn't it be acpuclock-arm11 |
22:06.58 | emwe | .35 stock, no oc (because not added), 22.7fps w/o sound. just fyi. |
22:07.28 | rpierce99 | http://xdandroid.com/wiki/FAQ#How_do_I_overclock.3F |
22:07.35 | detule | that's not relevant to .39 |
22:07.42 | rpierce99 | no one told me that :) |
22:07.45 | detule | perhaps WisTilt2 can chime in |
22:09.26 | detule | should be able to check the sysfs entry right |
22:09.28 | WisTilt2 | acpuclock-arm11.oc_freq_khz= |
22:09.38 | rpierce99 | facepalm |
22:09.53 | WisTilt2 | thats for .39 and up, .27 i thik is still like rpierce99 has it |
22:10.21 | rpierce99 | that explains the 23.9 i just pulled |
22:11.33 | detule | that'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.28 | detule | i dont think my phone likes 672 |
22:12.33 | detule | it's dragging |
22:12.39 | detule | stutter stutter |
22:13.09 | WisTilt2 | need 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.29 | detule | well it just rebooted me to winmo |
22:13.35 | detule | k calling it a day later folks |
22:13.42 | WisTilt2 | yeah that sounds like it doesnt like that much oc |
22:13.51 | WisTilt2 | cul |
22:14.35 | WisTilt2 | rpierce99 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.07 | jonpry_ | 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.40 | jonpry_ | i'm very confused as to how your supposed to use this pmem driver |
22:21.39 | rpierce99 | 24.3fps |
22:21.58 | rpierce99 | @672 |
22:22.35 | *** join/#htc-linux jonpry (~jon@unaffiliated/jonpry) |
22:23.16 | rpierce99 | 24.6fps on second run |
22:24.19 | detule | jonpry, what if you change that no_allocator =0 |
22:24.46 | jonpry | the pmem pool has no_allocator=1 |
22:25.13 | detule | so that means one thing at a time |
22:25.15 | detule | right? |
22:26.30 | jonpry | gralloc normally uses this PMEM_CONNECT thing to do it |
22:28.07 | detule | yeah but it also does PMEM_MAP |
22:28.45 | jonpry | so i want the same effect as however it does it. but not out of the pool. |
22:28.46 | jonpry | http://gitorious.org/xdandroid-eclair/xdandroid-hardware_msm7k/blobs/froyo/libgralloc/gralloc.cpp#line344 |
22:29.03 | jonpry | i am rewriting the if(){} block at that location |
22:29.08 | WisTilt2 | rpierce99 so it didn't make a huge jump oc'd thats good and what i was hoping to see |
22:29.57 | WisTilt2 | jonpry doesn't no_allocator only need to be set if its cached? |
22:30.53 | jonpry | i 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.22 | jonpry | so i'm wondering if ioctl(fd, PMEM_CONNECT, gpu1_fd); would even work |
22:31.37 | jonpry | unfortunately its difficult to try |
22:32.27 | detule | i don't think no_allocator has to do with cached or not |
22:32.31 | detule | it just means that pmem doesn't manage it |
22:32.43 | detule | whenever someone requests that pmem -> pmem driver just gives it all up |
22:32.48 | detule | and sets a flag that says allocated |
22:32.54 | detule | nothing else can request anything from it |
22:33.00 | detule | on release it unsets the allocated flag |
22:33.10 | jonpry | unless you use connect and map? |
22:34.12 | jonpry | also would fd = open("/dev/pmem", O_RDWR, 0); be correct or would it also open /dev/pmem_gpu1 ? |
22:34.24 | WisTilt2 | no_allocator is an indicator whethere maps of that region should be cached or not |
22:35.06 | jonpry | thats not .cached = 1 |
22:35.08 | detule | WisTilt2, that's the wrong line |
22:35.11 | detule | it'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.45 | detule | i 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.00 | WisTilt2 | guess im reading this wrong but this is the line im talking about-> |
22:37.01 | WisTilt2 | unsigned no_allocator; |
22:37.01 | WisTilt2 | /* indicates maps of this region should be cached, if a mix of |
22:37.01 | WisTilt2 | <PROTECTED> |
22:37.01 | WisTilt2 | <PROTECTED> |
22:37.26 | WisTilt2 | ah, comment is above that you're saying? |
22:37.30 | detule | yes |
22:37.39 | WisTilt2 | im going back to gpu work, you guys sort that out |
22:38.28 | detule | no_allocator=1 is an easy out for pmem.c |
22:38.34 | WisTilt2 | rpierce99 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.40 | jonpry | urg |
22:48.41 | rpierce99 | 24.0 on the first run @ 614400 |
22:49.52 | rpierce99 | 24.3 second run |
22:50.05 | detule | jonpry, so this PMEM_MAP is what managing the memory within that one file/fd |
22:50.27 | WisTilt2 | rpierce99 what was it without oc'ing? |
22:50.44 | rpierce99 | 24.8 |
22:50.45 | rpierce99 | err |
22:50.46 | rpierce99 | 23.8 |
22:51.24 | WisTilt2 | not 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.57 | WisTilt2 | now 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.50 | jonpry | detule, 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.02 | d3tul3 | jonpry, so what all the work is done by the userland allocator |
23:22.47 | jonpry | that has always been the case |
23:22.55 | d3tul3 | that 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.31 | jonpry | so how do i say that the offset is relative to gpu1? |
23:24.00 | d3tul3 | isn't that automatic from the fact that you are requesting from pmem/gpu1? |
23:24.40 | jonpry | the existing gralloc takes it from the 32mb deal. i am unsure how to explain that i want it from gpu1 |
23:24.57 | jonpry | i already have a thing that calculates the correct value of offset relative to gpu1 base |
23:26.43 | d3tul3 | i don't get it you do one mmap operation on gpu1 that returns a base and store a FD |
23:27.30 | d3tul3 | then you use sAllocator.allocate(size); which returns an offset particular to that base |
23:27.46 | jonpry | i have an fd |
23:27.56 | jonpry | and sAllocator is not used anymore |
23:28.30 | d3tul3 | no userland allocator? |
23:28.49 | jonpry | libGLES is doing it |
23:29.11 | jonpry | so just open("/dev/pmem"); ioctl(fd,PMEM_CONNECT, gpu1_fd) ? |
23:31.41 | d3tul3 | open 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.47 | d3tul3 | em |
23:34.17 | *** join/#htc-linux lamikr (lamikr@nat/nokia/x-nganwugxuuljaimi) |
23:38.30 | d3tul3 | "open will return a fd" <- lol deep words of wisdom |
23:39.25 | rpierce99 | that's the kind of wisdom we keep you around for d3tul3 |
23:39.58 | jonpry | somehow this seems to work. fd = open("/dev/null", O_RDONLY); |
23:40.13 | jonpry | so i am officially confused |
23:43.57 | jonpry | figure 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) |