| Wizzup | freemangordon: when you get to it, conversations is also a good test case for some corruption | 00:42 |
|---|---|---|
| Wizzup | there are two bars on the side of the screen that weirdly become 'transparent' or something where the previous (stacked) window becomes visible | 00:43 |
| Wizzup | I would suggest to just copy your n900 rtcom el db and try it | 00:43 |
| Wizzup | this is also only on the pin64 | 00:44 |
| mighty17[m] | does video accl work out of box for omap4? | 08:08 |
| mighty17[m] | (its a mess with ducati :P) | 08:08 |
| freemangordon1 | Wizzup: about llvmpip capture, who is rendering using llvmpipe? | 09:07 |
| freemangordon1 | X or hildon-desktop | 09:08 |
| freemangordon1 | ah, hildon-desktop | 09:08 |
| freemangordon1 | Wizzup: what I see in those traces is that 2D rendering is incomplete by the time application texture is rendered to back buffer | 09:09 |
| freemangordon1 | what's with my nick?!? | 09:09 |
| freemangordon | Wizzup: so, could you replace glFlush calls in glamor with glFinish and retry? or, use llvmpipe in glamor. | 09:10 |
| freemangordon | hmm, hmm, no, looks something is wrong with scissor | 09:18 |
| Wizzup | hi | 09:59 |
| Wizzup | mighty17[m]: out of the box on what? | 09:59 |
| freemangordon | Wizzup: hi | 09:59 |
| Wizzup | hi | 09:59 |
| freemangordon | Wizzup: I am looking at llvmpipe capture | 09:59 |
| mighty17[m] | Wizzup: well, espresso (the tab) with omap2plus_defconfig ig | 10:00 |
| Wizzup | freemangordon: right | 10:01 |
| Wizzup | mighty17[m]: well it's a complicated question since it can refer to many things, iirc you need dts setup, clocks correct, userspace and X set up, etc etc | 10:01 |
| Wizzup | mighty17[m]: but you've been working on this so that further makes me not understand :D | 10:01 |
| mighty17[m] | Wizzup: i just mean video playback (ie decoding?) | 10:03 |
| freemangordon | Wizzup: so, if you look at frame 22 | 10:05 |
| freemangordon | Wizzup: do you have 5 minutes now? | 10:06 |
| freemangordon | we can postpone that for later on | 10:06 |
| Wizzup | freemangordon: I have time now | 10:07 |
| Wizzup | you want me to look using qapitrace that is llvmbacked right | 10:08 |
| freemangordon | yes | 10:08 |
| freemangordon | hmm | 10:08 |
| freemangordon | wait, I think this will take as more tim | 10:08 |
| freemangordon | *time | 10:08 |
| freemangordon | 5 minutes will not be enough | 10:09 |
| freemangordon | I have really 5 minutes now and have to go shopping | 10:09 |
| freemangordon | ok, we made a deal with GF, she will go alone :) | 10:10 |
| Wizzup | don't mean to disturn :) | 10:10 |
| freemangordon | no, it is ok | 10:10 |
| Wizzup | ok | 10:10 |
| Wizzup | mighty17[m]: no, we haven't focussed on that at all | 10:10 |
| freemangordon | so, please open llvmpipe trace in qapitrace | 10:11 |
| Wizzup | yes, but should my qapitrace be llvmpipe backed as well? | 10:11 |
| freemangordon | doesn;t matter | 10:11 |
| Wizzup | ok | 10:11 |
| freemangordon | I think | 10:11 |
| Wizzup | it renders differently with amdgpu than with llvmpipe | 10:11 |
| Wizzup | I will use llvmpipe with it | 10:12 |
| freemangordon | with llvmpipe qapitrace it renders fine, right? | 10:12 |
| Wizzup | yes | 10:12 |
| freemangordon | no, we want the proken rendering | 10:12 |
| Wizzup | ok | 10:12 |
| freemangordon | *broken | 10:12 |
| Wizzup | frame different already has a different result it looks likle | 10:12 |
| freemangordon | hmm? | 10:13 |
| freemangordon | can't parse | 10:13 |
| Wizzup | I am looking at frame 20 :-) | 10:13 |
| Wizzup | qapitrace renders it differently with different renderers | 10:13 |
| Wizzup | is all I am saying | 10:13 |
| freemangordon | yeah, I think frame 19 is the first broken one | 10:13 |
| mighty17[m] | Wizzup: oh alrighty! | 10:13 |
| Wizzup | freemangordon: ok, do you want me to just type what I see or wait for specific requests | 10:14 |
| freemangordon | Wizzup: my idea is to try to understand where data uploaded with glTexSubImage2D disappears | 10:17 |
| freemangordon | I mean - to try to analyze frames 19- together in an attempt to understand WTF is going on | 10:18 |
| freemangordon | too bad we can't see the contents of texture 106 | 10:19 |
| freemangordon | oh, actually we can | 10:19 |
| freemangordon | look at call 2205 | 10:19 |
| freemangordon | you can export the data from there and open it with gimp | 10:20 |
| Wizzup | ok | 10:21 |
| Wizzup | so the glTexSubImage2D call | 10:22 |
| Wizzup | you want me to click export and look at the data | 10:22 |
| Wizzup | most of the data is nan | 10:22 |
| freemangordon | this is unsigned byte, not float ;) | 10:23 |
| Wizzup | oh | 10:23 |
| freemangordon | this is RGB data | 10:23 |
| freemangordon | so, you can export and open with gimp | 10:23 |
| freemangordon | as 'raw' image | 10:23 |
| Wizzup | ok | 10:23 |
| freemangordon | glTexSubImage2D call gives you the dimensions | 10:24 |
| Wizzup | ok | 10:25 |
| Wizzup | I have it open | 10:25 |
| Wizzup | it is osso-xterm contents | 10:25 |
| freemangordon | mhm | 10:25 |
| freemangordon | and looks correct | 10:26 |
| Wizzup | https://wizzup.org/maemo-summoner-hildon-desktop-llvmpipe.trace_call_2205_buffer.png | 10:26 |
| freemangordon | now, what I think we should look for, is why this texture (106) contents is not correctly updated | 10:26 |
| freemangordon | I would say glTexSubImage2D is broken | 10:27 |
| Wizzup | when can I see this texture? | 10:28 |
| freemangordon | unfortunatel apitrace is not smart enough it seems | 10:28 |
| freemangordon | to track textures | 10:28 |
| freemangordon | you can;t see it | 10:29 |
| freemangordon | but, we can decide what it's contents is based on glTexSubImage2D calls | 10:29 |
| freemangordon | Wizzup: so, texture 106 is osso-xterm texture and I see no FBO attached to it | 10:31 |
| freemangordon | so, the only way this texture can be changed is by glTexSubImage2D, IIUC | 10:31 |
| freemangordon | to me, at the end of frame 19, both framebuffer and texture 106 are correctly rendered, agree? | 10:32 |
| Wizzup | let me check | 10:32 |
| Wizzup | no | 10:33 |
| Wizzup | the framebuffer is not correct, or rather, it is different between llvmpipe and amdgpu | 10:33 |
| Wizzup | amdpgpu renders some random artifacts of hildon-home | 10:33 |
| Wizzup | on framebuffer | 10:33 |
| Wizzup | on llvmpipe it is the terminal | 10:33 |
| freemangordon | NV here renders it fine | 10:33 |
| freemangordon | this is call 2329 | 10:34 |
| Wizzup | I was looking at 2330 | 10:34 |
| Wizzup | 2329 is ok | 10:34 |
| rafael2k | morning - the 5.15 for pp is here: https://github.com/rafael2k/sunxi64-linux/tree/mobian-5.15 - I'm trying to import it to my pine64-linux under name maemo-kernel-5.15 | 10:34 |
| freemangordon | no, this is the 'new' buffer what you see there | 10:34 |
| Wizzup | freemangordon: ok | 10:35 |
| freemangordon | like, framebuffer after the swap | 10:35 |
| Wizzup | rafael2k: did you try my git instructions? | 10:35 |
| freemangordon | ofc it is not ok | 10:35 |
| rafael2k | Wizzup: just woke up, not yet - still downloading the repo from github | 10:35 |
| freemangordon | so, now (2330) we have good front buffer and texture 106 with correct contents | 10:35 |
| Wizzup | freemangordon: presumably, I can't check out the texture atm, but if it was used to render the result then yes | 10:36 |
| Wizzup | freemangordon: as in I don't see texture 106 anymore but I guess it was freed or something | 10:36 |
| freemangordon | it was used in call 2236 | 10:37 |
| freemangordon | no, 106 is not deleted | 10:37 |
| freemangordon | it is just that apitrace does not show it for us | 10:37 |
| Wizzup | ok, it is also not in the gl state | 10:37 |
| freemangordon | yes, because it is not current | 10:37 |
| Wizzup | ok | 10:37 |
| freemangordon | but I dont see it deleted | 10:37 |
| Wizzup | ok | 10:37 |
| freemangordon | sec, need some coffee | 10:38 |
| Wizzup | same.. | 10:38 |
| Wizzup | there's this car alarm that has been beeping every 5 seconds for the whole night | 10:38 |
| freemangordon | :( | 10:38 |
| freemangordon | ok, so at the very beginning of frame 20 we have another glTexSubImage2D upload to texture 106 | 10:40 |
| freemangordon | call 2333 that is | 10:41 |
| rafael2k | Wizzup: did not work the git command, I get fatal: ../sunxi64-linux/.git: '../sunxi64-linux/.git' is outside repository at '/home/rafael2k/programs/pinephone/pine64-kernel' | 10:43 |
| rafael2k | git add remote mobian-5.15 ../sunxi64-linux/.git | 10:43 |
| Wizzup | rafael2k: please search around on how to do it, it can be done | 10:44 |
| Wizzup | freemangordon: let me look | 10:44 |
| freemangordon | which uploads a 720x29 black rectangle at 0,182 | 10:44 |
| Wizzup | hm | 10:45 |
| Wizzup | yeah, mostly black rectangle | 10:45 |
| Wizzup | it also contains white | 10:45 |
| freemangordon | not here | 10:46 |
| Wizzup | are you looking at the frame data? | 10:46 |
| Wizzup | vertex ata* | 10:46 |
| freemangordon | no, I am looking at the exported data | 10:47 |
| Wizzup | rafael2k: I can help later but not atm | 10:47 |
| freemangordon | yes, vertex data | 10:47 |
| Wizzup | freemangordon: so vertex data starts with this for me: 0) [255, 255, 255, 255] | 10:47 |
| freemangordon | yeah, correct | 10:47 |
| Wizzup | that is white, not black | 10:48 |
| Wizzup | but ok | 10:48 |
| freemangordon | right | 10:48 |
| Wizzup | it doesn't really matter I think | 10:48 |
| freemangordon | mhm | 10:48 |
| rafael2k | Wizzup: no rush with this | 10:48 |
| freemangordon | Wizzup: so in call 2356 this is rendered to framebuffer | 10:50 |
| Wizzup | rafael2k: https://stackoverflow.com/questions/10603671/how-to-add-a-local-repo-and-treat-it-as-a-remote-repo | 10:50 |
| Wizzup | rafael2k: you just need absolute path | 10:50 |
| rafael2k | Wizzup: tks | 10:51 |
| Wizzup | freemangordon: looking at the code it seems to do glTexSubImage2D, some scissor stuff, and then calls glBindTexture on 106 again, should it not do anything else? | 10:52 |
| Wizzup | can it just call bind again? | 10:53 |
| freemangordon | yes | 10:53 |
| freemangordon | this is fibe | 10:53 |
| freemangordon | *fine | 10:53 |
| Wizzup | I guess the glEnable for gl_scissor_text makes it draw on the texture? | 10:53 |
| freemangordon | as I said, texture is not deleted, so it is a valid object | 10:53 |
| freemangordon | no | 10:53 |
| freemangordon | scissor puts 'boundaries' on the target FBO and nothing gets rendered aoutside those | 10:54 |
| freemangordon | *outside | 10:54 |
| Wizzup | ok | 10:54 |
| freemangordon | Wizzup: could you compare the visual contents of back buffer at start of frame 20 between amd and llvmpipe? | 10:56 |
| Wizzup | at the glPixelStore? | 10:57 |
| Wizzup | so 2331? | 10:57 |
| freemangordon | yes | 10:57 |
| freemangordon | I think the diff comes from frame 18, but still | 10:57 |
| Wizzup | totally different | 10:57 |
| Wizzup | it's just like after the swap call | 10:58 |
| freemangordon | yes, exactly | 10:58 |
| freemangordon | but, I see 720x720 osso-xterm | 10:58 |
| freemangordon | not 720x1384 xterm | 10:58 |
| freemangordon | and clutter seems to only draw the difference | 10:58 |
| Wizzup | GL_BACK for me is 800x1440 | 10:59 |
| Wizzup | are you talking about something else? | 10:59 |
| freemangordon | yes, but the osso-xterm there is 720x720 | 10:59 |
| freemangordon | or somesuch | 10:59 |
| Wizzup | oh, right | 10:59 |
| Wizzup | the initial height | 10:59 |
| rafael2k | Wizzup: better I leave this git messing up with someone who knows what is doing - I'll focus on the kernel setup / tesing | 10:59 |
| freemangordon | Wizzup: look at call 2082 | 11:00 |
| Wizzup | freemangordon: ok | 11:01 |
| Wizzup | freemangordon: yeah so GL_BACK is still 800x1440 but the terminal isn't that size yet | 11:01 |
| freemangordon | right | 11:01 |
| freemangordon | GL_BACK is the size of the screen | 11:02 |
| Wizzup | yeah | 11:02 |
| freemangordon | not really important | 11:02 |
| Wizzup | ok | 11:02 |
| freemangordon | but, what I think happens is that we have difference in osso-xterm images between 2 back buffers | 11:03 |
| freemangordon | now, the question is why this does not bother llvmpipe rendering | 11:04 |
| Wizzup | or nvidia | 11:05 |
| freemangordon | on nvidia rendering is broken too | 11:05 |
| Wizzup | not for meridion | 11:05 |
| Wizzup | he also tested it | 11:05 |
| Wizzup | see https://wizzup.org/dirlist/maemo-leste/lima/dump-images/ | 11:06 |
| Wizzup | but could perhaps be coincidence in buffer mgmt or something maybe | 11:06 |
| Wizzup | freemangordon: when you write 'we have a difference in osso-xterm images between 2 back buffers', what do you mean exactly | 11:08 |
| Wizzup | I guess you're suggesting that mesa considers the back buffers fair game to change them in the meantime and we expect it not to changfe | 11:09 |
| Wizzup | to drawing only the difference then gets broken? | 11:09 |
| Wizzup | s/to/so/ | 11:09 |
| freemangordon | Wizzup: rather - "clutter expects back buffers to be equal but they are not because application window has not been resized when first texture upload happened" | 11:10 |
| freemangordon | clutter expects equal initial condition | 11:11 |
| freemangordon | *conditions | 11:11 |
| freemangordon | I guess this could happen because pp is very fast | 11:11 |
| Wizzup | hm | 11:12 |
| freemangordon | Wizzup: can we have some online mtg, I cannot run llvmpipe retrace here | 11:13 |
| freemangordon | I would like to see you screen share of frame 18 | 11:13 |
| Wizzup | sure | 11:13 |
| Wizzup | I'll send you a msg | 11:13 |
| freemangordon | no audio/vide, just screen share | 11:14 |
| Wizzup | yeah ok | 11:14 |
| freemangordon | I have no camera/mic here attached anyways :) | 11:14 |
| freemangordon | yes :) | 11:16 |
| Wizzup | ok | 11:16 |
| freemangordon | so, it is the same on llvmpipe | 11:16 |
| Wizzup | the apitrace on the right is llvmpipe | 11:17 |
| Wizzup | (rendered) | 11:17 |
| freemangordon | yeah | 11:17 |
| Wizzup | ok | 11:17 |
| freemangordon | I can't see the framebuffer | 11:18 |
| freemangordon | thanks :) | 11:18 |
| freemangordon | so, those are same, no? | 11:18 |
| Wizzup | yeah | 11:18 |
| freemangordon | ok, can we see what happens in frame 20? | 11:19 |
| Wizzup | what call? | 11:19 |
| freemangordon | call 2356 | 11:19 |
| freemangordon | not possible :) | 11:20 |
| freemangordon | can we check @2331 | 11:20 |
| freemangordon | here | 11:21 |
| freemangordon | see framebuffer contents | 11:21 |
| Wizzup | different terminal sizes | 11:21 |
| freemangordon | right | 11:21 |
| freemangordon | could you check on the previous call? | 11:22 |
| freemangordon | last one of frame 19 | 11:22 |
| freemangordon | swapbuffers one | 11:23 |
| freemangordon | how's that possible? | 11:23 |
| freemangordon | I would say qapitrace lies to us | 11:23 |
| Wizzup | hm, why? | 11:24 |
| freemangordon | I mean - this is the same buffer @start of frame 20, no? | 11:24 |
| Wizzup | right | 11:24 |
| freemangordon | but those were different 2 minutes ago :) | 11:24 |
| freemangordon | ugh | 11:25 |
| Wizzup | looks like they are different after glPixelStorei | 11:25 |
| Wizzup | or do I misunderstand? | 11:26 |
| freemangordon | glPixelStorei should not make any change to the framebuffer | 11:26 |
| freemangordon | it just sets the format for GlTexImage etc | 11:26 |
| Wizzup | ok | 11:26 |
| Wizzup | well the behaviour is the same every time within qapitrace at least | 11:27 |
| freemangordon | but! | 11:27 |
| freemangordon | the right framebuffer cannot be correct | 11:27 |
| Wizzup | the llvmpipe rendered one? | 11:27 |
| freemangordon | yes | 11:27 |
| Wizzup | weird, that is the correct though, for us | 11:27 |
| freemangordon | because we uploaded 720x720 osso-xterm texture | 11:27 |
| freemangordon | how this come to be fullscreen? | 11:28 |
| Wizzup | are you confusing frame 18 and 19? | 11:28 |
| * freemangordon checks | 11:28 | |
| Wizzup | in frame 18 it is small | 11:28 |
| Wizzup | in frame 19 it is normal size | 11:28 |
| freemangordon | no | 11:28 |
| freemangordon | which call in frame 18 that is? | 11:28 |
| freemangordon | ah, right | 11:29 |
| freemangordon | we uploaded 720x720 in frame 18 | 11:29 |
| freemangordon | this become front buffer in frame 19 | 11:29 |
| freemangordon | and become back buffer again in frame 20, right? | 11:29 |
| freemangordon | unless we do 3-buffer | 11:30 |
| freemangordon | maybe check the pointer | 11:30 |
| freemangordon | parameterg of swapbuffers | 11:30 |
| Wizzup | ok | 11:30 |
| Wizzup | looks like only two pointers | 11:30 |
| freemangordon | yeah, we have 2 buffers only | 11:30 |
| Wizzup | the same order every time | 11:30 |
| freemangordon | mhm | 11:31 |
| freemangordon | so, how 720x720 from frame 18 backbufer become fulscreen in frame 20 | 11:31 |
| freemangordon | ? | 11:31 |
| freemangordon | this one, yes | 11:31 |
| freemangordon | that drawarrys, which texture uses? | 11:33 |
| freemangordon | the one that draws it "correctly"? | 11:33 |
| Wizzup | which drawarrays | 11:33 |
| freemangordon | the one that draws correct osso-xterm on llvmpipe | 11:34 |
| freemangordon | 2261 I thin | 11:34 |
| freemangordon | *think | 11:34 |
| freemangordon | could you click on the previous one? | 11:35 |
| freemangordon | previous? | 11:35 |
| freemangordon | hmm, this is frame 19 | 11:35 |
| freemangordon | things here are correct | 11:36 |
| freemangordon | we shall look at either 18 or 20 | 11:36 |
| freemangordon | Wizzup: I mean - can you find the glDrawArrays call that magically turns 720x720 to fullscreen | 11:37 |
| freemangordon | on llvmpipe retrace | 11:37 |
| Wizzup | I don't think that happens, there is a glclear and then another draw | 11:37 |
| Wizzup | in frame 19 | 11:37 |
| freemangordon | but how then we start with correct back buffer in frame 20? | 11:37 |
| freemangordon | frame 19 is ok | 11:38 |
| Wizzup | not sure | 11:38 |
| Wizzup | brb 1 minute | 11:39 |
| Wizzup | b | 11:42 |
| freemangordon | hmm | 11:44 |
| freemangordon | where is that uploaded? | 11:44 |
| Wizzup | which one? | 11:44 |
| Wizzup | for the record I added filtering to only show certain events | 11:45 |
| freemangordon | yeah | 11:45 |
| freemangordon | which call uploads 720x720 texture | 11:45 |
| Wizzup | in frame 18? | 11:46 |
| freemangordon | mhm | 11:46 |
| Wizzup | 1941? | 11:47 |
| * freemangordon checks | 11:49 | |
| freemangordon | no, that's the draw | 11:50 |
| freemangordon | not the upload | 11:50 |
| freemangordon | so, it is texture 66 | 11:50 |
| Wizzup | how do you know? sorry | 11:51 |
| freemangordon | we want either glTexSubImage2D or glTexImage2D call | 11:52 |
| freemangordon | those upload image data | 11:52 |
| Wizzup | I don't see the call that uploads texture 66 | 11:52 |
| freemangordon | maybe it is 67, I am trying to find | 11:53 |
| freemangordon | 1016 | 11:57 |
| freemangordon | is the first upload | 11:58 |
| freemangordon | I think 1193 | 11:58 |
| freemangordon | yep, this is it | 11:59 |
| freemangordon | osso-xterm in landscape | 11:59 |
| Wizzup | ok | 12:00 |
| freemangordon | this is 66 | 12:00 |
| Wizzup | I think I am losing track of what we are investigating | 12:02 |
| freemangordon | :) | 12:02 |
| freemangordon | Wizzup: I want to understand how that lanscape 1440x594 texture becomes fullscreen portrait | 12:03 |
| freemangordon | texture 66 that is | 12:03 |
| Wizzup | ok, but it shouldn't ever touch a swapped out buffer,no? | 12:03 |
| Wizzup | oh, hm | 12:03 |
| Wizzup | I guess some frames in the middle are like the start animation | 12:04 |
| freemangordon | yeah | 12:04 |
| freemangordon | ok, afk for a while, lunch | 12:04 |
| freemangordon | brb | 12:04 |
| Wizzup | ok, I'll close the screen sharing for now | 12:04 |
| freemangordon | ok | 12:05 |
| freemangordon | Wizzup: to me call 2338 is wrong | 12:25 |
| Wizzup | the glScissor call? | 12:26 |
| freemangordon | yes, to me all glScissor calls are wrong | 12:26 |
| Wizzup | ok, do you mean they do not have the right arguments | 12:27 |
| freemangordon | yes | 12:27 |
| freemangordon | I think we shall render the whole texture | 12:27 |
| freemangordon | not only part of it | 12:27 |
| freemangordon | if we take frame 20 as example | 12:29 |
| freemangordon | call 2356 should have scissors with the size of the texture, not the size of the canged part | 12:29 |
| freemangordon | *changed | 12:30 |
| freemangordon | at least that's my understanding | 12:30 |
| Wizzup | ok | 12:31 |
| freemangordon | could you capture the same trace from within VM | 12:31 |
| freemangordon | ? | 12:31 |
| Wizzup | I need to take a break now, brb | 12:31 |
| freemangordon | ok | 12:31 |
| Wizzup | uh | 12:31 |
| freemangordon | I can do it too | 12:31 |
| Wizzup | ok | 12:31 |
| Wizzup | ty | 12:31 |
| freemangordon | later on | 12:31 |
| Wizzup | brb | 12:31 |
| Wizzup | b | 12:57 |
| freemangordon | Wizzup: to me it seems llvmpipe retrace ignores scissors, that's why it renders correctly | 13:05 |
| Wizzup | ah | 13:05 |
| freemangordon | this is a bug though :) | 13:05 |
| Wizzup | just to be clear by the way, this might only be a bug for the fallback path? | 13:05 |
| Wizzup | (there TFP is not available?) | 13:05 |
| Wizzup | s/there/where/ | 13:06 |
| freemangordon | this is a bug in mesa | 13:06 |
| Wizzup | right, I mean, a bug in mesa llvmpipe | 13:06 |
| freemangordon | mesa/llvmpipe | 13:06 |
| freemangordon | yeah | 13:06 |
| Wizzup | interesting, given that the nvidia binary driver also has the problem | 13:06 |
| freemangordon | what do you mean "has the problem" | 13:06 |
| freemangordon | I see corrupted rendering here as well | 13:07 |
| freemangordon | because it obeys scissors | 13:07 |
| freemangordon | but, I think we shall focus on TFP path | 13:07 |
| freemangordon | there we have broken textures | 13:07 |
| freemangordon | and this I would say is a bug in either glamor or in lima | 13:07 |
| freemangordon | basically, 2D path | 13:08 |
| Wizzup | phone sec | 13:11 |
| Wizzup | freemangordon: uh | 13:14 |
| Wizzup | so the llvmpipe trace file is not using TFP, agreed? | 13:14 |
| Wizzup | I think we ought to fix that first | 13:17 |
| Wizzup | and then look at potential bugs in the TFP path | 13:17 |
| freemangordon | yes, it is not using TFP | 13:17 |
| freemangordon | but, TFP is extension which is either supported or not | 13:17 |
| freemangordon | we cannot 'fix' it | 13:17 |
| Wizzup | so the scissor calls are not wrong? | 13:18 |
| freemangordon | in TFP path? | 13:18 |
| Wizzup | no, in the path we were looking at together | 13:18 |
| freemangordon | this is non-TFP path | 13:18 |
| Wizzup | yes | 13:18 |
| Wizzup | let me clarify | 13:18 |
| freemangordon | I think those calls are wrong | 13:18 |
| Wizzup | we looked at non-tfp path, and we found a bug, maybe, I think it is worth fixing | 13:18 |
| freemangordon | not really | 13:19 |
| freemangordon | we should not be using fallback path | 13:19 |
| freemangordon | this ruins the performance | 13:19 |
| freemangordon | basically, this leads to glReadPixels afaik | 13:19 |
| Wizzup | maybe, but lima with fallback path is already much better if we fix it I think | 13:19 |
| freemangordon | no, we shall fix TFP path | 13:20 |
| Wizzup | I am not saying we shouldn't look at the other problem | 13:20 |
| Wizzup | but keeping this path broken seems silly | 13:20 |
| Wizzup | then we should just not have it at all | 13:20 |
| freemangordon | I agree, but this should not be used anyways | 13:20 |
| Wizzup | it is being used in my VM and probably most VMs that people use, as well as upon initial bringup of most devices | 13:20 |
| Wizzup | but I shall not try to argue the merits of fallbacks now | 13:20 |
| freemangordon | Wizzup: at least on vmware and vbox it is TFP that is used | 13:21 |
| Wizzup | I think your setup is special, the one we recommend on the wiki is not acceleration (but still fast on modern cpu) | 13:21 |
| Wizzup | my vm: | 13:22 |
| Wizzup | user@devuan:~$ glxinfo |grep -i 'renderer string' | 13:22 |
| Wizzup | OpenGL renderer string: llvmpipe (LLVM 7.0.1, 256 bits) | 13:22 |
| freemangordon | does it have GL_OES_EGL_image_external? | 13:23 |
| freemangordon | es2_info | grep external | 13:23 |
| freemangordon | GL_RENDERER: llvmpipe (LLVM 7.0.1, 256 bits) :p | 13:24 |
| freemangordon | and yes, we have GL_OES_EGL_image_external | 13:24 |
| freemangordon | which is TFP | 13:24 |
| Wizzup | we don't check for that extension in clutter | 13:24 |
| freemangordon | sure we do | 13:25 |
| freemangordon | sec | 13:25 |
| Wizzup | we look for EGL_NOKIA_texture_from_pixmap and EGL_KHR_image_pixmap | 13:25 |
| freemangordon | hmm | 13:26 |
| Wizzup | G_MESSAGES_DEBUG=all (or w/e the env var is called) will show if it doesn't find them | 13:27 |
| freemangordon | GL_OES_EGL_image | 13:28 |
| freemangordon | but yeah | 13:29 |
| Wizzup | so pretty sure vm uses fallback path | 13:29 |
| Wizzup | but can check now if you want | 13:30 |
| freemangordon | if you can capture trace, it will be perfect | 13:30 |
| freemangordon | I will do it later on if not | 13:30 |
| Wizzup | (/usr/bin/hildon-desktop:4149): ClutterEGL-DEBUG: 13:31:05.368: clutter_eglx_texture_pixmap_init: checking for texture_from_pixmap | 13:31 |
| Wizzup | (/usr/bin/hildon-desktop:4149): ClutterEGL-DEBUG: 13:31:05.368: clutter_eglx_texture_pixmap_init: checking for EGLImage 'texture from pixmap' ability | 13:31 |
| Wizzup | (/usr/bin/hildon-desktop:4149): ClutterEGL-DEBUG: 13:31:05.368: clutter_eglx_texture_pixmap_update_area: Falling back to X11 | 13:31 |
| freemangordon | ok | 13:31 |
| Wizzup | I can capture a trace but it will be just like me other llvmpipe one | 13:31 |
| freemangordon | ok, but if we cannot reproduce int the VM I am afraid it will be very hard to fix | 13:32 |
| freemangordon | maybe I shall try another renderer/driver | 13:32 |
| freemangordon | or in vmware | 13:32 |
| freemangordon | iirc it is not using llvmpipe | 13:32 |
| Wizzup | you have a pinephone, no? | 13:33 |
| freemangordon | yes, I have | 13:33 |
| Wizzup | but please be more clear about 'if we cannot reproduce it' | 13:33 |
| freemangordon | if we cannot reproduce broken rendering | 13:33 |
| freemangordon | in the VM | 13:33 |
| Wizzup | if the scissor calls are wrong, we could attempt to fix, trace that result and rerun on amdgpu or something | 13:33 |
| freemangordon | understand, but this will be really hard | 13:34 |
| Wizzup | let me think about some other ways | 13:34 |
| Wizzup | does xnest support 3d/mesa? | 13:34 |
| freemangordon | ok, so we have the broken an all but llvmpipe, right? | 13:34 |
| freemangordon | *that broken | 13:35 |
| Wizzup | and meridion's nvidia binary driver | 13:35 |
| Wizzup | per the apitrace image dumps | 13:35 |
| freemangordon | weird | 13:35 |
| Wizzup | fwiw I am fine with looking at the TFP bug now, just wanted to make it clear that we make widespread use of the fallback path | 13:36 |
| freemangordon | yeah, agree | 13:37 |
| freemangordon | hmm, I doubt nvidia driver ignores scissirs | 13:37 |
| freemangordon | *scissors | 13:37 |
| Wizzup | it looks like xephyr/xnest doesn't do hw accel rendering, only sw (so llvmpipe) | 13:39 |
| freemangordon | maybe we shall capture on d4 | 13:39 |
| Wizzup | I tried that | 13:39 |
| Wizzup | apitrace segfaults | 13:39 |
| Wizzup | in our pvr mesa so | 13:39 |
| freemangordon | I remember I sent a patch for that ;) | 13:39 |
| Wizzup | to apitrace? | 13:40 |
| freemangordon | mhm | 13:40 |
| Wizzup | ok | 13:40 |
| Wizzup | I thought maybe it was a bug in our pvr mesa stuff | 13:40 |
| freemangordon | lemme try to find it | 13:40 |
| Wizzup | https://github.com/apitrace/apitrace/issues/599 ? | 13:42 |
| freemangordon | yes | 13:43 |
| Wizzup | so I'll build it on the droid4 I guess? | 13:43 |
| freemangordon | don;t really remember, but yeah, I think it makes sense to try upstream apitrace | 13:43 |
| Wizzup | and we will use this trace how? | 13:46 |
| Wizzup | btw, explain to me why llvmpipe also renders lima trace fine | 13:46 |
| Wizzup | if it doesn't support TFP | 13:46 |
| Wizzup | I guess it does support TFP | 13:46 |
| freemangordon | we will use that trace to compare the scissors | 13:47 |
| freemangordon | rertace does not need to support TFP | 13:48 |
| freemangordon | it already has the texture data | 13:48 |
| Wizzup | I will build tag 9.0 of apitrace, tag 1.0 requires newer cmake (sigh) | 13:49 |
| freemangordon | yeah | 13:49 |
| Wizzup | autotools almost never has these problems :) | 13:49 |
| freemangordon | not in the last 10 years at least | 13:49 |
| Wizzup | right | 13:50 |
| freemangordon | hmm, see | 13:52 |
| freemangordon | seems we have the same issue with tfp path | 13:52 |
| Wizzup | right | 13:52 |
| freemangordon | if you look at frame 27 | 13:53 |
| freemangordon | texture in call 2340 looks fine to me | 13:53 |
| freemangordon | but scissor is only 55 pixels tall | 13:54 |
| rafael2k | autotools rocks | 13:54 |
| freemangordon | :nod: | 13:54 |
| Wizzup | freemangordon: let me open the lima trace | 13:54 |
| freemangordon | ok | 13:55 |
| freemangordon | if you change height in call 2325 to be 1440, the frame renders correctly | 13:55 |
| Wizzup | ah | 13:56 |
| freemangordon | ok, seems something has been optimized | 13:56 |
| freemangordon | so scissor box includes only the updated area | 13:57 |
| freemangordon | and somehow it counts on framebuffer to contain valid data | 13:57 |
| Wizzup | yeah | 13:57 |
| freemangordon | from previous draws on a different framebuffer | 13:57 |
| Wizzup | which I guess they cannot rely on | 13:58 |
| freemangordon | yes, but why do they do? | 13:58 |
| freemangordon | also, this seems to work on pvr | 13:58 |
| Wizzup | good question, llvmpipe is fine with it | 13:58 |
| Wizzup | yes | 13:58 |
| freemangordon | to me llvmpipe simply ignores the scissors | 13:59 |
| freemangordon | but, we have pvr and at least one nvidia that does it correctly | 13:59 |
| freemangordon | which does not make sense to me by looking at the trace | 14:00 |
| Wizzup | yes and the nvidia one run was not used for X, it was secondary render | 14:00 |
| freemangordon | or, something has changed between es2 and es3 | 14:00 |
| Wizzup | which could explain the clean buffers | 14:00 |
| freemangordon | clean? | 14:00 |
| Wizzup | not dirty/wrong | 14:00 |
| Wizzup | 13:57 < freemangordon> and somehow it counts on framebuffer to contain valid data | 14:00 |
| freemangordon | yeah | 14:01 |
| freemangordon | but how that valid data end up there? | 14:01 |
| freemangordon | unless they use common memory for both back buffers | 14:01 |
| Wizzup | from previous calls/swaps? | 14:01 |
| freemangordon | which does not make sense at all | 14:01 |
| freemangordon | hmm, maybe there exist a way to do "hidden" copy on swap | 14:02 |
| Wizzup | yeah | 14:02 |
| freemangordon | but I have never heard of anything like that | 14:02 |
| freemangordon | well, actually there is such thing like buffers age | 14:03 |
| freemangordon | and if clutter 0.8 is smart enough to use that, it might explain what we see | 14:03 |
| freemangordon | but I am not sure it is | 14:03 |
| freemangordon | see https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_buffer_age.txt | 14:04 |
| freemangordon | interesting reading https://gitlab.freedesktop.org/lima/mesa/-/issues/59 | 14:16 |
| freemangordon | I wonder if default is EGL_BUFFER_PRESERVED | 14:17 |
| freemangordon | "The initial value of EGL_SWAP_BEHAVIOR is chosen by the implementation. " | 14:17 |
| Wizzup | heh | 14:18 |
| Wizzup | ironically I saw this two days age | 14:21 |
| Wizzup | ago | 14:21 |
| Wizzup | when I was just looking at the differences in extensions | 14:21 |
| Wizzup | didn't think much of it but did look it up | 14:22 |
| Wizzup | freemangordon: fwiw apitrace with your patches in there still segfaults in libGLESv2_PVR_MESA.so | 14:24 |
| freemangordon | :( | 14:24 |
| Wizzup | but sounds like the buffer age might very well be the thing | 14:24 |
| freemangordon | I guess weh shall capture this with pvrtrace | 14:24 |
| Wizzup | maybe we can try to set the swap behaviour first? | 14:25 |
| freemangordon | mhm | 14:25 |
| freemangordon | just cloned clutter, to see if this is already set | 14:25 |
| Wizzup | no calls to eglSurfaceAttrib | 14:25 |
| Wizzup | in clutter 0.8 | 14:25 |
| freemangordon | yeah | 14:26 |
| freemangordon | will try it first in the VM | 14:26 |
| Wizzup | ok | 14:27 |
| Wizzup | I will need to go to a shop quickly before they close | 14:27 |
| freemangordon | will provide patch if it doesn;t break anything | 14:27 |
| freemangordon | ok | 14:27 |
| Wizzup | I'll be back in 25mins | 14:27 |
| Wizzup | or so | 14:27 |
| freemangordon | ok | 14:27 |
| freemangordon | Wizzup: changes nothing in the VM at least | 14:50 |
| freemangordon | I set it to EGL_BUFFER_DESTROYED, hoping that it will break something | 14:51 |
| freemangordon | maybe it is simply ignored by mesa | 14:51 |
| rafael2k | so, if nothing goes wrong in the testing, I think next pp kernel is ready, based on 5.15.10 | 14:51 |
| rafael2k | turning the pp in a build machine <- | 14:52 |
| freemangordon | Wizzup: for you to test when have time https://pastebin.com/1pYU4A05 | 14:53 |
| rafael2k | I'll upload the new 5.15 based pp packages soon for anyone who also wants to test | 14:53 |
| freemangordon | anyway, lemme take a capture | 14:54 |
| Wizzup | hi | 14:56 |
| Wizzup | 14:51 < freemangordon> maybe it is simply ignored by mesa | 14:57 |
| Wizzup | you mean llvmpipe here specifically right | 14:57 |
| freemangordon | yeah | 14:57 |
| Wizzup | ok | 14:58 |
| Wizzup | let me warm up my fingers and try the patch | 14:58 |
| freemangordon | ok, the captured trace is broken on nvidia :) | 15:00 |
| Wizzup | wrt scissor? | 15:00 |
| freemangordon | with stock clutter | 15:00 |
| freemangordon | without that patch | 15:00 |
| freemangordon | I'll capture now with a apatch | 15:00 |
| freemangordon | *with the patch | 15:00 |
| Wizzup | ok | 15:01 |
| Wizzup | I applied it now and the rendering issues with TFP path still exist | 15:01 |
| Wizzup | on lima that is | 15:03 |
| freemangordon | the same on retrace | 15:04 |
| freemangordon | ugh | 15:04 |
| freemangordon | seems this attribute is not supprted | 15:04 |
| freemangordon | on nvidia that is | 15:04 |
| Wizzup | 1) What are the semantics if EGL_BUFFER_PRESERVED is in use | 15:05 |
| Wizzup | RESOLVED: The age will always be 1 in this case. | 15:05 |
| Wizzup | hm | 15:05 |
| freemangordon | mhm | 15:05 |
| Wizzup | btw we can query for the swap behaviour | 15:06 |
| Wizzup | https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglQuerySurface.xhtml | 15:06 |
| Wizzup | btw https://dpaste.com/DYNSC9WK6 | 15:07 |
| freemangordon | yeah | 15:07 |
| freemangordon | but I guess this is harmless | 15:07 |
| Wizzup | but that is only in error path | 15:07 |
| freemangordon | mhm | 15:07 |
| Wizzup | I see this in cogl: | 15:14 |
| Wizzup | /* Some implementation require a clear before drawing | 15:14 |
| Wizzup | to an fbo. Luckily it is affected by scissor test. */ | 15:14 |
| Wizzup | /* FIXME: test where exactly this is needed end whether | 15:14 |
| Wizzup | a glClear with 0 argument is enough */ | 15:14 |
| Wizzup | freemangordon: wb | 15:18 |
| Wizzup | freemangordon: clutter/cogl/gles/cogl-fbo.c has some weird comments | 15:19 |
| Wizzup | freemangordon: regarding scissor and glclear | 15:19 |
| freemangordon | my PC just reset out of the blue :( | 15:22 |
| Wizzup | :( | 15:22 |
| freemangordon | will needs some time to restore the environment | 15:22 |
| Wizzup | ok | 15:23 |
| Wizzup | * clutter/clutter-stage.c: modified comments, made GLES use glScissor based | 15:23 |
| Wizzup | partial updates rather than glViewport (which was too inaccurate and not | 15:23 |
| Wizzup | actually much faster with current drivers) | 15:23 |
| Wizzup | I suppose that might clarify | 15:23 |
| Wizzup | clutter/clutter-stage.c has some weird comments as well regarding DOUBLE_BUFFER and VIEWPORT_DAMAGE | 15:25 |
| Wizzup | seems like they struggled quite a bit with old n900 drivers to make this work well | 15:25 |
| freemangordon | you mean lines 75-? | 15:27 |
| freemangordon | right | 15:27 |
| Wizzup | yeah glScissor is also mentioned in the changelog | 15:27 |
| freemangordon | ugh, it seems pvr driver do blit, not flip | 15:28 |
| Wizzup | and there is that comment that they only reason they use scissor test is to clear a fbo or something | 15:28 |
| freemangordon | ok, maybe you shoudl set that to 1 and test | 15:28 |
| Wizzup | which var in particular? | 15:28 |
| freemangordon | DOUBLE_BUFFER | 15:28 |
| Wizzup | not VIEWPORT_DAMAGE? | 15:28 |
| freemangordon | no | 15:29 |
| Wizzup | ok | 15:29 |
| freemangordon | this shoudl fix it | 15:29 |
| freemangordon | this is exactly the damage tracking we are missing, IIUC | 15:29 |
| Wizzup | I had some other local comments | 15:30 |
| Wizzup | code changes* | 15:30 |
| Wizzup | let me remove those | 15:30 |
| freemangordon | I guess this should also fix tearing, but not really sure | 15:31 |
| freemangordon | on d4 that is | 15:31 |
| Wizzup | most problems are gone | 15:31 |
| Wizzup | the osso selection in particular is still problematic | 15:32 |
| Wizzup | but the conversations bug is gone | 15:32 |
| Wizzup | oh, firefox is still messy | 15:32 |
| Wizzup | ok I spoke too soon | 15:32 |
| Wizzup | btw, hum: (hildon-desktop:10764): ClutterEGL-DEBUG: 15:33:09.110: clutter_eglx_texture_pixmap_paint: X errors | 15:33 |
| Wizzup | oh that is maybe just when windows are closed | 15:33 |
| freemangordon | mhm | 15:34 |
| Wizzup | yeah so I thought it got better, and maybe it did some, but there are still problems | 15:35 |
| Wizzup | I need to go back to my test cases and try | 15:35 |
| Wizzup | so the virtual keyboard renders ok now in portrait always | 15:35 |
| Wizzup | the text input applet also no longer has trouble | 15:35 |
| freemangordon | is it fixed for TFP or for x11 case? | 15:36 |
| Wizzup | nothing is entirely fixed | 15:36 |
| freemangordon | I think TFP has other issues | 15:36 |
| Wizzup | ok | 15:36 |
| Wizzup | let me force fallback | 15:36 |
| Wizzup | I had TFP on | 15:36 |
| freemangordon | yeah | 15:36 |
| Wizzup | no, several problems still exist | 15:40 |
| Wizzup | those could be entirely different problems | 15:40 |
| freemangordon | mhm | 15:40 |
| Wizzup | specifically vkb is ok | 15:40 |
| freemangordon | I captured a trace in the vm | 15:40 |
| freemangordon | lets see if replay on nv will be ok | 15:41 |
| Wizzup | so what is fixed with fallback + double buffer = 1 + buffer preserved is | 15:42 |
| Wizzup | 1. vkb rendering (it shows ok, and it also doesn't 'jump' up for every key press) | 15:42 |
| Wizzup | 2. display and text input applets in cpa (sometimes those would 'bounce' forever) | 15:42 |
| freemangordon | this affects TFP path as well | 15:42 |
| Wizzup | 3. firefox doesn't flicker insanely or at all really | 15:42 |
| Wizzup | without fallback, firefox flickers insanely | 15:42 |
| Wizzup | and in either case, the osso-xterm selection bug is -not- fixed | 15:43 |
| freemangordon | it is, in replay | 15:43 |
| freemangordon | please capture a trace | 15:43 |
| Wizzup | interesting | 15:43 |
| freemangordon | as my capture here in VM is ok on NV | 15:43 |
| freemangordon | hmm, wat was the command to replay? | 15:44 |
| Wizzup | there is apitrace replay | 15:44 |
| Wizzup | but it renders way too fast | 15:44 |
| Wizzup | so I just do dump-images and look at them all | 15:44 |
| freemangordon | ok | 15:44 |
| Wizzup | so to be clear, you want me to capture another osso-xterm select regions with my finger session | 15:45 |
| Wizzup | but this time with the buffer management change, the double buffer change and the fallback change? | 15:45 |
| freemangordon | hmm, what is "buffer management change"? swap behaviour? | 15:46 |
| Wizzup | yes | 15:46 |
| freemangordon | no, remove that | 15:46 |
| freemangordon | double-buffer change should be enough | 15:46 |
| freemangordon | and what is "fallback change"? | 15:46 |
| Wizzup | use_fallback = TRUE; | 15:47 |
| Wizzup | iow force disable tfp path | 15:47 |
| freemangordon | can;t we do that from a env var? | 15:47 |
| Wizzup | probably but this was way easier for me | 15:48 |
| freemangordon | Wizzup: ok | 15:48 |
| Wizzup | also, did you see this: | 15:48 |
| Wizzup | We *should* be double-buffered, but because we're just blitting in | 15:48 |
| Wizzup | glSwapBuffers rather than flipping, we can do without the extra areas | 15:48 |
| Wizzup | drawn. THIS MUST BE SET TO 1 IF FLIPPING IS EVER IMPLEMENTED | 15:48 |
| freemangordon | yes | 15:48 |
| Wizzup | I mean I guess you did | 15:48 |
| Wizzup | ok | 15:48 |
| freemangordon | and we are flipping ;) | 15:48 |
| freemangordon | I guess on fremantle pvr blits, thats why the tearing | 15:48 |
| Wizzup | tearing on the d4 you mean | 15:48 |
| Wizzup | well this was a useful exercise then at least | 15:49 |
| freemangordon | no, I mean on fremantle | 15:49 |
| Wizzup | ok | 15:49 |
| freemangordon | but I expect this change to fix tearing on d4 | 15:49 |
| Wizzup | that would be neat | 15:49 |
| freemangordon | the point is: | 15:49 |
| freemangordon | back then, on fremantle, because pvr or x11 or no idea who was/is using single buffer to do blits, we have that tearing | 15:50 |
| freemangordon | but clutter tracks dameage only for the last frame | 15:50 |
| freemangordon | nowdays we have a real double-buffering, so we must enable last 2 frames damage tracking | 15:51 |
| freemangordon | this is what that note says | 15:51 |
| freemangordon | *IIUC* :0 | 15:51 |
| freemangordon | :p | 15:51 |
| freemangordon | so, please do 2 capture, both with DOUBLE_BUFFER=1 | 15:51 |
| freemangordon | one with TFP and another without | 15:52 |
| Wizzup | of osso-xterm with selection? | 15:52 |
| freemangordon | yes | 15:52 |
| Wizzup | ok | 15:52 |
| Wizzup | do you want lima and llvmpipe renders | 15:52 |
| freemangordon | I think the TFP one will be needed to track why glamor or lima does not render pixmap texture correctly | 15:52 |
| Wizzup | s/renders/traces/ | 15:52 |
| freemangordon | that would mean 4 traces, no? | 15:53 |
| Wizzup | i.e. shall I do the same with LIBGL_ALWAYS_SOFTWARE=1 | 15:53 |
| Wizzup | yes | 15:53 |
| Wizzup | I suppose we don't need it now | 15:53 |
| freemangordon | yeah | 15:53 |
| freemangordon | we may want to do llvmpipe glamor though | 15:53 |
| freemangordon | because I think glamor has bugs, no matter what uvos says :p | 15:53 |
| freemangordon | but, not now | 15:54 |
| Wizzup | how does this look to you: | 15:54 |
| Wizzup | MESA_DEBUG=flush,incomplete_tex,incomplete_fbo LIBGL_DEBUG=verbose G_MESSAGES_DEBUG=all COGL_RENDERER=egl_xlib COGL_DRIVER=gles2 apitrace -a egl -o hildon-desktop-doublebuf-fallback.trace maemo-summoner hildon-desktop.launch | 15:54 |
| freemangordon | ugh | 15:54 |
| freemangordon | why those mesa flags? | 15:54 |
| Wizzup | this is just how I run the command normally | 15:54 |
| Wizzup | I was using them earlier | 15:54 |
| Wizzup | let me remove them | 15:54 |
| Wizzup | just checking with you | 15:54 |
| freemangordon | "apitrace trace -a egl maemo-summoner /usr/bin/hildon-desktop.launch" is all I did in the VM :) | 15:55 |
| Wizzup | freemangordon: btw I replayed it on my laptop and it looks good | 15:56 |
| Wizzup | (what does not look good on lima) | 15:56 |
| Wizzup | https://wizzup.org/dirlist/maemo-leste/lima/new-traces/ | 15:57 |
| Wizzup | now let me do with tfp on | 15:57 |
| freemangordon | This issue reminds me of a proverb that my manager told me back then when I was so much younger, and which translates roughly to " His donkey died because of complex reasons" :) | 15:57 |
| Wizzup | meaning? :D | 15:57 |
| freemangordon | well, it does not work because of several issues, not one or 2 | 15:58 |
| Wizzup | right | 15:58 |
| Wizzup | does the trace also replay ok for you? | 15:58 |
| freemangordon | lemme check | 15:58 |
| freemangordon | yep, looks perfect | 15:59 |
| Wizzup | hm, now with tfp it looks ok | 16:00 |
| Wizzup | wtf | 16:00 |
| freemangordon | mhm | 16:00 |
| freemangordon | as expected | 16:00 |
| freemangordon | ;) | 16:01 |
| Wizzup | well I did rebuild it | 16:01 |
| freemangordon | as I said, TFP was bitten by the same scissors issue | 16:01 |
| freemangordon | was/is | 16:01 |
| freemangordon | but, we have issues in lima/glamor too | 16:01 |
| Wizzup | see https://wizzup.org/dirlist/maemo-leste/lima/new-traces/ | 16:02 |
| Wizzup | I think if we have lima specific bugs we can start asking for their help | 16:02 |
| Wizzup | freemangordon: wait, hang on, I remember now | 16:04 |
| freemangordon | that's why as told you to capture both tfp and fallback :) | 16:04 |
| Wizzup | freemangordon: so regarding this: | 16:04 |
| Wizzup | 16:00 < Wizzup> hm, now with tfp it looks ok | 16:04 |
| Wizzup | 16:00 < Wizzup> wtf | 16:04 |
| Wizzup | this happens because things are slower | 16:04 |
| Wizzup | that is why I was previously struggling to capture traces of some of it | 16:04 |
| freemangordon | what is slower? TFP compared to fallback? | 16:04 |
| Wizzup | no, so let me explain what I mean | 16:05 |
| Wizzup | I was doing osso-xterm test with clutter and TFP enabled | 16:05 |
| Wizzup | and it looked ok on the screen | 16:05 |
| Wizzup | right? | 16:05 |
| Wizzup | that is only because it was run within apitrace | 16:05 |
| Wizzup | if I run h-d outside of apitrace with TFP the same bug that we see with fallback path is there | 16:05 |
| freemangordon | ah, I see | 16:06 |
| freemangordon | so, a missing fence ;) | 16:06 |
| Wizzup | possible yes | 16:06 |
| Wizzup | otherwise it looks pretty ok | 16:07 |
| freemangordon | ok, do you want to rebuild clutter with DOUBLE_BUFFER enabled and rebuild for -devel? | 16:07 |
| freemangordon | or I shall do that? | 16:08 |
| Wizzup | I can do it, just want to check with you that we have more work to do here potentially | 16:08 |
| Wizzup | let me capture a few more traces | 16:08 |
| Wizzup | one in particular | 16:08 |
| freemangordon | ok, but I don;t think we have any more issues in clutter | 16:08 |
| freemangordon | well, we may want to compare fps with VIEWPORT_DAMAGE enabled vs disabled | 16:09 |
| freemangordon | but not now | 16:09 |
| freemangordon | also, we shall do that on n900 | 16:09 |
| Wizzup | actually nevermind I think | 16:10 |
| Wizzup | I replayed the trace and dumped the images locally and the problem is gone | 16:10 |
| Wizzup | so it's either a lima problem or a glamor problem | 16:10 |
| freemangordon | lima I would say | 16:10 |
| Wizzup | (it is scrolling in conversations) | 16:10 |
| freemangordon | because glamor does 2d | 16:11 |
| freemangordon | and we receive ready textures | 16:11 |
| Wizzup | yeah and conversations uses 3d | 16:11 |
| Wizzup | (qml) | 16:11 |
| freemangordon | mhm | 16:11 |
| Wizzup | ok | 16:11 |
| Wizzup | I'll do a clutter build | 16:11 |
| freemangordon | don't forget to revert the other changes :) | 16:11 |
| Wizzup | no worries, those are on a pinephone | 16:11 |
| Wizzup | I only do this work from my laptop and vm | 16:12 |
| freemangordon | ah, ok | 16:12 |
| Wizzup | shall I remove the comments | 16:12 |
| freemangordon | no | 16:12 |
| Wizzup | the one regarding blitting? | 16:12 |
| freemangordon | maybe add a new one | 16:12 |
| Wizzup | ok | 16:12 |
| freemangordon | saying "this no longer holds true on leste, so we enable", etc | 16:13 |
| Wizzup | https://github.com/maemo-leste-upstream-forks/clutter-0.8/commit/13903d341009266d0bfa19806e74625a16ab552a | 16:16 |
| freemangordon | mhm | 16:17 |
| Wizzup | so on the lima front | 16:22 |
| Wizzup | do you suggest I just send the traces I uploaded to them? | 16:22 |
| freemangordon | yeah | 16:24 |
| Wizzup | ok | 16:24 |
| freemangordon | we may provide more info if requested | 16:24 |
| freemangordon | what's the channel? | 16:24 |
| Wizzup | I am in the channel | 16:24 |
| Wizzup | #lima on oftc | 16:24 |
| freemangordon | oftc? | 16:24 |
| Wizzup | irc.oftc.net and you must register and verify | 16:24 |
| freemangordon | ok | 16:24 |
| Wizzup | otherwise you are muted | 16:24 |
| freemangordon | by muted you mean I can only see what others are saying, right? | 16:26 |
| freemangordon | sorry for the maybe stupid question, but how to register? | 16:27 |
| Wizzup | I think /msg NickServ help | 16:27 |
| Wizzup | and then register, and then I had to 'reverify' | 16:27 |
| rafael2k | wow, you are ready doing serios debbuging! cheers! | 16:32 |
| rafael2k | lemme know if there is something I can test here | 16:34 |
| rafael2k | I'm watching kernel compilation TV here in on Maemo PP TV | 16:34 |
| freemangordon | :) | 16:34 |
| freemangordon | season 5? | 16:35 |
| rafael2k | finishing season 5 already | 16:35 |
| Wizzup | freemangordon: it's ready btw | 16:36 |
| Wizzup | in -devel | 16:36 |
| freemangordon | installing already :) | 16:36 |
| Wizzup | I think there is still tearing | 16:38 |
| Wizzup | sorry for spoiler :P | 16:38 |
| Wizzup | but maybe not in your setup, if you did more work | 16:39 |
| freemangordon | :) | 16:39 |
| Wizzup | this d4 is a bit out of date | 16:39 |
| freemangordon | well, it does not boot for me at all | 16:39 |
| freemangordon | hung on Starting PowerVR | 16:39 |
| Wizzup | not good :) | 16:39 |
| freemangordon | and then DDK message | 16:39 |
| freemangordon | and that's all | 16:40 |
| Wizzup | maybe dsme is not called dsme | 16:40 |
| freemangordon | hmm? | 16:40 |
| Wizzup | maybe you renamed it | 16:40 |
| freemangordon | no | 16:40 |
| freemangordon | why should I | 16:40 |
| Wizzup | to prevent it from booting to h-d or something | 16:40 |
| freemangordon | no, I just rebooted from osso-xterm | 16:41 |
| freemangordon | after doing dist-upgrade | 16:41 |
| Wizzup | did that complete entirelyt? | 16:41 |
| Wizzup | on -devel or -experimental? | 16:41 |
| freemangordon | yeah | 16:41 |
| freemangordon | -experimental | 16:41 |
| Wizzup | hmm weird | 16:41 |
| Wizzup | pretty sure my daily one is up to date | 16:42 |
| freemangordon | it seems it just hang after starting powervr service | 16:42 |
| Wizzup | I will upgrade mine but I do not think I am seeing this | 16:43 |
| Wizzup | hm my device says that xserver-xorg-video-omap is being held back | 16:43 |
| Wizzup | wonder why | 16:43 |
| freemangordon | that's why dist-upgrade | 16:43 |
| Wizzup | even with dist-upgrade | 16:43 |
| freemangordon | hmm | 16:43 |
| freemangordon | weird | 16:44 |
| Wizzup | so mesa failed for -devel last night | 16:45 |
| Wizzup | because of some really annoying CI bug | 16:45 |
| Wizzup | I'll get that started now | 16:45 |
| Wizzup | I'll need that to figure out what's up anyway | 16:45 |
| freemangordon | hmm, even emergency shell does not start | 16:45 |
| freemangordon | why is powervr needed there? | 16:45 |
| Wizzup | probably because it is in sysvinit runlevel or something like that | 16:46 |
| Wizzup | is this custom kernel or the one in the repos | 16:46 |
| freemangordon | should be the one in the repos | 16:46 |
| Wizzup | btw with pinephone upgraded things are better for sure | 16:47 |
| Wizzup | but the vkb still has occasional flicker/glitch, but I am going to attribute that to the other thing we're going to chase down | 16:47 |
| freemangordon | this is with TFP? | 16:48 |
| Wizzup | yes | 16:48 |
| freemangordon | ok | 16:48 |
| rafael2k | Unpacking libclutter-0.8-0:arm64 (0.8.2.75+2m7) over (0.8.2.74+2m7.2) ... | 16:48 |
| rafael2k | ; ) | 16:48 |
| freemangordon | :) | 16:48 |
| Wizzup | rafael2k: try pkill hildon-desktop when that is done | 16:48 |
| rafael2k | Wizzup: will this make me lose network connection? I can not lose ssh right now in the middle of kernel compiling. | 16:49 |
| freemangordon | no | 16:49 |
| rafael2k | ok | 16:49 |
| freemangordon | in theory :) | 16:49 |
| rafael2k | lemme wait a bit, I don't want to spend any amp more turning on the screen right now | 16:50 |
| Wizzup | conceptually :p | 16:50 |
| Wizzup | rafael2k: again, just lmk when you want the easy steps to compile on pc/laptop ;) | 16:50 |
| freemangordon | Wizzup: what fps do you get when scrolling in h-d? | 16:50 |
| freemangordon | CLUTTER_SHOW_FPS=1 that is | 16:51 |
| rafael2k | Wizzup: I want (if this kernel is not 100% perfect... next try I'll cross) | 16:51 |
| Wizzup | freemangordon: on pp? | 16:51 |
| freemangordon | mhm | 16:51 |
| Wizzup | freemangordon: and portrait? | 16:52 |
| freemangordon | both | 16:52 |
| freemangordon | just curious | 16:52 |
| Wizzup | freemangordon: 22 landscape, 55-62 on portrait | 16:53 |
| freemangordon | portrait seems fine, glamor/modesetting seem to SW rotate :( | 16:54 |
| Wizzup | yes, but that is a later worry imho | 16:54 |
| freemangordon | yeah | 16:54 |
| freemangordon | ok, I am done for now, bbl | 17:04 |
| Wizzup | mhm | 17:04 |
| Wizzup | I'll look at the problem | 17:04 |
| freemangordon | d4 you mean? | 17:05 |
| Wizzup | the dist-upgrade at least | 17:05 |
| freemangordon | ok | 17:05 |
| freemangordon | Wizzup: well, /usr/bin/pvrsrvinit never seem to exit | 17:11 |
| Wizzup | should it not be in /sbin? | 17:12 |
| Wizzup | anyway I will upgrade and look | 17:12 |
| Wizzup | but I will also be busy for some part this evening | 17:13 |
| freemangordon | me too | 17:13 |
| Wizzup | yeah I guess that makes sense | 17:16 |
| Wizzup | :D | 17:16 |
| sicelo | < Wizzup> [17:43] hm my device says that xserver-xorg-video-omap is being held back <<<--- i got this too | 17:16 |
| Wizzup | sicelo: yes, so I'll try to figure it out once mesa is built | 17:17 |
| rafael2k | fixed ofono packaging using internal libell | 17:36 |
| rafael2k | so we don't need to import newer libell to beowulf (this is how it was built ofono in maemo in the first place anyway... so the right thing to do) | 17:36 |
| Wizzup | yup | 17:37 |
| Wizzup | going to be a nice christmas update | 17:38 |
| Wizzup | esp if we can get this lima/glamor bug fixed | 17:38 |
| rafael2k | that would be pappa frost biggest one | 17:41 |
| Wizzup | newer clutter makes things much better btw | 17:42 |
| rafael2k | cool! will try soon, certainly kernel compilation is finishing! | 17:43 |
| Wizzup | that poor sd card ;) | 17:44 |
| Wizzup | bbiab | 17:44 |
| rafael2k | I compiling in the eMMC | 17:55 |
| rafael2k | it is faster | 17:55 |
| rafael2k | it has luks and crypto... which does not help, but anyway... | 17:56 |
| Wizzup | and it'll die sooner and is not replaceable | 17:57 |
| Wizzup | :P | 17:57 |
| freemangordon | Wizzup: if you have some spare time, could you patch clutter on pp to dump the default value of EGL_SWAP_BEHAVIOUR? | 19:11 |
| rafael2k | compilation still going on... eheheheheh | 19:13 |
| rafael2k | 4h already | 19:13 |
| Wizzup | freemangordon: will do | 19:16 |
| Wizzup | I tested setting it and it did not make a difference fwiw | 19:16 |
| Wizzup | freemangordon: might be tomorrow... picking up gf at the airport | 19:16 |
| Wizzup | freemangordon: but reading the links I shared, it seems very unlikely it is on by default | 19:18 |
| Wizzup | given that lima authors added patches to mesa to allow drivers to disable it | 19:19 |
| Wizzup | the partial update way might work too | 19:24 |
| sicelo | nice hostname & nick n900 | 21:19 |
| buZz | hehe, qtwebbrowser is pretty nice :D too bad of the onscreen keyboard | 22:01 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
