| freemangordon | omg, SW rendering works :D | 10:45 |
|---|---|---|
| uvos | freemangordon: yay :) | 11:11 |
| uvos | freemangordon: hows performance? comperable to ddk1.9? | 11:12 |
| uvos | (with -video-omap) | 11:12 |
| Wizzup | freemangordon: \o/ | 11:32 |
| Wizzup | MVP ;) | 11:32 |
| Wizzup | of the month or somethin | 11:32 |
| Wizzup | g | 11:32 |
| uvos | yeah this is massive boon for leste | 11:33 |
| uvos | soon we can have just one kernel for everything | 11:33 |
| Wizzup | mhm | 11:48 |
| freemangordon | Wizzup: no idea, it is 2d only still | 12:27 |
| freemangordon | would you recommend 2d benchmark? | 12:27 |
| Wizzup | freemangordon: I recall one, just a minute... | 12:29 |
| Wizzup | x11perf? | 12:30 |
| freemangordon | ok, thanks | 12:33 |
| freemangordon | could you run it on d4 with omap driver (and no h-d running)? | 12:34 |
| Wizzup | maybe some others from https://www.phoronix.com/scan.php?page=news_item&px=GLAMOR-EXA-2D-Ubuntu-16.04 | 12:34 |
| Wizzup | yeah, sure, I can do that | 12:34 |
| Wizzup | now? | 12:34 |
| freemangordon | no, when you have time | 12:35 |
| freemangordon | I want to have some values to compare to | 12:35 |
| Wizzup | ok | 12:35 |
| Wizzup | trying to find xperf in debian atm | 12:36 |
| Wizzup | looks like it is x11-apps, but my d4 cannot find it | 12:37 |
| Wizzup | ok, the repo cache was unhappy or something, installing no | 12:39 |
| Wizzup | w | 12:39 |
| Wizzup | any idea what in particular to benchmark? | 12:39 |
| freemangordon | x11perf -scroll500 | 12:39 |
| Wizzup | funny, it's worse without h-d running | 12:40 |
| Wizzup | with h-d: | 12:40 |
| Wizzup | 600 reps @ 8.7288 msec ( 115.0/sec): Scroll 500x500 pixels | 12:40 |
| Wizzup | without h-d: | 12:40 |
| Wizzup | 400 reps @ 13.7097 msec ( 72.9/sec): Scroll 500x500 pixels | 12:40 |
| uvos | im not sure how usefull xperf is | 12:41 |
| uvos | no one draws xorgs primitives anymore | 12:41 |
| uvos | mostly pixmaps are blited | 12:41 |
| Wizzup | what do you suggest then? | 12:41 |
| uvos | how fast you can blit and transform a pixmap is more relevant | 12:41 |
| Wizzup | gtkperf? | 12:41 |
| uvos | that would work yeah (gtk2 3 would use gl), but there was a | 12:42 |
| uvos | nother utility for this.. | 12:42 |
| Wizzup | running gtkperf atm | 12:42 |
| uvos | xperf copywin* actually should be ok | 12:44 |
| Wizzup | yes that is also what I was thinking | 12:44 |
| Wizzup | but gtkperf is running now | 12:44 |
| uvos | also cpyplane and putimage | 12:44 |
| Wizzup | it has a scroll test | 12:44 |
| uvos | not sure how its implemented tho | 12:44 |
| uvos | i would shy away from that one | 12:44 |
| Wizzup | freemangordon: gtkperf https://dpaste.com/58WAC4Z7Q | 12:45 |
| uvos | but yeah xperf has more relevant tests than i tought | 12:45 |
| Wizzup | how about -comppixwin500 | 12:45 |
| uvos | yeah | 12:46 |
| Wizzup | x11perf -comppixwin500 = 4000 trep @ 10.2475 msec ( 97.6/sec): Composite 500x500 from pixmap to window | 12:46 |
| Wizzup | without h-d | 12:46 |
| Wizzup | with h-d running: | 12:48 |
| Wizzup | 4000 trep @ 10.7185 msec ( 93.3/sec): Composite 500x500 from pixmap to window | 12:48 |
| Wizzup | freemangordon: ^^ | 12:48 |
| uvos | how dose x11perf -copypixwin500 | 12:49 |
| uvos | do | 12:49 |
| uvos | interestingly on desktop (glamor) this perfroms the same as comp | 12:50 |
| freemangordon | lemme check | 12:54 |
| freemangordon | what is x11perf -rect500 ? | 12:56 |
| freemangordon | 3600 reps @ 1.4711 msec ( 680.0/sec): Composite 500x500 from pixmap to window | 12:59 |
| freemangordon | 3600 reps @ 1.4348 msec ( 697.0/sec): Copy 500x500 from pixmap to window | 13:01 |
| freemangordon | but, this is without sync | 13:02 |
| Wizzup | freemangordon: -rect500 is 10000 trep @ 2.9374 msec ( 340.0/sec): 500x500 rectangle | 13:32 |
| Wizzup | without h-d | 13:32 |
| Wizzup | so whatever you have already seems faster | 13:34 |
| Wizzup | (by a lot) | 13:35 |
| freemangordon | 20000 reps @ 0.4609 msec ( 2170.0/sec): 500x500 rectangle | 13:35 |
| freemangordon | yeah | 13:35 |
| freemangordon | and this is without pvr 2d accelleration | 13:35 |
| Wizzup | so the code you have now, it can also render 3d in x? | 13:36 |
| Wizzup | as in, h-d can work and stuff?) | 13:36 |
| freemangordon | 3d is trough mesa as of now | 13:38 |
| freemangordon | on d4 and 5.15 there is some issue with 3d | 13:38 |
| freemangordon | hmm, why TS does not work? | 13:38 |
| uvos | you built a kernel without touchscreen-buttons | 13:38 |
| uvos | i presume | 13:38 |
| uvos | wayland 3d works fine on d4 | 13:38 |
| uvos | but yeah with chromeos mesa | 13:39 |
| uvos | on d4 has issues | 13:39 |
| freemangordon | chromeos mesa here too | 13:39 |
| freemangordon | yeah | 13:39 |
| Wizzup | freemangordon: I guess you don't know for sure about n900 and you're testing on d4 for speed reasons? | 13:39 |
| freemangordon | yes | 13:39 |
| Wizzup | ok | 13:39 |
| freemangordon | but, I don;t see a reason for 3d to work ATM as I still have to implemnt the code that renders PRESENT bos :) | 13:40 |
| uvos | freemangordon: if you have a kernel without ts-buttons | 13:40 |
| uvos | freemangordon: you have to drop https://github.com/maemo-leste/leste-config/blob/master/leste-config-mapphone/lib/udev/rules.d/85-input-devices.rules.leste | 13:40 |
| uvos | since it makes libinput ignore the other ts driver | 13:40 |
| freemangordon | uvos: ok, thanks. I have to reboot the device after that, right? | 13:43 |
| uvos | udevadm --trigger | 13:43 |
| uvos | should be enough | 13:43 |
| freemangordon | ok | 13:43 |
| uvos | its udevadm trigger | 13:43 |
| freemangordon | wait, I alredy have 85-input-devices.rules -> 85-input-devices.rules.leste | 13:45 |
| uvos | you have to remove it | 13:45 |
| freemangordon | ah | 13:45 |
| uvos | "you have to drop ...." | 13:45 |
| freemangordon | ah, *drop* :D | 13:45 |
| freemangordon | I read that as 'drop there" | 13:45 |
| uvos | ah ok | 13:45 |
| freemangordon | ok, works now | 13:46 |
| freemangordon | well, h/d is trough llvmpipe | 13:47 |
| Wizzup | because of the 3d problem? | 13:47 |
| freemangordon | mhm | 13:47 |
| freemangordon | Wizzup: re n900 - so far I saw no isses | 13:57 |
| freemangordon | but until I implement EGL rendering of bo, 3d will simply not be visible | 13:58 |
| freemangordon | unless through llvmpipe ofc | 13:58 |
| freemangordon | cool, rotation works :) | 13:58 |
| Wizzup | right @ n900 | 14:00 |
| freemangordon | Wizzup: https://pastebin.com/kMJjJ1CP | 15:13 |
| freemangordon | :) | 15:13 |
| freemangordon | 10x improvement without HW acceleration is not that bad I would say | 15:14 |
| bencoh | indeed :) | 15:19 |
| uvos | aslo means it will do atleast ok on n900 | 15:24 |
| freemangordon | mhm | 15:25 |
| uvos | since n900 is about 1/5 the speed on threaded loads | 15:25 |
| freemangordon | yeah, but lets see how it will behave when we have both 2d and 3d, implementing ATM | 15:25 |
| _inky | hey hey, will your gfx improvements affect pinephone? | 15:49 |
| freemangordon | they should | 16:03 |
| freemangordon | but we can;t be sure until we try it | 16:03 |
| _inky | heh | 16:14 |
| _inky | should i update from -devel? | 16:14 |
| lyubov | /close | 16:54 |
| uvos | _inky: no its not something installable yet | 16:56 |
| _inky | okay (: | 17:20 |
| Wizzup | freemangordon: how will that improve pinephone? with glamor disabled you mean? | 17:41 |
| freemangordon | no, I mean I am not using pvr2d and still have 10x faster than omap driver we use currently | 17:42 |
| freemangordon | ah | 17:42 |
| freemangordon | I think rendering in 3d text and such is stupid | 17:42 |
| Wizzup | right, but pinephone uses glamor with lima | 17:42 |
| uvos | rendering 3d text ans sutch is not supid on modern desktop hardware | 17:43 |
| freemangordon | so? it has 4 cores that I am sure can perform 2d ops faster | 17:43 |
| uvos | not by any strech | 17:43 |
| freemangordon | on mobile | 17:43 |
| uvos | Wizzup: it helps pp by avoiding bugy opengl on it | 17:43 |
| freemangordon | this one too | 17:43 |
| uvos | so it gets slower but is useable | 17:43 |
| Wizzup | yeah ok | 17:43 |
| freemangordon | is it? I remember terrible rendering artifacts last time I tried it | 17:43 |
| Wizzup | I think for lima artifacts and stability are more of a problem than scrolling perf | 17:44 |
| freemangordon | but thing could have improved since then, yeah | 17:44 |
| Wizzup | and others *might* fix tha tt for us | 17:44 |
| freemangordon | oh, it is GL, not GLES? | 17:45 |
| Wizzup | freemangordon: yeah mali driver was better than lima in terms of stability and perf, but eh | 17:45 |
| Wizzup | yes lima driver does both | 17:45 |
| freemangordon | ok | 17:45 |
| freemangordon | because I aim es2 only | 17:45 |
| uvos | thats fine | 17:45 |
| uvos | its ogl thats broken | 17:45 |
| freemangordon | ok | 17:45 |
| freemangordon | good | 17:45 |
| uvos | (according to others) | 17:45 |
| uvos | i dont have a pp ofc | 17:46 |
| freemangordon | so, we should see an improvement, because X renders directly on mmaped video memory | 17:46 |
| freemangordon | instead of rendering to memory pixmap and then bliting | 17:46 |
| uvos | ok | 17:47 |
| uvos | depends on kernel bahvior | 17:47 |
| uvos | ofc | 17:47 |
| uvos | hw wise the kernel should be able to just ajust the mmu to move the ram from cpu to gpu area and back | 17:47 |
| freemangordon | and for 3d/present, we (will) have a simple shader that just renders a texture | 17:47 |
| uvos | no idea if the kernel dose so in practice | 17:47 |
| freemangordon | it does | 17:47 |
| uvos | ok | 17:47 |
| uvos | great | 17:47 |
| freemangordon | at least thta's what I think happens | 17:47 |
| freemangordon | for SGX | 17:47 |
| freemangordon | because I see driver traces setting SGX mmu in chunks of a page | 17:48 |
| freemangordon | even if we are hit by a perf penalty because of cache flushes and such, we still should be faster than copying | 17:48 |
| freemangordon | in theory (tm) | 17:49 |
| uvos | yeah ofc | 17:49 |
| tmlind | nice | 17:49 |
| uvos | that shouldbe very performant | 17:49 |
| freemangordon | and we see it | 17:49 |
| tmlind | freemangordon: any luck getting droid4 to update the display? | 17:49 |
| freemangordon | 10x improvement for 2d | 17:49 |
| freemangordon | tmlind: the issue is that SGX recovery gets triggered | 17:49 |
| tmlind | ah | 17:50 |
| freemangordon | not that display is not updated | 17:50 |
| tmlind | ok | 17:50 |
| freemangordon | see backscroll, with my (half-baked) xf86-video-modesetting-module-gbm we see ~10x improvement in 2d ops compared to omap driver | 17:51 |
| uvos | are you calling the drm display update thing | 17:51 |
| uvos | there is an ioctl to update comannd mode displays | 17:52 |
| freemangordon | this is modesetting with a glamor replacement which performs all 2d in SW (so far, I plan to implement 2d in SGX) | 17:52 |
| uvos | iirc | 17:52 |
| freemangordon | uvos: no, I guess modesetting does that for me | 17:52 |
| freemangordon | mind you, I am replacing glamor, not the whole ddx | 17:52 |
| freemangordon | glamors just renders on BOs provided by MS | 17:52 |
| freemangordon | drm interaction is out of scope | 17:53 |
| freemangordon | but, obviously something updates the display, will record a video of gtkperf running when I get tired | 17:54 |
| freemangordon | though my n90 won;t be able to capture it I guess (30fps) | 17:54 |
| freemangordon | *n900 | 17:54 |
| freemangordon | hmm, is it possible that NEON core cannot read mmaped video memory? | 20:13 |
| freemangordon | tmlind: ^^^? | 20:13 |
| freemangordon | hmm, no, it is not that | 20:17 |
| Wizzup | freemangordon: debugging the d4 problem? | 20:34 |
| freemangordon | no, Xorg was segfaulting | 20:48 |
| freemangordon | but I found the reason | 20:48 |
| Wizzup | ok | 20:52 |
| freemangordon | gtkperf on n900: | 21:01 |
| freemangordon | Total time: 72.87 | 21:01 |
| Wizzup | faster than our current d4 path | 21:02 |
| freemangordon | mhm | 21:02 |
| freemangordon | glmark2 Score: 21 | 21:08 |
| freemangordon | but! this is with memcpy of 3d memory to 2d | 21:08 |
| sicelo | Magic :-) | 21:16 |
| Wizzup | freemangordon: so 3d render shows on screen now? | 21:20 |
| freemangordon | yes | 21:21 |
| Wizzup | :-o | 21:22 |
| freemangordon | going to implement the fast (hopefully) path - GL render of Bo texture | 21:22 |
| Wizzup | check | 21:25 |
| Wizzup | with the simple shader? | 21:25 |
| freemangordon | I hope so | 21:25 |
| * Wizzup too | 21:25 | |
| Wizzup | freemangordon: unrelated but I am getting this: string "Method "SendReceive" with signature "" on interface "com.nokia.modest" doesn't exist | 22:28 |
| Wizzup | oh | 22:31 |
| Wizzup | I think I know what the problem is | 22:31 |
| Wizzup | I think dns is fubar on my device | 22:32 |
| Wizzup | note if the files in /etc/dnsmasq.d/00_leste_dns seem to exist | 22:33 |
| Wizzup | parazyd: ^^ | 22:33 |
| Wizzup | uhhh dnsmasq 5377 0.0 0.2 8172 2076 ? S 22:33 0:00 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -r /run/dnsmasq/resolv.conf -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-service --trust-anchor=.,20326,8,2,e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d | 22:37 |
| Wizzup | /run/dnsmasq/resolv.conf is empty | 22:38 |
| Wizzup | I think this happens because resolvconf is installed | 22:39 |
| Wizzup | (per the dnsmasq initscript) | 22:40 |
| Wizzup | yup, that's it... | 22:41 |
| lel | MerlijnWajer opened an issue: https://github.com/maemo-leste/bugtracker/issues/583 (Installing resolvconf breaks our dnsmasq setup) | 22:43 |
| lel | MerlijnWajer assigned an issue: https://github.com/maemo-leste/bugtracker/issues/583 (Installing resolvconf breaks our dnsmasq setup) | 22:43 |
| Wizzup | pls fix | 22:43 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!