| Wizzup | ok, should be done | 14:11 |
|---|---|---|
| Wizzup | (isp switch) | 14:11 |
| freemangordon | tmlind: seems there is some coherency issue on mmaped BOs, no matter what I do, x11perf tests show terrible tearing. this happens on both d4 and n900 | 16:08 |
| freemangordon | I think what I am doing is correct: | 16:09 |
| freemangordon | 1. mmap | 16:10 |
| freemangordon | 2. ioctl DMA_BUF_IOCTL_SYNC/ DMA_BUF_SYNC_START | 16:10 |
| freemangordon | 3. read/write memory | 16:10 |
| freemangordon | 4. ioctl DMA_BUF_IOCTL_SYNC/ DMA_BUF_SYNC_END | 16:10 |
| freemangordon | 5. munmap | 16:10 |
| freemangordon | unless I am missing something, this should assure coherency between CPU and GPU | 16:11 |
| freemangordon | but it does not :( | 16:11 |
| freemangordon | at least this is my understanding | 16:20 |
| freemangordon | or, something else happens | 16:20 |
| tmlind | freemangordon: ok, care to upload some vid on the tearing? | 16:25 |
| freemangordon | the same happens with omap driver though | 16:25 |
| freemangordon | ok | 16:25 |
| freemangordon | tmlind: BTW, I modified omap_gem_is_cached_coherent to always return false and am testing with that on d4 | 16:26 |
| tmlind | hmm so with the reverted 33bc43 we at least need to check OMAP_BO_WC and OMAP_BO_UNCACHED masks separately as OMAP_BO_UNCACHED is 0 | 16:27 |
| freemangordon | bma_buf gems are allocated with OMAP_BO_WC flag IIUC | 16:28 |
| tmlind | yeah and on n900 it should be DMABUF | 16:29 |
| freemangordon | isn;t it dma_buf on d4 too? | 16:29 |
| freemangordon | despite the tiler? | 16:29 |
| freemangordon | sec, to provide link to the video | 16:30 |
| tmlind | no, it's shmem write-combine on omap4, OMAP_BO_MEM_DMA_API on n900 afaik | 16:30 |
| tmlind | weird if both n900 and d4 have the same tearing.. i confirmed that hdmi enabled does not remove the tearing i'm seeing with wlroots and termite | 16:30 |
| tmlind | so i thought this was tiler mapping related issue, but maybe what you see on n900 and d4 is something different then | 16:31 |
| freemangordon | I didn't try omap driver on n900 though, but the issue looks the same with glamor replacement driver | 16:33 |
| freemangordon | http://46.249.74.23/leste/20211025_001.mp4 | 16:33 |
| freemangordon | this | 16:33 |
| freemangordon | omap driver | 16:34 |
| freemangordon | with glamor replacement it is worse, because of the way higher performance | 16:34 |
| freemangordon | also, there is a black rectangle in the upper-right corner of the screen for -comppixwin500 (and some other tests) | 16:35 |
| freemangordon | lemme record another video | 16:35 |
| tmlind | that top left corner tearing on d4 looks somewhat similar to what i see with wlroots and termite | 16:37 |
| freemangordon | see http://46.249.74.23/leste/20211025_002.mp4 | 16:38 |
| freemangordon | maybe xorg related, lemme downgrade to stock | 16:39 |
| tmlind | heh have not seen that one before :) | 16:39 |
| tmlind | brb | 16:39 |
| uvos | freemangordon: honestly cant tell what http://46.249.74.23/leste/20211025_001.mp4 is supposed to show me | 16:39 |
| uvos | thats what x11perf -comppixwinXXX looks like on my dekstop too | 16:40 |
| freemangordon | with a black rectangle?!? | 16:40 |
| uvos | freemangordon: first video | 16:40 |
| freemangordon | -comppixwinXXX is the second video | 16:40 |
| uvos | whats the first one of? | 16:41 |
| freemangordon | -dots | 16:41 |
| uvos | yeah no black rectangles ofc | 16:41 |
| freemangordon | half of the dots are missing, in a random order :) | 16:41 |
| freemangordon | lets see with stock xorg | 16:42 |
| uvos | freemangordon: yeah | 16:42 |
| uvos | thats how dots works on destkop for me too | 16:42 |
| freemangordon | really? | 16:42 |
| uvos | uncomposed x is immidate mode.... | 16:42 |
| uvos | yeah | 16:42 |
| uvos | uncompsed x looks like that | 16:42 |
| uvos | *uncomposited? | 16:43 |
| freemangordon | not here | 16:43 |
| uvos | not sure how to say | 16:43 |
| uvos | freemangordon: using intel? | 16:43 |
| freemangordon | on my desktop I mean | 16:43 |
| uvos | intel has a hack in the ddx | 16:43 |
| uvos | what ddx | 16:43 |
| freemangordon | no, nvidia | 16:43 |
| uvos | some ddx use specal hacks to work around it | 16:44 |
| freemangordon | but, this is ubuntu 14 so everything is all | 16:44 |
| uvos | but regular x has no vsync and uses uncoordinated imiidate mode rendering | 16:44 |
| uvos | which is what modesetting dose | 16:44 |
| uvos | nvidia ddx also has special tear free option in ddx iirc | 16:44 |
| uvos | (from 10 years ago) | 16:44 |
| freemangordon | not really, IIUC, I think it renders to back buffer | 16:44 |
| uvos | yeah but when the draw calls are processed | 16:45 |
| uvos | core x ones that is | 16:45 |
| uvos | is uncoordinated with any refresh | 16:45 |
| uvos | so the application dose XPlotPixel or whatever | 16:45 |
| uvos | and that lands on this frame or the next or who knows | 16:45 |
| freemangordon | no, see backscrol about the sequance | 16:45 |
| freemangordon | DMA_BUF_SYNC_START/DMA_BUF_SYNC_END | 16:46 |
| uvos | no i mean in X api | 16:46 |
| freemangordon | maybe I don;t understand what you say | 16:46 |
| freemangordon | modesetting has only one buffer? | 16:47 |
| uvos | old school x draws directly into front buffer, so core x drawing calls dont coordinate with any refesh | 16:47 |
| freemangordon | IIUC, it has 2 buffers and draw calls are on back buffer | 16:47 |
| uvos | how modesting draws is immaterial | 16:47 |
| uvos | the core x drawing fuctions draw when the call comes in from xlib over the wire | 16:48 |
| uvos | that can be before or after a refresh | 16:48 |
| freemangordon | but ms presents on vsync | 16:49 |
| uvos | sure but what is it presenting | 16:49 |
| uvos | the back buffer | 16:49 |
| freemangordon | yes | 16:49 |
| uvos | the tearing is on the back buffer allready | 16:49 |
| freemangordon | but why it is there, given that all the drawing happened there? | 16:49 |
| uvos | because the x application that uses core x drawing calls | 16:50 |
| uvos | just draws at some point in time onto the back buffer | 16:50 |
| uvos | the backbuffer then flips while its sill drawing | 16:50 |
| uvos | this is the whole problem | 16:50 |
| uvos | why removing tearing entirely is almost impossible in x | 16:51 |
| uvos | and why wayland has this every frame is perfect thing | 16:51 |
| uvos | as a core concept | 16:51 |
| freemangordon | so, lemme see if I get this right: | 16:51 |
| freemangordon | 1. we have a back buffer not currently presented on the screen | 16:52 |
| freemangordon | 2: application issues "fill rectangle" call | 16:52 |
| freemangordon | 3. DDX starts drawing that rectangle on the back buffer | 16:53 |
| freemangordon | 4. somehow, in the middle of the drawing MS flips | 16:53 |
| freemangordon | uvos: is this what happens? | 16:53 |
| uvos | freemangordon: no | 16:53 |
| freemangordon | ok, call me stupid, but I don;t get it then :) | 16:54 |
| dreamer | freemangordon: you're stupid | 16:54 |
| freemangordon | thanks | 16:54 |
| dreamer | :) | 16:54 |
| dreamer | y/w | 16:54 |
| uvos | freemangordon: application wants to draw 3 lines | 16:55 |
| uvos | freemangordon: applicaiton calls XDrawLine, x draws line on back buffer, application calls XDrawLine, line finishes drawing, ms flips buffer, application calls XDrawLine | 16:55 |
| uvos | upps one frame with 2 lines | 16:55 |
| uvos | and one frame with 1 line | 16:55 |
| Wizzup | ttps://gitlab.freedesktop.org/vliaskov/xserver/-/commit/18be004ad18b8a33e5854c08ab2ea023f34890b6 | 16:56 |
| freemangordon | uvos: that's why I gave example with "fill rectangle" | 16:56 |
| uvos | freemangordon: so the not sure what happens with rectangle | 16:56 |
| uvos | some calls decompose into others | 16:56 |
| Wizzup | from https://gitlab.freedesktop.org/xorg/xserver/-/issues/244 | 16:56 |
| uvos | so 1 rectangle can have tearing | 16:56 |
| sunshavi | fmg: dreamer: :) | 16:56 |
| dreamer | sunshavi: fmg? | 16:57 |
| sunshavi | s/fmg/freemangordon/ | 16:57 |
| Wizzup | also https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/24#note_41468 | 16:57 |
| uvos | http://uvos.xyz/maserati/videos/recording.mp4 | 16:57 |
| freemangordon | uvos: they decompose, but the particular test case draws 4000 dots | 16:57 |
| uvos | modesetting on amdgpu | 16:57 |
| uvos | freemangordon: right so some frames have dots | 16:58 |
| uvos | some dont | 16:58 |
| uvos | some have some | 16:58 |
| freemangordon | but they are drawn in a single pass, I can provide call stack | 16:58 |
| Wizzup | (what I linked adds tearfree to modesetting, but not for rotated display and also is not merged in xserver) | 16:58 |
| freemangordon | uvos: video seems to be broken | 16:59 |
| uvos | use mpv | 16:59 |
| freemangordon | 45k | 16:59 |
| Wizzup | it works for me | 16:59 |
| uvos | thats correct | 16:59 |
| freemangordon | ok | 16:59 |
| uvos | ff dosent like it on my end ether | 16:59 |
| freemangordon | omg | 17:00 |
| freemangordon | this is awful | 17:00 |
| uvos | well it goes away if you enable compositing | 17:01 |
| uvos | because then every application has its own back buffer | 17:01 |
| uvos | and draw calls just accumulated | 17:01 |
| uvos | but this is just how x is desinged | 17:02 |
| uvos | its also largly irrelivant because modern applications ussualy just flip the whole window as one pixmap | 17:03 |
| freemangordon | stock xorg + omap driver draws nothing :D | 17:06 |
| Wizzup | right, x11perf might not be the best test case for tearing | 17:08 |
| uvos | accualy what is concerning about the dots video on d4 | 17:08 |
| uvos | is that is changes so slowly | 17:09 |
| freemangordon | this is omp driver | 17:09 |
| uvos | ok | 17:09 |
| freemangordon | *omap | 17:09 |
| freemangordon | with glmaor replacement is it waaaay faster | 17:09 |
| freemangordon | but still, we should not have that black rectangle | 17:09 |
| uvos | right | 17:09 |
| uvos | there is something wrong there for sure | 17:10 |
| uvos | maybe same thing as missing tiles on ddk1.9 | 17:10 |
| uvos | but idk | 17:10 |
| uvos | just spculating | 17:10 |
| uvos | *speculating | 17:10 |
| freemangordon | no tiles on n900 | 17:11 |
| uvos | no tiler on n900 | 17:11 |
| uvos | sgx is sill a tile based renderer | 17:11 |
| uvos | but that dosen pass though gpu dose it | 17:11 |
| uvos | hmm | 17:11 |
| freemangordon | and there the black rectangle is on lower-left corner | 17:11 |
| freemangordon | it doesn't | 17:11 |
| uvos | no idea | 17:11 |
| uvos | sorry | 17:11 |
| freemangordon | that why I think there is something wrong with either cache or mmap | 17:11 |
| Wizzup | is this also visible outside of x11perf? | 17:13 |
| uvos | it might make sense to try your dri3 non glamor modesetting on some very stable drm driver | 17:13 |
| uvos | like amdgpu or intel | 17:13 |
| uvos | just to ensure that its not that | 17:13 |
| freemangordon | uvos: hmm, lemme try MS without glamor | 17:14 |
| uvos | yeah just NoAccel glamor might be a good test too | 17:14 |
| uvos | *modesetting | 17:14 |
| freemangordon | mhm | 17:15 |
| bencoh | considering how people complain about tearing issues on various pc setups, it might be just that, yeah | 17:16 |
| freemangordon | the same happens on NoAccel glamor | 17:17 |
| uvos | *modesetting | 17:17 |
| uvos | :P | 17:17 |
| freemangordon | yea | 17:18 |
| freemangordon | but it happens with omap too | 17:18 |
| uvos | so some buffer sync thing between cpu and dss or something | 17:18 |
| uvos | like that | 17:18 |
| freemangordon | so I would say it is a kernel thing | 17:18 |
| uvos | yeah | 17:18 |
| uvos | tmlind is your fault :P | 17:18 |
| freemangordon | heh, upstream xorg has font sizes broken :D | 17:19 |
| uvos | freemangordon: might make sense to try omapdrm with NoAccel modesetting on a mainline kernel with no sgx patches | 17:20 |
| uvos | and see if it sill happens & report a bug on linux | 17:20 |
| uvos | ml | 17:20 |
| uvos | i can do so if you like | 17:21 |
| freemangordon | yeah, maybe | 17:21 |
| freemangordon | uvos: if you can | 17:21 |
| uvos | ok | 17:21 |
| freemangordon | that'd help a lot | 17:21 |
| freemangordon | but I think I didn;t see the same issue with ny test applications | 17:22 |
| uvos | do any of your test applicaitons | 17:22 |
| uvos | oh ok | 17:22 |
| uvos | nvm then | 17:22 |
| uvos | freemangordon: wrt font sizes | 17:26 |
| uvos | freemangordon: xorg is probubly just reporting correct dpi | 17:26 |
| uvos | freemangordon: i noticed that the display size porparty in x is wrong on current leste setup | 17:26 |
| uvos | freemangordon: setting it to be correct breaks gtk2 fonts | 17:27 |
| uvos | amoung others | 17:27 |
| uvos | so check that | 17:27 |
| freemangordon | ah, I see | 17:28 |
| uvos | xdpyinfo | grep resolution | 17:30 |
| tmlind | freemangordon: here are hopefully better version of two patches to replace the reverted 33bc43 commit: muru.com/linux/d4/omapdrm-flush/ | 17:30 |
| tmlind | seems to fix my termite on wlroots issue better than 33bc43 based on quick testing | 17:31 |
| freemangordon | tmlind: shall I test? | 17:31 |
| tmlind | heh well based on about 1 minute of testing :) | 17:31 |
| tmlind | yeah please do, hopefully it won't hang n900 any longer | 17:32 |
| freemangordon | ok, will try in a couple of minutes | 17:32 |
| tmlind | well if n900 hangs then would be good to know which of the two patches causes it | 17:32 |
| tmlind | so far no tearing here :) | 17:34 |
| tmlind | oh also the weirdness around the sun in stellarium seems to be gone now | 17:36 |
| tmlind | ok saw some tearing on the hdmi panel, so there's at least some issues remaining | 17:39 |
| tmlind | bbl | 17:40 |
| tmlind | uvos: maybe also take a look and see if those help with the tearing you're seeing? | 18:01 |
| freemangordon | uvos: resolution: 264x265 dots per inch | 18:09 |
| tmlind | hmm running glmark2-es2-wayland nowadays produces a sgx lockup, i guess that must be the mesa vs blobs issue | 18:11 |
| freemangordon | mhm | 18:11 |
| freemangordon | tmlind: with both patches applied n900 seems to boot fine | 18:12 |
| freemangordon | glmark runs fine too, so it seems nothing got broken :) | 18:16 |
| tmlind | ok great | 18:18 |
| tmlind | did these help with your tearing issues at all? | 18:19 |
| freemangordon | lemme check | 18:19 |
| freemangordon | no | 18:26 |
| freemangordon | this black square is still there on both devices | 18:26 |
| tmlind | ok | 18:27 |
| tmlind | seems like a separate issue so i'll push out these two fixes if no comments | 18:28 |
| freemangordon | yeah | 18:32 |
| tmlind | ok pushed out updated droid4-pending-pvr-omapdrm-v5.15 | 18:37 |
| tmlind | looks like rm /dev/dri/renderD128; ln -s /dev/dri/card0 /dev/dri/renderD128 can be used to work around the omapdrm/pvr render node limitations | 18:46 |
| tmlind | we should somehow fix omapdrm to allow the standard calls on /dev/dri/renderD128 also with only allocation happening on /dev/dri/card0 | 18:47 |
| tmlind | i guess the /dev/dri/renderD128 is created automatically by the kernel based on some flag? | 18:50 |
| uvos | freemangordon: yeah thats correct | 18:50 |
| uvos | freemangordon: so upstream fixed it | 18:50 |
| uvos | on current leste its resolution: 96x96 | 18:51 |
| tmlind | ah DRIVER_RENDER i guess creates /dev/dri/renderD128 | 18:51 |
| uvos | annoingly nokia just decided its ok to just scall up the fonts | 18:51 |
| uvos | and leave it set wrong at 96x96 (before kms xorg had no way to know the display size without being told in xorg.conf) | 18:52 |
| uvos | this is also why scaling in qt5 and gtk3 is broken in leste | 18:52 |
| uvos | well part of the reason anyways | 18:52 |
| uvos | even if xorg reports correctly scaling is still pretty broken | 18:53 |
| uvos | because the toolkits (esp gtk3) dont do this well | 18:53 |
| uvos | (and gtk2 dosent scalle at all besides fonts) | 18:53 |
| uvos | and everyone blames "X" for scaling being broken on linux... but im getting into a rant here again | 18:54 |
| uvos | and now in wayland mutter they report lie to applications to about the window size and then do bliniear scaling on gpu to make things the right size.. grrr | 18:56 |
| tmlind | uhh i guess nothing wrong with omapdrm for /dev/dri/renderD128, we somehow need to translate /dev/dri/renderD128 to /dev/dri/card0 for the pvr mesa or blobs :( | 19:06 |
| * tmlind goes to build mesa again on d4 | 19:19 | |
| freemangordon | tmlind: doess dss support HW rotation? | 19:38 |
| freemangordon | I remember there was something called vrfb | 19:38 |
| tmlind | i think rotation is there only for the tiler and there was something in omap1 that used the sdma | 19:44 |
| freemangordon | do you know if dss driver supports it? | 19:44 |
| tmlind | don't think so, i think only tiler is supported | 19:44 |
| freemangordon | :( | 19:45 |
| uvos | portrait n900 will be hella slow with roation working in sw no? | 19:45 |
| tmlind | not sure if later omaps even have the sdma support for rotation any longer since omap1 | 19:45 |
| freemangordon | uvos: yeah | 19:45 |
| uvos | :( | 19:45 |
| uvos | well pvr2d could do it | 19:45 |
| freemangordon | but, fremantle somehow manages to do it | 19:45 |
| tmlind | hmm so what was nokia using on fremantle then? | 19:45 |
| uvos | pvr2d proubly can rotate the surface on pvr or? | 19:45 |
| freemangordon | don;t know | 19:45 |
| freemangordon | but, I think omapfb was able to rotate | 19:46 |
| freemangordon | so I guess it was somthing in the kernal | 19:46 |
| tmlind | oh there is some roation support in omapdrm for framebuffer with the rotate command line, not sure if it's all software without tiler | 19:46 |
| * tmlind has 472/1150 of mesa compiled.. | 19:55 | |
| uvos | weeee | 19:56 |
| uvos | we need a big arm server or something | 19:56 |
| uvos | (yeah i know expensive) | 19:56 |
| Wizzup | I had that, but it broke down | 20:05 |
| uvos | yeah i know a amd one | 20:07 |
| freemangordon | hmm, why modesetting does not rotate through GL? | 20:18 |
| uvos | it dosent with the glamor path? | 20:19 |
| uvos | in the non glamor path should be obvious why.. | 20:19 |
| freemangordon | it doesn;t | 20:19 |
| uvos | i gues that they never needed it | 20:19 |
| freemangordon | it seems it does SW rotation even with glamor | 20:19 |
| uvos | since desktop gpus can rotate in drm | 20:20 |
| freemangordon | yeah | 20:20 |
| freemangordon | I am starting to wonder if it makes sense to continue waste time on that | 20:20 |
| freemangordon | that == modesetting | 20:20 |
| uvos | i dont see why your wasting time? | 20:21 |
| freemangordon | because it is broken all over the place | 20:21 |
| uvos | the plan is to create a acell plugin that uses pvr2d right? | 20:21 |
| uvos | ok | 20:21 |
| freemangordon | yes, but we have nasty bug in modesetting | 20:21 |
| freemangordon | *bugs | 20:21 |
| uvos | what is it? | 20:21 |
| uvos | maybe list the ones you found | 20:22 |
| freemangordon | let me record a video, you might have an idea what it might be | 20:22 |
| uvos | i can try repoducing them later | 20:22 |
| uvos | on amdgpu or plain omapdrm w/o sgx | 20:22 |
| freemangordon | BTW h-d scrolls with 58-59 fps | 20:22 |
| freemangordon | on n900 | 20:22 |
| uvos | neat | 20:22 |
| freemangordon | yeah | 20:22 |
| uvos | what about gtk2 scrolling lists and sutch? | 20:23 |
| uvos | (ie non gl accelerated rendering) | 20:23 |
| freemangordon | but, there is some 'frames repetition", you'll see in the video | 20:23 |
| uvos | ok | 20:23 |
| freemangordon | I want ^^^ fixed first | 20:23 |
| uvos | any you have evidence that this is ms fault? | 20:23 |
| uvos | or why are you unhappy with it | 20:23 |
| freemangordon | it happens with glamor as well | 20:23 |
| uvos | sure but that dosent mean its not omapdrms fault... | 20:24 |
| freemangordon | 'real' galmor | 20:24 |
| freemangordon | wait for a video :) | 20:24 |
| uvos | ok ok | 20:24 |
| uvos | also any bugs you find in ms upstream might fix | 20:24 |
| uvos | since ms is also the base of xwayland.... | 20:24 |
| uvos | ...and wildy used still on bare metal x too | 20:25 |
| freemangordon | http://46.249.74.23/leste/20211025_003.mp4 | 20:29 |
| freemangordon | I have the feeling that wrong pixmaps is being drawn to | 20:30 |
| uvos | freemangordon: well i dont see anything that couldent be cause by the kernel messing up buffer allocation or setting up the mmu for dss usage | 20:31 |
| uvos | but im prediposed to think modesetting is not buggy beacuse i have used it for like 10+ years on various devices.... | 20:32 |
| uvos | the fact that ddk1.9 with vidoe-omap allso has kinda simmular looking artifacts | 20:32 |
| uvos | altho they are less bad | 20:32 |
| uvos | also makes me suspect the kernel... | 20:33 |
| freemangordon | most-probably because it is slower :) | 20:33 |
| freemangordon | yeah, could be | 20:33 |
| freemangordon | but have no idea how to debug | 20:33 |
| uvos | well first i would try mainline kernel no patches with mainline modesetting no patches on a d4 and see if it artifacts | 20:34 |
| freemangordon | either the driver draws to wrong framebuffer or MS asks kernel to flip to wrong framebuffer or kernel displays wrong framebuffer :) | 20:35 |
| uvos | i will do this soon i promise | 20:35 |
| uvos | tomorrow | 20:35 |
| uvos | and then ask on the kernel m-l | 20:35 |
| uvos | and maybe report a bug against xorg | 20:35 |
| uvos | if so | 20:35 |
| freemangordon | this happens with hildon-desktop only | 20:35 |
| freemangordon | hmm, I will start it with SW rendering, lets see | 20:35 |
| uvos | oh so the problem with black sections in core x rendering is gohne | 20:36 |
| uvos | sorry if i missed it in backscroll | 20:36 |
| tmlind | yeah maybe the two patches i pushed today fixed the black sections that don't get refreshed | 20:37 |
| freemangordon | no, it isn't | 20:37 |
| tmlind | you still see some black squares that don't get refreshed? | 20:38 |
| freemangordon | only with x11perf | 20:38 |
| freemangordon | but I guess this is to be ignored | 20:39 |
| uvos | no | 20:39 |
| uvos | freemangordon: try something else that renders in 2 in a loop | 20:39 |
| uvos | like resizing xeyes or something | 20:39 |
| freemangordon | hmm, it seems like ms without glamor works fine | 20:40 |
| uvos | also sutch artifacts i also sometimes encounter on wayland (sway, weston) too | 20:40 |
| uvos | again makeing me suspect kernel... | 20:40 |
| freemangordon | I see | 20:40 |
| uvos | like bits black bits of missing frame mostly at the top right | 20:41 |
| uvos | can hapen in qt applications on sway | 20:41 |
| freemangordon | by kernel you mean omapdrm I guess | 20:41 |
| uvos | yeah | 20:41 |
| freemangordon | tmlind: can we have tomi on the channel somehow? | 20:42 |
| freemangordon | :) | 20:42 |
| freemangordon | oh, so what we have working now on n900 is omapfd, right? | 20:43 |
| freemangordon | *omapfb | 20:43 |
| uvos | yes | 20:43 |
| uvos | on d4 its omapdrm | 20:43 |
| uvos | and its artifacting | 20:43 |
| uvos | again the common bit is omapdrm | 20:43 |
| freemangordon | yeah | 20:43 |
| freemangordon | mhm | 20:43 |
| freemangordon | I wonder how to debug that | 20:44 |
| uvos | no idea | 20:44 |
| Wizzup | if you take a screenshot using X, I guess the artifacts are not there? | 20:44 |
| uvos | totaly over my head | 20:44 |
| freemangordon | Wizzup: did you watch the video? | 20:44 |
| Wizzup | yes | 20:44 |
| uvos | freemangordon: yeah but if scrot also shows the problem is interesing question | 20:44 |
| uvos | on ddk1.9 scrot is fine | 20:44 |
| freemangordon | I wouldn;t say these are artifacts, rather wrong framebuffers | 20:45 |
| freemangordon | what is scrot | 20:45 |
| uvos | x11 screenshot tool | 20:45 |
| Wizzup | freemangordon: yeah, I was wondering around the xterm | 20:45 |
| freemangordon | Wizzup: it is like it renders every line to a different framebuffer/pixmap | 20:46 |
| tmlind | i uploaded the omapdrm flush debug patch i used too to muru.com/linux/d4/omapdrm-flush/ | 20:46 |
| freemangordon | hmm, maybe I shall trace what FB memory it renders to | 20:48 |
| tmlind | i just looked at the flushing path taken after starting sway and termite and pressing keys, maybe there are other paths that are unhandled too | 20:50 |
| tmlind | however, afaik n900 is not using this code path at all since it's not shmem write-combined | 20:51 |
| * tmlind has 1096/1150 of mesa built now.. | 20:51 | |
| freemangordon | but it is WC, no? | 20:51 |
| tmlind | hmm actually yeah, but not shmem mapped so should not need anything there | 20:52 |
| freemangordon | hmm, whith h-d running I see no black box | 20:54 |
| uvos | freemangordon: well the artifacting is highly timeing dependant | 20:57 |
| uvos | freemangordon: on ddk1.9 | 20:57 |
| uvos | freemangordon: you can mess with the sgx clocks and make it better or way worse | 20:57 |
| uvos | freemangordon: generaly longer frame rendering times makes the problem explode | 20:57 |
| uvos | so the missing boxes might just be a timeing fluke | 20:58 |
| uvos | (if the ddk1.9 problem and yours is related in the first place - but it suspect it is) | 20:58 |
| * tmlind has mesa finally built | 21:12 | |
| tmlind | looks like the render node checks are in the blobs | 21:15 |
| freemangordon | any idea what "omapdrm omapdrm.0: atomic complete timeout (pipe 0)!" is? | 22:18 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!