freemangordon | tmlind: uvos: I see absolutely no tearing on d4 HDMI with omap-video | 08:05 |
---|---|---|
freemangordon | so it seems the tearing I see on n900, is not what you see on d4 with sway/weston or whatever you use | 08:06 |
freemangordon | hmm, seems my TV vsync is 50 Hz | 08:09 |
freemangordon | d4, 1920x1080 glmark2 Score: 30 :) | 08:25 |
freemangordon | not that this helps with n900 | 08:26 |
tmlind | freemangordon: ok, yeah i see flicker on d4 hdmi but only after slowing down sgx clock rate as noted by uvos | 08:30 |
tmlind | maybe taking a video of the hdmi output might show some frames with black squares even at the normal sgx clock rate | 08:32 |
freemangordon | could you provide commands to slow down the device? | 08:35 |
freemangordon | or I shall wait for uvos? | 08:35 |
tmlind | looking at my notes pretty sure i use sudo rwmem 0x4a008164=0x1f to slow down sgx, can't check my test script right now | 08:43 |
tmlind | need to go, will drop by again later on | 08:43 |
freemangordon | ok | 08:44 |
freemangordon | tmlind: ok, yeah, I can repro now, thanks | 08:52 |
freemangordon | actually no need for HDMI | 08:54 |
freemangordon | it artefacts badly on DSI as well | 08:55 |
freemangordon | ok, good that I have a test case now | 08:55 |
freemangordon | hmm, ok, seems PVR driver attaches exclusive fense to each BO, bu I doubt omapdrm waits on it | 09:25 |
freemangordon | or. maybe it is core that shall wait, but it does not? | 09:29 |
tmlind | no idea, but the fact it also happens with hdmi means it's not related to the command mode lcd | 10:52 |
freemangordon | tmlind: ok, I think I have an idea what happens | 10:53 |
freemangordon | not sure though, but still | 10:53 |
freemangordon | PVR attaches exclusive fence to BOs it is about to render | 10:53 |
freemangordon | but, I don;t see where omapdrm waits for those fences to get signalled | 10:53 |
freemangordon | so, either PVR signals fences too early, or omapdrm does not wait for fence to be signalled | 10:54 |
freemangordon | this is when flip has been requested | 10:54 |
freemangordon | but, I would say it is omapdrm to blame, as pvr seems to obay its own fences | 10:55 |
freemangordon | like, there is not tear if blit through HW is done | 10:55 |
freemangordon | tmlind: I am trying to find where in omapdrm/drm kernel code is supposed this wait to happen | 10:56 |
freemangordon | so far no luck | 10:56 |
freemangordon | tmlind: also, look at 942d8344d5f14b9ea2ae43756f319b9f44216ba4 | 10:57 |
freemangordon | I am not sure I understand the commit message :) | 10:57 |
tmlind | no idea about that stuff | 10:59 |
freemangordon | hmm, ok, it seems pvr driver sets fence to signalled too early | 12:46 |
freemangordon | tmlind: adding msleep(50); in omap_framebuffer_pin() makes flicker go away | 13:14 |
freemangordon | so, it seems pvr driver doesn't behave correctly in regards to fences | 13:15 |
freemangordon | afaik it should signal exclusive fence only *after* write ops have been completed | 13:16 |
freemangordon | I have no clue how to deal with that | 13:16 |
freemangordon | or, maybe the idea is to add GL fence before calling swap? | 13:20 |
tmlind | freemangordon: interesting if you can make them go away with msleep, will give it a try when i can later on today or tomorrow | 15:11 |
tmlind | uvos might have some ideas based on that on what to fix, i sure don't | 15:12 |
freemangordon | tmlind: well, flicker goes away, but fps is like 10 :) | 16:08 |
tmlind | heh | 16:15 |
Wizzup | building mesa for experimental now | 16:42 |
Wizzup | freemangordon: i think it should be in the experimental repo in ~15 mins | 18:13 |
freemangordon | great | 18:15 |
freemangordon | hmm, what's wrong with usleep? | 18:19 |
freemangordon | usleep(500000); shall sleep for 500 ms, right? | 18:19 |
Wizzup | in C? | 18:20 |
Wizzup | as in userspace? | 18:20 |
bencoh | nah, usleep() wakes up from ALARM | 18:21 |
bencoh | you should use nanosleep | 18:21 |
freemangordon | hmm | 18:22 |
freemangordon | oh, ok | 18:22 |
bencoh | now I'm curious about the fact that you supposedly get an alrm signal, but ... :) | 18:22 |
Wizzup | man 3 usleep does not mention ALARM at all | 18:25 |
freemangordon | bencoh: hmm, I don;t see anyting like that here https://man7.org/linux/man-pages/man3/usleep.3.html | 18:25 |
bencoh | freemangordon: The interaction of this function with the SIGALRM signal [...] | 18:25 |
* freemangordon reads | 18:26 | |
bencoh | (yeah, ALRM, not ALARM) | 18:26 |
bencoh | anyway, it was even removed from posix-2008 :) | 18:27 |
freemangordon | I don't think I receive SIGALRM in xorg, but yeah, who knows | 18:27 |
freemangordon | Wizzup: mesa seems ok | 19:31 |
Wizzup | cool | 19:31 |
Wizzup | there's still the libllvm thing | 19:31 |
Wizzup | but that's for later | 19:31 |
bencoh | what about it? | 19:34 |
Wizzup | our mesa uses/requires (tbd) libllvm8 | 19:36 |
Wizzup | which is only in backports | 19:36 |
bencoh | oh so it builds but doesn't work then? | 19:36 |
bencoh | I mean, it looked like the mesa tests passed | 19:37 |
Wizzup | yes it works | 19:42 |
Wizzup | the package just depends on it | 19:42 |
Wizzup | I don't know what happens if you uninstall the libllvm8 package | 19:43 |
Wizzup | maybe it just works and the control is just overley whiney | 19:43 |
Wizzup | overly* | 19:43 |
Wizzup | or maybe it just works if it's built in CI | 19:43 |
Wizzup | I can't test atm | 19:43 |
Wizzup | man, it's a _royal_ pain to build our droid4-linux locally | 19:43 |
Wizzup | the build scripts seem to be in debian/patches which makes it also really hard to modify :D | 19:44 |
Wizzup | the instructions provided by parazyd also don't work for me | 19:45 |
Wizzup | actually it might work if you manually remove the .pc directory | 19:45 |
Wizzup | nope.. | 19:45 |
Wizzup | it's so insane, I did a clean checkout of the branch and manually applied the patches | 19:46 |
Wizzup | but quilt still manages to complain! | 19:46 |
freemangordon | using nanosleep to sleep 40 msecs before requesting flip makes, in omap-video, makes flickering go away on d4 | 19:46 |
freemangordon | ok, so, obviously a fence is missing | 19:46 |
freemangordon | or is wrongly signaled when it should not be | 19:47 |
Wizzup | btw, the pvr headers we want in kernel, I think all we need to do is to make sure they are considered to be headers to export in the kernel build system itself | 19:48 |
Wizzup | so probably we should not modify the debian packaging but rather the kernel build system | 19:49 |
freemangordon | so, we'll need kernel-headers package to build ddx? | 19:52 |
Wizzup | yes that seems the most sensible solution to me if you want them from the kernel specifically | 19:53 |
freemangordon | ok | 19:53 |
Wizzup | btw, if you can test briefly, does mesa complain if you remove the libllvm8 pkg you installed from backports earlier? | 19:54 |
Wizzup | the one from repos might not need it | 19:54 |
bencoh | Wizzup: ha, so I'm not the only one suffering from droid4-linux? :D | 19:56 |
Wizzup | insanely | 19:56 |
Wizzup | It just works sometimes with various incantations of git clean -fd and other stuff | 19:56 |
bencoh | regarding llvm8, I think I'm missing something ... I don't recall fetching a newer llvm package and it still passed the tests in my lxc container | 19:57 |
Wizzup | yes so it could be that I had it when I build mesa and it just used that | 19:57 |
Wizzup | the CI might not need/depend on it | 19:57 |
Wizzup | I built in the CI a few hours ago | 19:57 |
bencoh | nd it failed? | 19:57 |
Wizzup | there seem to be a lot of droid 4 listings on ebay now | 19:58 |
Wizzup | bencoh: no the CI went fine | 19:58 |
bencoh | ah | 19:58 |
Wizzup | bencoh: we just need tdo check if we still need libllvm8 or not | 19:58 |
bencoh | alright | 19:58 |
bencoh | (moar d4) | 19:59 |
Wizzup | not that many | 19:59 |
Wizzup | I wonder if it's because we asked about it somehow | 19:59 |
Wizzup | they know to ask for more now it seems | 19:59 |
Wizzup | seems to be from the same guy | 20:00 |
Wizzup | ships from germany | 20:01 |
Wizzup | rr italy | 20:01 |
Wizzup | some of them say usb port defect hehe | 20:02 |
freemangordon | bencoh: do you have any knowledge on dmabuf fences? | 20:03 |
Wizzup | calebtheythem[m]: if you search for "motorola photon q" on ebay now there are about 6 phones for 30 usd each, they charge but 'do not turn on' according to the seller | 20:04 |
Wizzup | calebtheythem[m]: more like 10 it looks like | 20:05 |
Wizzup | bencoh: looks like the CI happily pulls from backports: Get: 11 http://pkgmaster.devuan.org/merged beowulf-backports/main armhf libllvm8 armhf 1:8.0.1-3~bpo10+1 [12.0 MB] | 20:22 |
Wizzup | https://phoenix.maemo.org/job/mesa-binaries/architecture=armhf,label=armhf/90/consoleFull | 20:22 |
Wizzup | freemangordon: ok, I think I know how to add kernel headers | 20:35 |
Wizzup | https://github.com/maemo-leste/droid4-linux/blob/maemo-5.15/scripts/package/builddeb#L67 | 20:37 |
Wizzup | so maybe they are already in there | 20:37 |
Wizzup | (building atm) | 20:37 |
freemangordon | ok, lets see | 20:39 |
Wizzup | will take ~1-2 hrs I tihnk | 20:41 |
freemangordon | heh | 20:48 |
lel | norayr opened an issue: https://github.com/maemo-leste/bugtracker/issues/586 (osso-xterm selects, instead of scrolling in portrait mode.) | 20:50 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!