| rafael2k | ofono is ready to go production: https://github.com/rafael2k/ofono | 00:01 |
|---|---|---|
| rafael2k | For people with pp, who want to test new ofono packages: http://173.255.215.196/pinephone/ofono-packaging/ | 00:06 |
| _inky | rafael2k: and thank you too for advices and ideas. | 01:12 |
| _inky | i think eventually we have breakthroughs with pinephone support. | 01:12 |
| _inky | and this is very important: people come to linux phones and operating systems via pinephone. | 01:12 |
| _inky | so maemo will actually get more users via pinephone. | 01:13 |
| _inky | i'll ask these couple of days if i need to update from -devel to get the updates you all made. | 01:14 |
| tmlind | hmm my bionic is all updated now, but not accelerated.. i have sgx-ddk-um-ti443x and xserver-xorg-video-omap installed, kernel module is initialized on boot.. | 07:11 |
| freemangordon | tmlind: check xorg.conf | 08:14 |
| tmlind | freemangordon: don't seem to have one.. should it be under /etc/X11? | 08:14 |
| freemangordon | no, /usr/share/X11/xorg.conf.d | 08:15 |
| tmlind | ok | 08:15 |
| freemangordon | there should be 99-omap | 08:15 |
| tmlind | i have 99-omap.conf symlinked to 99-omap.conf.leste | 08:16 |
| freemangordon | yeah | 08:16 |
| freemangordon | that's fine | 08:16 |
| freemangordon | could you provide xorg log, from /tmp | 08:17 |
| tmlind | ok | 08:17 |
| tmlind | freemangordon: http://muru.com/Xorg.0.log | 08:20 |
| tmlind | not much there for EE errors | 08:20 |
| tmlind | also trying to run glxgears as user user fails | 08:21 |
| tmlind | /dev/dri is group readable/writable for video | 08:21 |
| freemangordon | glxgears? | 08:22 |
| freemangordon | you should run es2_gears | 08:22 |
| tmlind | oh ok | 08:22 |
| freemangordon | OGL is not accelerated | 08:22 |
| freemangordon | brb | 08:22 |
| tmlind | ok es2gears works :) | 08:24 |
| tmlind | stellarium is not accelerated, let me recheck | 08:24 |
| tmlind | starting stellarium as user produces: QXcbIntegration: Cannot create platform OpenGL context, neither GLX nor EGL are enabled | 08:25 |
| tmlind | i can start is as root but it's not accelerated | 08:25 |
| tmlind | fyi | 08:25 |
| tmlind | hmm es2tri triangle is only partially visible somehow | 08:28 |
| freemangordon | does glmark2_es2 work? | 08:34 |
| freemangordon | tmlind: actually, does your device boot to h-d? | 08:34 |
| tmlind | freemangordon: yeah boots now to h-d, looks like stellarium tries to start with sgx with QT_QPA_PLATFORM=eglfs stellarium | 08:40 |
| tmlind | then segfaults | 08:40 |
| tmlind | let me check glmark2_es2 | 08:41 |
| tmlind | hmm can't find glmark2 package.. | 08:42 |
| freemangordon | h-d is accelerated, right? | 08:42 |
| freemangordon | glmark2 shall be compiled, there is no package | 08:42 |
| tmlind | ok, h-d looks a bit jerky, not sure if it's accelerated | 08:43 |
| freemangordon | hmm, weird | 08:43 |
| tmlind | i'm pretty sure h-d is accelerated, only jerky here and there | 08:43 |
| freemangordon | that's weird, should be smooth | 08:43 |
| freemangordon | but well, i have d4 here, not bionic | 08:44 |
| tmlind | should be about the same | 08:44 |
| freemangordon | maybe lets wait for Wizzup to share his experience | 08:44 |
| freemangordon | but swiping h-d should be smooth | 08:45 |
| freemangordon | well, non-accelerated h-d renders with 1-2 fps, so... :) | 08:45 |
| tmlind | yeah it's mostly smooth, sometimes starting a new app the animation is kind of jerky.. | 08:45 |
| freemangordon | ah | 08:46 |
| freemangordon | well, for sure we have issues on omap, there is also tearing and the reported fps looks too high for what is really seens | 08:47 |
| freemangordon | *seen | 08:47 |
| freemangordon | but otherwise is useful | 08:47 |
| tmlind | yup looks way better than earlier :) | 08:50 |
| tmlind | heh looks like gdb shows stellarium segfaults at ssl libcrypto somewhere.. | 08:56 |
| tmlind | ok got stellarium running with QT_QPA_PLATFORM=eglfs stellarium | 08:58 |
| tmlind | sorry with QT_QPA_PLATFORM=eglfs stellarium --home-planet=mars | 08:59 |
| tmlind | some location lookup issue it seems :) | 08:59 |
| tmlind | about 9 fps it seems | 08:59 |
| freemangordon | :) | 08:59 |
| freemangordon | hmm, shouldn;t it be faster? | 08:59 |
| tmlind | i'm seeing someting like 12 fps with wayland | 09:00 |
| freemangordon | ah | 09:00 |
| freemangordon | well, given that compositing is non-accelerated... | 09:00 |
| freemangordon | hmm, maybe I shall RE that part too | 09:00 |
| freemangordon | btw, is it fullscreen? | 09:00 |
| tmlind | yeah it's full screen | 09:01 |
| freemangordon | hmm | 09:01 |
| freemangordon | should be the same like WL | 09:01 |
| freemangordon | if not faster | 09:01 |
| tmlind | let me check again on wl | 09:01 |
| freemangordon | with 'mars' | 09:01 |
| tmlind | uh looks like i have some pvr issue with my wl setup right now, need to check the fps later | 09:07 |
| tmlind | switching from stellarium to h-d window list hung xorg | 09:10 |
| freemangordon | hmm | 09:11 |
| freemangordon | some oops? | 09:11 |
| tmlind | no, Xorg.0.log has many (EE) OMAP(0): ERROR: waitForBlitsCompleteOnDeviceMem: PVR2DQueryBlitsComplete failed with error code: -8 (Blit not complete) | 09:12 |
| freemangordon | this should not result in a hang | 09:13 |
| tmlind | keeps producing them about every 500 ms | 09:13 |
| freemangordon | dmesg? | 09:13 |
| freemangordon | I would say there is HW recovery trigered | 09:13 |
| tmlind | no errors | 09:13 |
| freemangordon | weird | 09:13 |
| tmlind | what should i type to restart xorg? | 09:14 |
| freemangordon | nothing | 09:14 |
| freemangordon | I mean - you shoud restart the device | 09:14 |
| tmlind | killall -9 Xorg at least got fb back | 09:16 |
| freemangordon | yeah | 09:16 |
| freemangordon | hmm, we even have tearing with modesetting without glamor | 09:17 |
| freemangordon | this is omapdrm behaving I would say | 09:17 |
| tmlind | weird now it's behaving after a reboot | 09:23 |
| freemangordon | hmm? | 09:27 |
| freemangordon | you mean there are no issues? | 09:27 |
| tmlind | can't make QT_QPA_PLATFORM=eglfs stellarium --home-planet=mars hang after switching between app view and stellarium | 09:28 |
| freemangordon | it should not :) | 09:29 |
| freemangordon | I was hoping modesetting with glamor will hit > 50 fps on d4 | 09:45 |
| freemangordon | but unfortunately it hits 50fps and that's it | 09:46 |
| freemangordon | and it suffers from the same tearing issue | 09:46 |
| tmlind | anyways a massive upgrade to get rid of all the old buggy legacy crap with the kernels and ddk-1.9 :) | 09:49 |
| * tmlind goes to investigate fridge for the ham | 09:50 | |
| freemangordon | tmlind: any advice on how to deal with omapdrm tearing issue? I need upstream support, but I doubt Tomi will care about that | 09:50 |
| Wizzup | rafael2k: once I get home in ~8 hours I'll look at packaging this stuff, ty | 10:05 |
| Wizzup | 08:56 < tmlind> heh looks like gdb shows stellarium segfaults at ssl libcrypto somewhere.. | 10:06 |
| Wizzup | this is openssl testing instructions (sigill) | 10:06 |
| Wizzup | freemangordon: same for lima bug/video, will do that when I get back | 10:07 |
| freemangordon | ok | 10:08 |
| freemangordon | no hurry | 10:08 |
| Wizzup | :) | 10:12 |
| Wizzup | Just don't have the device here at the moment | 10:12 |
| freemangordon | yay, omapdrm BO patch is in -next :) | 10:14 |
| tmlind | freemangordon: what's the omapdrm tearing issue? | 10:27 |
| tmlind | Wizzup: i guess that openssl issue will get fixed upstream pretty fast | 10:29 |
| freemangordon | tmlind: h-d swiping tears terribly | 10:31 |
| freemangordon | it is clearly visible in portrait | 10:31 |
| freemangordon | rotate you bionic in portrait and swipe | 10:31 |
| freemangordon | *your | 10:32 |
| freemangordon | this happens with both omap and modesetting drivers | 10:32 |
| freemangordon | with modesetting it happens even with no HW accel, though less visible because of low fps | 10:32 |
| freemangordon | I wonder if it is caused by omapdrm starting another flush while still there is a flush in progress | 10:33 |
| freemangordon | but, it happens on hdmi too | 10:33 |
| freemangordon | hmm, actually lemme try again on hdmi | 10:33 |
| freemangordon | yep, there is tearing on HDMI as well | 10:40 |
| tmlind | ok | 10:41 |
| freemangordon | tmlind: hmm, if I lower the SGX frequency to 0x1f, tearing disappears on HDMI | 10:44 |
| freemangordon | I guess by the time the new frame is ready the old one has already been flushed or somesuch | 10:45 |
| tmlind | weird | 10:45 |
| Wizzup | tmlind: I don't think it is an issue, it's just it testing for instructions with sigill signal handler | 10:45 |
| tmlind | does reverting "drm/omap: Fix omap_gem_dma_sync_buffer() when we already have a dma_addr" make it better or worse by any chance? | 10:45 |
| Wizzup | tmlind: as in I don't think this is a bug, you just see it in gdb, but you can type 'c' for continue | 10:45 |
| freemangordon | tmlind: lemme try | 10:46 |
| tmlind | so the test is to swipe the desktop background in portrait mode? | 10:47 |
| freemangordon | yes | 10:47 |
| tmlind | can't seem to make it happen on my bionic | 10:47 |
| freemangordon | the same happens in landscape, but is less visible | 10:47 |
| freemangordon | install marina theme | 10:47 |
| tmlind | i see a bit of flicker if i drag slowly | 10:48 |
| freemangordon | yep | 10:48 |
| freemangordon | hmm, wait | 10:48 |
| freemangordon | tmlind: please install marina theme | 10:48 |
| tmlind | ok | 10:48 |
| freemangordon | it has very sharp transition between backgrounds | 10:49 |
| Wizzup | maybe just share the tearing test image | 10:49 |
| * Wizzup bbiab | 10:50 | |
| freemangordon | marina is in the repos | 10:50 |
| freemangordon | and is cute, also :) | 10:51 |
| tmlind | yup with marina i see a variant of the black squares problem dragging the desktop slowly | 10:54 |
| tmlind | and also tearing between the desktop image borders | 10:55 |
| freemangordon | exactly | 10:55 |
| freemangordon | this is what I mean | 10:55 |
| freemangordon | this happens no matter driver/acceleration | 10:55 |
| freemangordon | thats why I think it is omapdrm | 10:55 |
| tmlind | i'm guessing the black artifacts problem gets worse with "drm/omap: Fix omap_gem_dma_sync_buffer() when we already have a dma_addr" reverted? | 10:56 |
| tmlind | the tearing might get better.. | 10:56 |
| freemangordon | reverting as we speak :) | 10:56 |
| freemangordon | I see no black artifacts though | 10:56 |
| freemangordon | sometimes I see some corrupted pixels (black) in the left top corner | 10:57 |
| tmlind | in portrait mode, slowly keep swiping to the left until you see tiny black rectangles at top right corner | 10:57 |
| freemangordon | ok | 10:57 |
| freemangordon | nope | 10:57 |
| tmlind | top left corner in landscape mode, top right corner in portrait mode | 10:57 |
| tmlind | or is it part of the background image pixmap? | 10:58 |
| freemangordon | nope | 10:58 |
| freemangordon | no | 10:58 |
| tmlind | maybe it's part of the pixmap at the top right in portrait mode at the light blue area just before the dark blue border | 10:59 |
| freemangordon | I see nothing mis-rendered | 10:59 |
| freemangordon | can;t see that here | 10:59 |
| freemangordon | tmlind: sometimes bacground has some corruption, restart fixes that | 10:59 |
| tmlind | i see it on every 4th desktop | 10:59 |
| freemangordon | yep, that one :) | 11:00 |
| freemangordon | it is on top-left in portrait | 11:00 |
| tmlind | yup, so is that supposed to be there? | 11:00 |
| freemangordon | and lives just behind six bars | 11:00 |
| freemangordon | no | 11:00 |
| freemangordon | this is deffinitely a corruption | 11:00 |
| tmlind | yeah that's the black tiles artifacts problem i also see with sway | 11:00 |
| freemangordon | could you take a picture, to confirm we are talking about the same thing | 11:01 |
| tmlind | let me consult my camera operator | 11:01 |
| freemangordon | :D | 11:02 |
| freemangordon | tmlind: honestly, I don;t think this has anything to do with omapdrm | 11:03 |
| freemangordon | this looks like a bug in pvr | 11:03 |
| tmlind | could be | 11:03 |
| freemangordon | oh, lemme revert that patch | 11:04 |
| freemangordon | hmm, this patch looks to me like a reason for low fps :) | 11:08 |
| tmlind | ok :) | 11:08 |
| freemangordon | lets see on the dvice though | 11:08 |
| tmlind | see the black ants at top right corner here http://muru.com/m-l-ants.jpg | 11:08 |
| freemangordon | yes, exactly this | 11:09 |
| freemangordon | reboot fixes it usually | 11:09 |
| freemangordon | this happens more often if your battery is low | 11:09 |
| tmlind | weird | 11:09 |
| freemangordon | but I am almost sure this is either PVR or h-d/clutter bug | 11:10 |
| tmlind | so a variation of the ants problem i see on wayland is a bit larger black rectangles in the same location, top left corner for landscape mode | 11:10 |
| freemangordon | because this corruption is exactly behind and with the size of six squares icon | 11:10 |
| freemangordon | could be | 11:11 |
| freemangordon | but I almost never see that after a reboot | 11:11 |
| freemangordon | only if I play stopping/starting xorg/h-d | 11:11 |
| tmlind | well m-l should revert "drm/omap: Fix omap_gem_dma_sync_buffer() when we already have a dma_addr" if it causes no other issues, wayland is unusable without that patch | 11:12 |
| freemangordon | this should be fixed in wl though | 11:12 |
| tmlind | no idea how it should be fixed :( | 11:12 |
| tmlind | especially if m-l also shows a similar issue on xorg | 11:13 |
| freemangordon | it should use sync | 11:13 |
| freemangordon | xorg uses "wait for blits" | 11:13 |
| freemangordon | but WL can include sync objects in GL commands stream and wait for them, IIUC | 11:13 |
| tmlind | i don't think i've seen the ants with weston | 11:13 |
| freemangordon | ugh, I should have fixed TS buttons udev rules before reboot :( | 11:14 |
| freemangordon | now I have to wait device to autoconnect | 11:14 |
| tmlind | weird how the autoconnect stuff still takes few mins | 11:15 |
| freemangordon | not on pinephone though | 11:15 |
| tmlind | weird | 11:15 |
| freemangordon | so it is something with d4 driver | 11:15 |
| tmlind | i wonder if adding iw dev wlan0 scan on start up would help | 11:15 |
| freemangordon | still tears | 11:16 |
| freemangordon | lemme check fps | 11:17 |
| freemangordon | oh | 11:17 |
| freemangordon | we hit 80 fps with ease | 11:17 |
| tmlind | nice | 11:17 |
| tmlind | maybe check the stellarium on mars rate too? | 11:18 |
| freemangordon | is it in repos? | 11:18 |
| tmlind | yeah apt-get install stellarium | 11:18 |
| tmlind | takes a while for the data files though | 11:19 |
| freemangordon | maep renders with 45 fps though | 11:19 |
| freemangordon | this is with 3-buffer | 11:19 |
| tmlind | need to go for some family time now, ttyl | 11:19 |
| freemangordon | ttyl | 11:19 |
| freemangordon | yay! I know why fps is too low - tmlind broke it :p | 11:20 |
| freemangordon | tmlind: fps ~9 | 11:27 |
| freemangordon | but, nothing moves, is that normal? | 11:28 |
| freemangordon | oh, ok, we hit 80 fps without 3-buffer | 11:33 |
| freemangordon | I think we shall disable it by default | 11:33 |
| freemangordon | at least on d4 it doesn;t seem we need 3-buffer | 11:47 |
| rafael2k | Wizzup: tks | 11:51 |
| rafael2k | Wizzup: ofono will be pretty easy | 11:51 |
| rafael2k | Wizzup: kernel wise, I want some help with git, and also some suggestion if I should just add the line in rules to install kernel, initrd and dts to /boot, or may be use a postinst scrit... | 11:52 |
| freemangordon | wow, firefox renders as mad! | 11:57 |
| freemangordon | hmm, why there is no sound? | 12:02 |
| rafael2k | Wizzup: dtbs are being installed in /usr/lib/linux-image-5.15.10/allwinner/ and I copied by hand to /boot/allwinner | 12:09 |
| rafael2k | Wizzup: kernel and initrd are installed, but they dont get copied to ddefault locations specified in boot.txt | 12:11 |
| Wizzup | freemangordon: what did you change? | 13:56 |
| Wizzup | rafael2k: ok | 13:56 |
| freemangordon | Wizzup: reverted 6dd1aad1d0c4716944098b7b0f2abdd3a26cc0be. | 15:18 |
| freemangordon | we must do that asap | 15:18 |
| Wizzup | freemangordon: in kernel? | 15:25 |
| Wizzup | freemangordon: asap as in. now? | 15:25 |
| freemangordon | yes, in kernel | 15:28 |
| freemangordon | asas as 'as soon as we can' | 15:28 |
| freemangordon | this brings massive improvement on d4 and n900 (not tested) | 15:29 |
| freemangordon | and will allow us to not use 3-buffer | 15:29 |
| freemangordon | which will reduce memory usage | 15:29 |
| freemangordon | this commit is the reason for 6ms delay in drmModePageFlip() | 15:31 |
| bencoh | don't we want to actually flush cache to memory during sync_buffer() ? | 15:56 |
| Wizzup | freemangordon: ok | 16:16 |
| Wizzup | freemangordon: ok so I'll make a trace of the fallback method, *without* EGL_BUFFER_PRESERVED set? | 16:39 |
| Wizzup | or with? | 16:39 |
| Wizzup | because I already have both | 16:39 |
| freemangordon | without | 17:07 |
| freemangordon | bencoh: I think this is done on the other side (GPU) | 17:09 |
| bencoh | hmm ... | 17:09 |
| freemangordon | IIUC | 17:10 |
| bencoh | so the gpu automatically forces a cache sync when pushing a frame to it? | 17:11 |
| freemangordon | I don;t really know when pvr driver flush caches | 17:12 |
| bencoh | ah | 17:12 |
| freemangordon | but it does | 17:12 |
| bencoh | so it happens on the cpu side | 17:12 |
| bencoh | wait, something's wrong ... if it already takes place, why would it take 6ms? | 17:12 |
| freemangordon | ah, yes, if you look at it like that | 17:12 |
| bencoh | I mean, why would it take another 6ms? | 17:12 |
| freemangordon | bencoh: this commit in omapdrm | 17:13 |
| freemangordon | not in pvr driver | 17:13 |
| bencoh | aren't both used in our case? | 17:14 |
| freemangordon | yes, they are | 17:14 |
| bencoh | I feel like I'm missing something | 17:14 |
| freemangordon | but omapdrm is not the one to flush anything, as it renders nothing | 17:14 |
| freemangordon | maybe I am missing something too | 17:14 |
| bencoh | sure, but then why would flushing writes to buffer take 6ms? | 17:15 |
| freemangordon | I am not sure what dma_sync_single_for_device does | 17:15 |
| bencoh | (unless that sync-to-device does more than what I think it should do on our platform, and for some reason takes a lot of time) | 17:16 |
| freemangordon | this is done for every page of our scanout buffer | 17:16 |
| freemangordon | and yes, maybe it does more | 17:17 |
| bencoh | I guess you checked reverting that commit doesn't result in (more) tearing? :) | 17:18 |
| freemangordon | I don;t see how this commit may affect tearing | 17:18 |
| freemangordon | and yes, I checked :) | 17:18 |
| freemangordon | it affects fps only | 17:19 |
| bencoh | well, gpu fetching a non-fully-synced buffer sounds like tearing expected to me, hence me asking :) | 17:19 |
| freemangordon | that's the point, gpu should fetch nothing here | 17:19 |
| freemangordon | gpu has already rendered and we prepare the buffer for displaying | 17:20 |
| bencoh | but it's supposed to fetch later on | 17:20 |
| bencoh | hmm | 17:20 |
| freemangordon | why is that? | 17:20 |
| bencoh | wait, I might be the one missing something | 17:20 |
| bencoh | (I probably am) | 17:20 |
| Wizzup | freemangordon: hm ok, but didn't enunez ask to have it on? | 17:21 |
| bencoh | is that an input buffer to gpu, or an output buffer from gpu? | 17:21 |
| Wizzup | maybe I will share both | 17:21 |
| freemangordon | Wizzup: ok | 17:21 |
| freemangordon | bencoh: this is a back buffer (so output) we are preparing to flip to be front | 17:21 |
| freemangordon | gpu == renderer, gpu != display controler | 17:22 |
| freemangordon | so, this buffer is output for gpu and input for display controller | 17:22 |
| freemangordon | and this is display controller (so CPU) doing sync | 17:23 |
| freemangordon | but there is nothing to be synced, IIUC, as CPU does not render | 17:23 |
| freemangordon | I think this commit mitigates the issues tmlind has with WL as it adds a delay, during which GPU finishes rendering | 17:24 |
| freemangordon | but not fully, as sometims GPU needs more than 6ms to render | 17:24 |
| freemangordon | does this sound sane? | 17:24 |
| freemangordon | it is absolutely possible that I am talking nonsense here, but the net effect is that reverting that results in stable 80fps being hit on h-d swiping without any visible rendering artifacts, besides the tearing and ants, but they are there with and without that commit | 17:27 |
| freemangordon | and also removing that commit results in drmModePageFlip() behave according to specs | 17:28 |
| freemangordon | (didn;t check xorg logs though) | 17:28 |
| Wizzup | freemangordon: ok so I will revert 6dd1aad1d0c4716944098b7b0f2abdd3a26cc0be for now in our -devel kernel | 17:51 |
| tmlind | ack, that patch is a hack | 17:54 |
| freemangordon | Wizzup: :mod: | 17:55 |
| freemangordon | :nod: | 17:55 |
| freemangordon | Wizzup: shall I disable 3-buffer to be enabled by default in omap code? | 18:13 |
| freemangordon | I think this is the sane | 18:14 |
| freemangordon | the other option is to disable it in config | 18:14 |
| Wizzup | I would disable by default if we have no use for it | 18:15 |
| freemangordon | ok, will disable and spin a new build | 18:15 |
| Wizzup | ty | 18:16 |
| Wizzup | maybe wait for kernel to complete | 18:16 |
| freemangordon | for the build? | 18:16 |
| freemangordon | sure | 18:16 |
| freemangordon | tmlind: can you recall any other hack patch that might be related to tearing? | 18:25 |
| freemangordon | hmm, I think I know what the possible fix for the corruption could be, in xorg | 18:28 |
| freemangordon | there is pvr driver call that flushes GPU buffers to memory | 18:29 |
| Wizzup | great @ corruption | 18:30 |
| freemangordon | well, I think this is of low prio | 18:32 |
| Wizzup | mhm | 18:32 |
| tmlind | freemangordon: well are you seeing the same issues on n900? if not, it's somehow related to the tiler possibly | 18:35 |
| freemangordon | never seen | 18:35 |
| freemangordon | IIRC | 18:35 |
| freemangordon | yeah, could be related to tiler | 18:35 |
| freemangordon | Wizzup: ever seens something like http://muru.com/m-l-ants.jpg on n900? | 18:36 |
| Wizzup | I do not recall at the moment, I only saw these problems on d4 windows | 18:37 |
| freemangordon | mhm | 18:37 |
| Wizzup | but my n900 doesn't run for very long on X atm | 18:37 |
| Wizzup | because of the alloc problems | 18:37 |
| freemangordon | yeah, but this happens on startup only | 18:37 |
| freemangordon | without running any application | 18:37 |
| Wizzup | never saw that on d4 either | 18:37 |
| Wizzup | I only see it in overview windows | 18:38 |
| freemangordon | I am seeing it occasionally | 18:38 |
| Wizzup | compose view | 18:38 |
| freemangordon | could be related to compositing being done on CPU | 18:38 |
| freemangordon | maybe those will disappear when I implement GPU compositing accel | 18:38 |
| Wizzup | how does that work? | 18:39 |
| freemangordon | HW accel compositing? | 18:39 |
| freemangordon | USSE code in pvr exa | 18:39 |
| freemangordon | binary shaders IIUC | 18:39 |
| Wizzup | ok | 18:42 |
| freemangordon | could be a bug i nclutter as well | 18:42 |
| freemangordon | so, tomorrow will start implementing non-CMA buffers support | 18:43 |
| freemangordon | hopefully shouldn;t take much time | 18:44 |
| tmlind | i wonder what would happen with omapdrm .cpu_cache_flags = OMAP_BO_UNCACHED for omap4? | 18:45 |
| tmlind | just as an experiment to see if the issues disappear | 18:45 |
| tmlind | instead of OMAP_BO_WC | 18:46 |
| freemangordon | try it, I am curious as well | 18:46 |
| tmlind | yeah might be worth trying | 18:46 |
| freemangordon | Wizzup: hmm, seems like kernel build is not progressing | 19:00 |
| freemangordon | oh, scratch that | 19:01 |
| freemangordon | I was looking at wrong xonsole outpit | 19:01 |
| freemangordon | *console | 19:01 |
| Wizzup | freemangordon: it easily takes 2-3h | 19:02 |
| Wizzup | still waiting on the solidrun server :( | 19:03 |
| freemangordon | depmod is being run, so it is @ end | 19:12 |
| Wizzup | great | 19:15 |
| freemangordon | hmm, now it doesn;t hit more than 56 fps with 2-buffer | 19:58 |
| freemangordon | weird | 19:58 |
| freemangordon | well, ok, will reenable it by default and will fix one more issue | 20:04 |
| Wizzup | great | 20:06 |
| freemangordon | tmlind: testing a fix for xorg error messages you were seeing, will let you know when it hits the repo | 20:11 |
| freemangordon | non-fullscreen, landscape, glmark2 Score: 56 | 20:18 |
| Wizzup | with h-d running? | 20:19 |
| freemangordon | yes | 20:19 |
| Wizzup | not bad :) | 20:20 |
| freemangordon | gears run with 80fps | 20:20 |
| freemangordon | this is vsynced | 20:20 |
| Wizzup | is that max screen refresh or something? | 20:20 |
| Wizzup | righgt | 20:20 |
| freemangordon | yes | 20:20 |
| freemangordon | even in tasknav small window ;) | 20:21 |
| Wizzup | :D | 20:21 |
| freemangordon | Wizzup: it is in the repo, enjoy and report issues :) | 20:48 |
| * Wizzup updates | 21:12 | |
| Wizzup | freemangordon: quite smooth indeed | 21:36 |
| Wizzup | I guess I should brush off the pinetab as well once we have the other gfx bug fixed | 22:27 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
