| thomi | robert_ancell: OK, cool. I'm kind of here, kind of not, depending on how long this coffee keeps me awake | 00:00 |
|---|---|---|
| robert_ancell | thomi, :) | 00:10 |
| robert_ancell | ricmm, I'm trying to manually get mir out of proposed - it seems to be in a deadlock due to some build ordering issues | 00:10 |
| RAOF | robert_ancell: I don't see that corruption on ati with mir from -proposed (and usc built against that mir) | 00:22 |
| === chihchun_afk is now known as chihchun | ||
| ricmm | robert_ancell: awesome, thaks | 01:06 |
| ricmm | lemme know how that goes | 01:06 |
| robert_ancell | ricmm, packages are built, just waiting for the job that migrates them from -proposed to universe | 01:10 |
| ricmm | \o/ | 01:11 |
| robert_ancell | ricmm, seems to have worked, I'm upgrading now and pulling in the new versions | 01:23 |
| ricmm | great! | 01:23 |
| robert_ancell | duflu, have you tested bypass on an ati machine? | 01:49 |
| duflu | robert_ancell: No, it proved impossible. Multiple kernel bugs prevent me from being able to. Alf tested it for me | 01:50 |
| robert_ancell | duflu, it's failing in the lab | 01:50 |
| robert_ancell | we've set up ppa:mir-team/qa-testing to just contain bypass, then you can run it in the lab and watch the screen there | 01:50 |
| robert_ancell | has lots of corruption | 01:50 |
| duflu | robert_ancell: Hmm. OK. I was relying on Alexandros' testing. Got kernel 3.11.0+? | 01:50 |
| robert_ancell | the main archive version works | 01:51 |
| robert_ancell | duflu, I don't think I can check until the test completes | 01:51 |
| robert_ancell | thomi, (if still awake) is that true? | 01:51 |
| duflu | robert_ancell: Because corruption is expected. You need the "DMA-buf" fix wherever that was... in kernel 3.11 | 01:51 |
| thomi | robert_ancell: Im still awake | 01:51 |
| thomi | robert_ancell: you should be able to ssh in to the machine while the test is running | 01:52 |
| duflu | robert_ancell: To clarify... I have radeon hardware, but can't test saucy due to saucy being unbootable on my desktop (regardless of graphics) | 01:52 |
| thomi | robert_ancell: obviously you run the risk of affecting the result, but if all you need to do is check package versions it should be OK | 01:52 |
| robert_ancell | duflu, it's running saucy right now and seems to work | 01:53 |
| thomi | robert_ancell: oh, also, the machine may reboot under you :) | 01:53 |
| thomi | IP addresses are all on the wiki, in case you need them | 01:53 |
| robert_ancell | thomi, ta | 01:53 |
| robert_ancell | duflu, so the dma-buf fix is required only for bypass? | 01:53 |
| duflu | robert_ancell: Seems so. Because I can test raring and it fails there. alf said it worked for him on saucy+radeon. | 01:54 |
| robert_ancell | duflu, do you have a bug number? | 01:54 |
| duflu | robert_ancell: We're not also testing XMir at the same time are we? XMir adds new bugs which we would have to exclude | 01:55 |
| robert_ancell | duflu, yes, with xmir | 01:55 |
| duflu | robert_ancell: I wish I had a bug number, or a commit to point to. All anyone has been able to tell me is "you need kernel 3.11". Which seems true for nouveau too | 01:55 |
| robert_ancell | duflu, but saucy is kernel 3.11 | 01:56 |
| duflu | I've also tried kernel 3.11 on raring but ran into other graphics bugs before I could test Mir | 01:56 |
| duflu | robert_ancell: It would be unproductive to debug XMir+radeon+bypass right now. I need someone to test just radeon+bypass | 01:57 |
| duflu | I'm already in the boat of having too many variables at once with another bug | 01:57 |
| robert_ancell | duflu, ok, to be clear. On one of the QA ATI boxes running standard saucy + xmir enabled it works fine, but standard saucy + lp:~vanvugt/mir/bypass + xmir does not | 01:57 |
| robert_ancell | so this is only one variable... | 01:57 |
| duflu | robert_ancell: Not true. We've spent the past few days finding and fixing XMir bugs only revealed by new Mir features (which themselves are bug free) | 01:58 |
| duflu | Maybe we have working saucy images I can boot now. Will retry today | 01:59 |
| robert_ancell | thomi, what is the wiki link | 02:00 |
| thomi | robert_ancell: https://wiki.canonical.com/UbuntuEngineering/QA/Lab | 02:06 |
| kgunn | robert_ancell: is the failure in the mode of the funky stripes? or black screen ? | 02:43 |
| robert_ancell | kgunn, looks like just the funky stripes - the test completed otherwise | 02:44 |
| kgunn | robert_ancell: that is strange as it keeps changing | 02:45 |
| robert_ancell | kgunn, I'm just running saucy without XMir for completeness so we are sure we're comparing apples with apples | 02:45 |
| robert_ancell | yeah | 02:45 |
| robert_ancell | this remote camera is awesome :) | 02:45 |
| kgunn | robert_ancell: so what i'm looking at right now is saucy X | 02:45 |
| kgunn | ? | 02:46 |
| kgunn | well...then... | 02:46 |
| robert_ancell | kgunn, you were looking at saucy + XMir+bypass | 02:46 |
| kgunn | oh | 02:46 |
| kgunn | it is awesome | 02:46 |
| robert_ancell | our mir packages were all out of date - there was some deadlock in the autolanding system | 02:46 |
| robert_ancell | They're up to date now, so running the three cases with these packages | 02:47 |
| kgunn | robert_ancell: i stepped away...did it run yet? | 03:18 |
| robert_ancell | kgunn, yes, just collecting the results | 03:19 |
| robert_ancell | kgunn, emailed you the results | 03:22 |
| robert_ancell | kgunn, what were you looking for? | 03:23 |
| duflu | robert_ancell: The radeon issue, looks like vertical stripes right? | 03:36 |
| robert_ancell | duflu, there's a link to an image in the MP | 03:36 |
| duflu | If that means incorrect pixel format then I have a reasonable theory as to the cause. But haven't been able to reproduce any such issue yet | 03:36 |
| robert_ancell | duflu, that QA machine is at your disposal :) | 03:37 |
| duflu | robert_ancell, OK. I was hoping to not have to invest the time setting up VPNs etc :/ | 03:37 |
| robert_ancell | duflu, I recommend getting the QA VPN set up - it makes life easier | 03:38 |
| robert_ancell | thomi, asleep yet? | 03:38 |
| duflu | I used to... before reinstalling | 03:38 |
| duflu | robert_ancell: Shall I remove the prereq of bypass for timerless? | 03:40 |
| duflu | Just means bypass will conflict for a while | 03:40 |
| robert_ancell | duflu, sounds like a good idea | 03:40 |
| RAOF | Bypass breaks intel XMir too, even single head. | 03:46 |
| thomi | robert_ancell: asleep at my desk, does that count? | 03:47 |
| robert_ancell | RAOF, is it the mir side or the xmir side? | 03:48 |
| robert_ancell | duflu, do you have all the info for the VPN? | 03:48 |
| duflu | robert_ancell: No idea. And now I'm a couple of hours from trying :/ | 03:48 |
| robert_ancell | thomi, can you send any links info to duflu about setting up the QA VPN | 03:49 |
| thomi | sure, let me see where I can find it | 03:49 |
| thomi | duflu: robert_ancell: https://wiki.canonical.com/InformationInfrastructure/IS/VPN | 03:50 |
| thomi | worth noting that it's not so much a 'QA VPN' as a 'Canonical VPN' | 03:50 |
| RAOF | robert_ancell: Possibly a combination of the two | 03:50 |
| thomi | my understanding is that almost everyone who was in the old PS dept. should have an email in their inbox with their private key | 03:51 |
| thomi | otherwise, IS can send you new keys, or help you get it set up | 03:52 |
| duflu | I may get more value sooner by trying to find a way to boot saucy on my desktop (where I have radeon). Haven't succeeded yet but it's worth another try | 03:53 |
| thomi | duflu: otherwise, I may be able to give you SSH access to my radeon laptop, although it will be slow | 03:54 |
| duflu | thomi: If that blurry screenshot is to be trusted then it looks like vertical lines? That one I might have a clue about already | 03:54 |
| thomi | duflu: uhh, I'm not sure what screenshot you refer to | 03:55 |
| duflu | http://imgur.com/1k7tQE5 | 03:56 |
| thomi | oh | 03:56 |
| thomi | ok, well, let me know if you need annything | 03:56 |
| thomi | although for VPN-related things, IS is probably a better bet :) | 03:56 |
| kgunn | robert_ancell: i don't understand how those results can be like that... | 04:06 |
| kgunn | the thing that's supposed to be the crappiest is the best ? | 04:07 |
| robert_ancell | kgunn, yeah... | 04:10 |
| robert_ancell | kgunn, please double check the results but I *think* it was run correctly | 04:10 |
| robert_ancell | bob | 04:11 |
| robert_ancell | beLUmaya | 04:11 |
| robert_ancell | DISPLAY=:0 xev | 04:11 |
| tvoss | duflu, ping | 04:24 |
| tvoss | RAOF, ping | 04:26 |
| RAOF | tvoss: Pong. | 04:26 |
| duflu | tvoss, pong | 04:27 |
| RAOF | mlankhorst: Oooh, you're awake? | 04:27 |
| robert_ancell | RAOF, I notice X doesn't drop focus when you VT switch away - do you think this should be a system compositor special option? | 04:27 |
| RAOF | Hm, I don't know. | 04:28 |
| RAOF | I don't think it makes a huge amount of difference either way. | 04:28 |
| RAOF | But a client really isn't focused if it doesn't display or get input. | 04:28 |
| tvoss | robert_ancell, RAOF the benchmarking results for radeon seem to suggest that X touching the framebuffer makes things slower? | 04:38 |
| tvoss | duflu, kgunn ^ | 04:38 |
| robert_ancell | I've forwarded them to duflu and RAOF | 04:39 |
| RAOF | Does it render correctly? | 04:39 |
| tvoss | robert_ancell, ? | 04:39 |
| robert_ancell | RAOF, not with bypass | 04:40 |
| RAOF | I'm not sure that we should trust the benchmark numbers then. | 04:40 |
| tvoss | RAOF, true | 04:41 |
| duflu | I know that software rendering + bypass is often slower. Which is why bypass is disabled for software surfaces | 04:42 |
| duflu | RAOF: If XMir does any "copies" it's really a software renderer then... ? | 04:52 |
| duflu | And it's lying to Mir in saying this is a hardware surface? | 04:52 |
| duflu | I remember a while back I said we should distinguish between "hardware" buffer residency and hardware blitting, but my suggestion was rejected :/ | 04:53 |
| * duflu *shrugs* and goes to lunch | 04:54 | |
| RAOF | duflu: It's does hardware blitting, from hardware-rendered other buffers. | 04:59 |
| RAOF | duflu: It's as much a hardware surface as any EGL app. | 05:00 |
| tvoss | RAOF, duflu back | 05:27 |
| duflu | RAOF: OK. Though this "copy" I keep hearing about, is that on the CPU? What stage is it? | 05:31 |
| RAOF | duflu: It's on the GPU; X is basically acting as a compositor. | 05:32 |
| RAOF | Except rather than going through GL, it's speaking raw GPU command streams. | 05:32 |
| duflu | RAOF: Sounds fast. I guess if it actually was software copying I would not see the nice reduction in mouse lag with qa-testing(bypass) | 05:33 |
| RAOF | As far as Mir is concerned, though, it's not different than an EGL client. The difference between X and and EGL client is an EGL client has the mesa library to produce the command streams. | 05:33 |
| duflu | RAOF: Oh, BTW, any idea why single-buffering desktop environments would *not* exhibit the frame ordering bug? | 05:34 |
| RAOF | No, and are you certain that they don't? Last time I checked I could get the frame-ordering problem on raw X + xterm. | 05:35 |
| RAOF | But I guess that was a while ago. | 05:35 |
| duflu | RAOF: Almost certain. I could not get it to happen with Compiz doing single buffering, or plain Xfce | 05:37 |
| tvoss | RAOF, can we disable buffer age in X? | 05:37 |
| RAOF | tvoss: Yes, but it doesn't help. | 05:37 |
| tvoss | RAOF, ah | 05:37 |
| duflu | But that could be timing too... single buffer damage-only updates are faster | 05:37 |
| duflu | I have tried making intentionally slow clients, but didn't reproduce it that way | 05:38 |
| tvoss | RAOF, duflu so trying to understand: somewhere the buffer order inside X gets fucked up, and n+1 is submitted before n | 05:39 |
| duflu | It looks like it. I still can't reproduce it with any demo client, no matter how I try to change variables | 05:40 |
| RAOF | I don't believe that is the case - smspillaz was seeing the same problem with his GTK implementation, and he dumped the frames to disc before submitting them and they were correct. | 05:40 |
| RAOF | tvoss: ^^^ | 05:40 |
| duflu | RAOF: No, Sam reported lag only, not buffer misordering. Hence it's still a separate bug. Also that was fixed by ignoring buffer age | 05:41 |
| RAOF | Huh, I thought he'd tried that and it didn't work. | 05:41 |
| RAOF | I'm clearly not up on that bug. | 05:41 |
| tvoss | smspillaz, ping | 05:41 |
| duflu | I have other theories as to where bad ordering could come from. But I will have to learn new Mir code I've never really looked at | 05:42 |
| tvoss | duflu, which one? how can I help? | 05:42 |
| smspillaz | tvoss: pong, but I gotta go soon | 05:42 |
| tvoss | smspillaz, quick x-check: ignoring buffer age in your gtk port fixed the lag? | 05:43 |
| smspillaz | duflu: I'm not so sure if that was "fixed" by ignoring buffer age | 05:43 |
| smspillaz | at least - I didn't see it when I did full repaints but it appears to be a race condition | 05:43 |
| smspillaz | and furthermore, the symptoms I'm seeing are not consistent with incorrect buffer ages being sent | 05:43 |
| smspillaz | I'd suggest running the gtk demo to see if you can reproduce it on your end | 05:44 |
| tvoss | duflu, sounds like a simpler client than X | 05:44 |
| duflu | smspillaz: Yes, sorry, bad choice of words. But at least "worked around" by not using the buffer age | 05:44 |
| duflu | tvoss: Different bug | 05:44 |
| duflu | Hence not a valid test case | 05:44 |
| tvoss | duflu, ack | 05:46 |
| duflu | We have at least three lag/ordering bugs and they are all most definitely separate. It takes careful analysis to know they're different tho | 05:46 |
| smspillaz | duflu: like I said, I'm not sure that not using buffer age would actually fix it | 05:46 |
| smspillaz | it just seems that here it does not trigger that race | 05:46 |
| tvoss | duflu, so for the ordering bug: do we have a frame counter per surface? | 05:47 |
| duflu | tvoss: No, we have a unique ID you can track tho | 05:47 |
| tvoss | duflu, how do we know it's an ordering bug then and not an unfinished rendering? | 05:48 |
| duflu | tvoss: mir_debug_surface_current_buffer_id should be sufficient | 05:48 |
| duflu | tvoss: Unfinished rendering *usually* appears as tearing | 05:48 |
| duflu | But it could also be related to a missing flush/finish or equivalent | 05:48 |
| tvoss | duflu, true, but we are making an assumption here, and at such high frame rates, I would actually want to make sure that it is really ordering :) | 05:49 |
| duflu | tvoss: Well, we have tests for it already in lp:mir. You could also ask the client to check the order it's getting, with mir_debug_surface_current_buffer_id | 05:49 |
| duflu | Of course, tests are never foolproof | 05:50 |
| RAOF | That's how I tracked down the ordering problem last time; by dumping the surface ID all over the place. | 05:50 |
| duflu | RAOF: That was a while ago... we fixed that one right? | 05:50 |
| RAOF | Yeah. | 05:51 |
| RAOF | At least for single outputs and clients with single surfaces :) | 05:52 |
| RAOF | But I don't think that code cared where the buffer came from. | 05:52 |
| duflu | I have had more theories as to how order might be violated. However can't yet find any theoretical reason why it would be in the buffer swapper. That part is now designed to make ordering theoretically guaranteed | 05:52 |
| duflu | We might be racing/messing up in the protocol/threading somewhere though | 05:53 |
| duflu | ... but if it was that easy then you'd think some mir_demo_client could show a similar bug. | 05:53 |
| RAOF | Maybe? | 05:54 |
| RAOF | I think we might want to write a one-surface-per-output version of progressbar that uses GL rather than CPU mapping. | 05:55 |
| duflu | RAOF: egltriangle should be sufficient. Just need to add a parameter to populate output_id methinks | 05:56 |
| duflu | RAOF: I also keep thinking if your surfaces usually only map to one monitor each, then only one compositor thread should be getting each surface. It should behave like single monitor... unless we've messed up the region calculation | 05:57 |
| robert_ancell | RAOF, duflu, kgunn, racarr|desert, hikiko, tvoss, thomi, meeting time... | 05:57 |
| thomi | omw | 05:58 |
| tvoss | robert_ancell, not on broadband, will try to join, though | 05:59 |
| thomi | ugh, RAGE! | 06:00 |
| thomi | stupid technology | 06:00 |
| tvoss | duflu, do we see the ordering issue only on multi-monitor or also on single output? | 06:00 |
| thomi | robert_ancell: can someone link me the hangout url please? It's now showing up in my calendar | 06:01 |
| duflu | tvoss: Multimonitor only | 06:01 |
| tvoss | duflu, my understanding: it's trunk + bypass exposing it when used with XMir? | 06:01 |
| duflu | tvoss: No, multimonitor only. And even without bypass | 06:02 |
| tvoss | duflu, ah, that helps a lot | 06:03 |
| duflu | tvoss: It happens on qa-testing2 (no bypass) | 06:03 |
| tvoss | duflu, ack. So to land bypass, we need to check the weird ati numbers | 06:05 |
| duflu | tvoss: And corruption | 06:08 |
| duflu | tvoss: I will be in a better state to test and fix when I can boot saucy on my desktop. Which I cannot yet :( | 06:08 |
| tvoss | duflu, ack, what is blocking you from booting saucy on your desktop? | 06:11 |
| duflu | tvoss: Kernel/BIOS issues new in saucy. Cannot even start to boot it | 06:12 |
| tvoss | robert_ancell, which ppa did you use to run the openarena benchmarks? qa-testing? | 06:12 |
| tvoss | duflu, got a bug report? | 06:12 |
| robert_ancell | tvoss, ye | 06:12 |
| robert_ancell | s | 06:12 |
| duflu | tvoss: https://bugs.launchpad.net/bugs/1212977 | 06:12 |
| ubot5 | Launchpad bug 1212977 in linux (Ubuntu) "saucy daily-live images are unbootable on Dell Optiplex 990; stuck in BusyBox shell" [High,Incomplete] | 06:12 |
| tvoss | duflu, thx | 06:13 |
| mlankhorst | RAOF: yeah | 06:13 |
| mlankhorst | RAOF: did you get my message and video? :P | 06:13 |
| RAOF | mlankhorst: Yes | 06:13 |
| mlankhorst | ah good | 06:14 |
| RAOF | mlankhorst: I had a couple of questions. Mainly - is that pixmap the screen pixmap? | 06:14 |
| mlankhorst | no idea, considering the code it was from i would assume so :P | 06:14 |
| mlankhorst | tvoss: xorg-server is unmodified for bypass right? | 06:22 |
| olli | robert_ancell, mir/archive should be unblcoked | 06:22 |
| tvoss | mlankhorst, ack | 06:23 |
| robert_ancell | olli, yeah, it was another issue, fixed now | 06:23 |
| olli | ok | 06:23 |
| RAOF | mlankhorst: gdb and print out (screen->GetScreenPixmap)(screen)? | 06:24 |
| mlankhorst | RAOF: oh right it might be very much possible that it switches the front buffer in fullscreen gl case | 06:25 |
| mlankhorst | tvoss: hm interesting noise pattern :P | 06:25 |
| hikiko | could anyone review this branch: https://code.launchpad.net/~hikiko/mir/mir.native-gbm-platform-class/+merge/182074 ? | 06:25 |
| mlankhorst | I can vaguely make out the details | 06:25 |
| mlankhorst | tiling or pixel format is messed up | 06:26 |
| RAOF | mlankhorst: And I've just noticed that nouveau *does* keep a track of what it thinks is the front buffer that is wrong as soon as xmir_resize hits... | 06:26 |
| mlankhorst | RAOF: hah! | 06:26 |
| robert_ancell | later all | 06:26 |
| RAOF | SetScreenPixmap hooks for everybody! | 06:26 |
| RAOF | robert_ancell: 'night! | 06:26 |
| hikiko | bye robert_ancell | 06:26 |
| RAOF | Also, I really really really really hate the way xf86-video-ati has an open coded "set up this radeon_surface" struct in like 2032232332342342 different places. | 06:27 |
| RAOF | That's right. There are more copies of that code than there are lines of code. | 06:27 |
| mlankhorst | tvoss: actually on closer look it looks like there are vertical lines that look correct, 4 pixels? then another vertical line with garbage | 06:27 |
| RAOF | It's very quantum. | 06:27 |
| mlankhorst | so dno | 06:27 |
| * RAOF goes and get groceries for dinner. | 06:28 | |
| mlankhorst | RAOF: welcome to radeon ;) | 06:28 |
| mlankhorst | RAOF: don't look at the kernel! | 06:28 |
| mlankhorst | it has 5 copies of 'is this command ring working' | 06:28 |
| mlankhorst | one for each ring | 06:28 |
| tvoss | duflu, did you see mlankhorst's findings? | 06:30 |
| duflu | afk | 06:30 |
| tvoss | duflu, ack | 06:30 |
| mlankhorst | nothing in dmesg this time | 06:31 |
| tvoss | mlankhorst, can you check with a mir demo client if the corruption shows up with that? | 06:31 |
| tvoss | mlankhorst, you can use lp:~thomas-voss/glmark2/mir-no-deprecated-functions and run it in fullscreen | 06:33 |
| mlankhorst | hm crash on eglplasma :P | 06:33 |
| tvoss | hah | 06:33 |
| mlankhorst | http://paste.debian.net/31210/ | 06:34 |
| mlankhorst | that's the eglplasma thing crashing, i think usc went too | 06:34 |
| tvoss | mlankhorst, thx | 06:34 |
| tvoss | mlankhorst, can you verify that usc did really crash? | 06:34 |
| mlankhorst | Program received signal SIGABRT, Aborted. | 06:35 |
| mlankhorst | [Switching to Thread 0x7f165cafe700 (LWP 2149)] | 06:35 |
| mlankhorst | 0x00007f1669126f77 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 | 06:35 |
| mlankhorst | 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: Bestand of map bestaat niet. | 06:35 |
| mlankhorst | http://paste.debian.net/31211/ | 06:36 |
| mlankhorst | lol, crashes on closing egltriangle too | 06:37 |
| mlankhorst | but the triangle looks fine, fwiw | 06:37 |
| tvoss | mlankhorst, okay, thanks for the hints | 06:38 |
| mlankhorst | back to the drawing board for you? :P I'm going to test for raof a bit | 06:38 |
| tvoss | mlankhorst, ack, calling some people to get an amd machine now | 06:39 |
| tvoss | mlankhorst, okay, I'm mostly interested in the corruption right now | 06:41 |
| mlankhorst | tvoss: oh I'm still on mesa 9.2 fwiw | 06:49 |
| tvoss | mlankhorst, mind switching to default saucy? | 06:50 |
| duflu | Sorry... had to get a quick fix for my leaky roof. Done I think | 06:51 |
| duflu | tvoss: What am I looking at? | 06:52 |
| mlankhorst | tvoss: actually I do, need to finish testing on that first :P | 06:52 |
| mlankhorst | but fine | 06:52 |
| duflu | mlankhorst: Yes I suspect the vertical lines might just be the drm fb using the wrong pixel format to the attached bo | 06:54 |
| duflu | Since we don't actually set it yet... | 06:55 |
| duflu | mlankhorst: Also, compiz _will_ switch front buffers, when it decides a fullscreen window can be "unredirected" | 06:56 |
| mlankhorst | that probably sounds about right :P | 06:56 |
| duflu | tvoss: "did you see mlankhorst's findings?" .... where? | 06:58 |
| mlankhorst | actually it looks like even worse garbage on 9.1.6 :P | 06:59 |
| mlankhorst | might just be freed memory being displayed | 06:59 |
| mlankhorst | hm then again it looks too much like what should be displayed, so i dont know | 07:00 |
| mlankhorst | but there's definitely some garbage on top of it | 07:00 |
| duflu | mlankhorst, sounds like what I saw with radeon doing bypass on raring. Still could never test saucy | 07:01 |
| tvoss | duflu, where would we need to set the pixel format? | 07:11 |
| duflu | tvoss: DRM calls. I will put together an attempt momentarily... which I have done before but never found a need to modify that code till now | 07:12 |
| duflu | I mean, it's something I've tried before but never found a system where it was necessary, yet | 07:12 |
| mlankhorst | $6 = {drawable = {type = 1 '\001', class = 0 '\000', depth = 24 '\030', bitsPerPixel = 32 ' ', id = 0, x = 0, y = 0, width = 2720, height = 1024, pScreen = 0x7f92f1e1b700, serialNumber = 2589}, | 07:13 |
| mlankhorst | devPrivates = 0x7f92f264ef38, refcnt = 1, devKind = 10880, devPrivate = {ptr = 0x0, val = 0, uval = 0, fptr = 0x0}, screen_x = 0, screen_y = 0, usage_hint = 2, master_pixmap = 0x0} | 07:13 |
| mlankhorst | RAOF: screen pixmap^ | 07:13 |
| mlankhorst | but the pixmap the function is called with is this | 07:13 |
| mlankhorst | $7 = {drawable = {type = 1 '\001', class = 0 '\000', depth = 24 '\030', bitsPerPixel = 32 ' ', id = 0, x = 0, y = 0, width = 1280, height = 1024, pScreen = 0x7f92f1e1b700, serialNumber = 2124}, | 07:13 |
| tvoss | duflu, ack | 07:13 |
| mlankhorst | devPrivates = 0x7f92f1e8aca8, refcnt = 1, devKind = 5120, devPrivate = {ptr = 0x0, val = 0, uval = 0, fptr = 0x0}, screen_x = 0, screen_y = 0, usage_hint = 0, master_pixmap = 0x0} | 07:13 |
| RAOF | mlankhorst: Thanks. | 07:16 |
| duflu | Silly question... "DMAbuf" I've never seen explicitly mentioned. Is it part of how we use drmModeAddFB ? | 07:21 |
| RAOF | No. | 07:22 |
| RAOF | dma-buf is our buffer IPC mechanism. | 07:22 |
| RAOF | We go from a gem name (for use in drmModeAddFB et al) to a dma-buf fd and back. | 07:23 |
| duflu | RAOF: Umm, kay. So it is correct to pass in gbm_bo_get_handle(bo).u32 (the "gem" handle?) to AddFB? | 07:25 |
| duflu | Obviously it works for intel+nouveau... | 07:25 |
| RAOF | Yup, that would be the right thing. | 07:26 |
| duflu | It's really confusing when people talk about "gem" this and that, even in naming variables, but "gem" isn't mentioned in the API at all. It's just uint32_t | 07:30 |
| tvoss | duflu, sounds like we should have a wrapper for that then :) | 07:31 |
| * tvoss restarts | 07:31 | |
| duflu | tvoss: Not Mir's fault. Just DRM... undocumented | 07:31 |
| tvoss | duflu, ack | 07:31 |
| Mirv | someone could check my two MP:s to get trunks in sync with the archive rebuilds https://code.launchpad.net/~timo-jyrinki/unity-mir/sync_to_archive/+merge/182553 + https://code.launchpad.net/~timo-jyrinki/unity-system-compositor/sync_to_archive/+merge/182554 | 07:34 |
| mlankhorst | duflu: yeah gem predates dma-buf, fd's were too expensive at the time :P | 07:35 |
| Mirv | not sure why robert changed that architecture line in a 'no change' rebuild, but it seems fine | 07:35 |
| tvoss | duflu, is the bypass branch in sync with trunk? | 07:37 |
| RAOF | mlankhorst: Fun story: randr resizes don't fix up the root window pixmap. | 07:37 |
| duflu | tvoss: Not sure about the LP one, but there have been no conflicts or logic changes since 14 Aug | 07:37 |
| duflu | tvoss: I'm working on it locally | 07:37 |
| mlankhorst | RAOF: you don't say ;) | 07:38 |
| tvoss | duflu, ack | 07:38 |
| RAOF | mlankhorst: Would you kindly check the new xserver & nouveau? They're in qa-testing2 and also in git. | 07:43 |
| mlankhorst | sure | 07:44 |
| duflu | RAOF, mlankhorst: Is it standard to use fourcc's for pixel formats now? I can't tell when pixel_format is just uint32_t | 07:47 |
| mlankhorst | I guess so, just look at the source I guess | 07:48 |
| duflu | Ah, in place of documentation, interpret the source :) | 07:48 |
| duflu | mlankhorst: Is it generally considered valid to keep an alpha channel on scanout buffers? Or expected to fail? | 07:49 |
| RAOF | duflu: Pixel format is always just a uint32_t. Sometimes it's just a uint32_t generated by concatenating 4 bytes... | 07:51 |
| RAOF | dma-buf brought drm in to the magical world of fourccs, because it implies interop with v4l stuff. | 07:52 |
| RAOF | To the Zoë! | 07:52 |
| tvoss | RAOF, :) | 07:53 |
| tvoss | mlankhorst, what's the status of https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1214066 | 07:59 |
| tvoss | ? | 07:59 |
| ubot5 | Launchpad bug 1214066 in xorg (Ubuntu) "phoronix benchmarks on nouveau is 4 times slower today than it was last thursday" [Undecided,Incomplete] | 07:59 |
| mlankhorst | as it says in the status, undecided, incomplete | 08:00 |
| mlankhorst | :P | 08:01 |
| tvoss | mlankhorst, have you seen similar behavior on your machine? | 08:01 |
| mlankhorst | not really, but I'm planning on releasing 9.2 soon | 08:01 |
| tvoss | mlankhorst, okay, eta? | 08:01 |
| tvoss | mlankhorst, is there a ppa with 9.2 such that I can test with Mir and XMir? | 08:02 |
| mlankhorst | ppa:canonical-x/x-staging | 08:02 |
| tvoss | mlankhorst, ack | 08:02 |
| tvoss | mlankhorst, so that has got all our mesa patches for Mir, too? just x-checking | 08:02 |
| duflu | mlankhorst: The bypass corruption issue... could that be because nothing is marked as dirty? | 08:03 |
| duflu | I just noticed the "dirty" feature | 08:03 |
| mlankhorst | no idea | 08:03 |
| mlankhorst | i think xorg only sends stuff when marked as dirty | 08:03 |
| duflu | The more I read, the more it sounds like bypass might /require/ it for some hardware | 08:05 |
| mlankhorst | I guess mir needs to be at least told a buffer is dirty :P | 08:10 |
| duflu | mlankhorst: I find some platforms fail to page flip with pixel_format's containing alpha. Can I tell if it's going to work before attempting the flip? Seems like I can't | 08:18 |
| mlankhorst | duflu: dno, I think if you can create a fb with the format flip should work | 08:19 |
| duflu | mlankhorst: FB creation always succeeds. But the drivers only check if the pixel_format is compatible later when the flip is attempted :( | 08:20 |
| hikiko | duflu, do you have some time to review a branch? (sorry I need to merge it and alf is on holidays so it's approved only by alan and jenkins) could you get a quick look? it's a very small change... | 08:22 |
| duflu | hikiko: Maybe. Not sure. I'm already way overloaded for the next day or two | 08:22 |
| mlankhorst | duflu: well strictly speaking ARGB would be compatible for flipping.. | 08:22 |
| mlankhorst | but as XRGB | 08:22 |
| duflu | mlankhorst: Apparently not. intel rejects AR24, only flips XR24. | 08:23 |
| hikiko | duflu, only if you have some free time (here it is: https://code.launchpad.net/~hikiko/mir/mir.native-gbm-platform-class/+merge/182074) +thank you :) | 08:23 |
| mlankhorst | duflu: kernel or userspace? | 08:23 |
| duflu | mlankhorst: Userspace | 08:23 |
| mlankhorst | then fix userspace.. | 08:23 |
| hikiko | hi alan_g :) | 08:32 |
| alan_g | hikiko: hi | 08:32 |
| hikiko | alan_g, I was waiting for you! :) can I merge this one: https://code.launchpad.net/~hikiko/mir/mir.native-gbm-platform-class/+merge/182074 | 08:33 |
| hikiko | ? | 08:33 |
| alan_g | hikiko: Yeah, autolanding failed for "unrelated reasons". I'll top-approve again | 08:34 |
| hikiko | thank you alan_g :) | 08:35 |
| alan_g | hikiko: can you do the same for https://code.launchpad.net/~alan-griffiths/mir/spike-NestedOutput/+merge/182405? | 08:35 |
| hikiko | yes | 08:35 |
| hikiko | I thought it was merged.. done alan_g :) | 08:36 |
| alan_g | hikiko: there are some intermittent test failures that we see in CI. No-one has got to the bottom of them yet | 08:37 |
| hikiko | what is the Cl? | 08:38 |
| alan_g | CI == Continuous Integration | 08:38 |
| hikiko | I see | 08:39 |
| tvoss | duflu, RAOF back | 08:56 |
| tvoss | duflu, any more insights? | 08:56 |
| duflu | tvoss: I have an experimental change that might fix radeon. But lots of mocks are now broken :( | 08:57 |
| tvoss | duflu, okay, can you get packages over to mlankhorst? disable tests in the package build if need be | 08:57 |
| tvoss | just to verify that the change fixes radeon | 08:58 |
| duflu | tvoss: I will test it with everything I have first. Make sure nothing regressed | 08:58 |
| tvoss | duflu, ack | 08:59 |
| tvoss | duflu, I have got an amd machine now | 08:59 |
| tvoss | duflu, need to set it up with 13.04 | 08:59 |
| RAOF | mlankhorst: How'd testing go? | 09:00 |
| === chihchun is now known as chihchun_afk | ||
| mlankhorst | RAOF: oops was waiting for the build | 09:03 |
| RAOF | Slacker :) | 09:03 |
| tvoss | mlankhorst, xmir from archive working fine with mesa 9.2 on intel | 09:07 |
| === chihchun_afk is now known as chihchun | ||
| mlankhorst | tvoss: yeah noticed the same with nouveau + radeon | 09:10 |
| duflu | Wow, I hate gmock more than ever now | 09:19 |
| duflu | Its sharing of details you shouldn't know and should be free to modify is absurd | 09:19 |
| tvoss | duflu, could you verify locally that things work fine on intel? | 09:20 |
| duflu | tvoss: Yes, about to start hardware testing. Given up trying to fix all the DRM mocks | 09:20 |
| duflu | brb | 09:21 |
| RAOF | mlankhorst: Still waiting for the build? :) | 09:29 |
| mlankhorst | nah was setting up my site | 09:36 |
| mlankhorst | with ssl.. https://mblankhorst.nl/ | 09:36 |
| Mirv | the mir+mirslave on't publish next cu2d run if https://code.launchpad.net/~timo-jyrinki/unity-system-compositor/sync_to_archive/+merge/182554 + https://code.launchpad.net/~timo-jyrinki/unity-mir/sync_to_archive/+merge/182553 don't get merged | 09:40 |
| mlankhorst | RAOF: hm your build is a fail :P | 09:41 |
| mlankhorst | it built against the wrong mir? | 09:42 |
| RAOF | Both build locally!!!!! | 09:42 |
| mlankhorst | of course but there's a newer mir in the distro archive | 09:42 |
| mlankhorst | which it built against | 09:42 |
| RAOF | Arse | 09:42 |
| RAOF | Just force dependencies; mirclient ABI hasn't changed. | 09:43 |
| mlankhorst | boom, dead | 09:48 |
| mlankhorst | #0 NVSetScreenPixmap (ppix=0x7f84f7000490) at ../../src/nv_driver.c:613 | 09:50 |
| mlankhorst | no bo attached yet, har har | 09:53 |
| mlankhorst | (gdb) print (struct nouveau_pixmap *)exaGetPixmapDriverPrivate(ppix) | 09:54 |
| mlankhorst | $6 = (struct nouveau_pixmap *) 0x0 | 09:54 |
| mlankhorst | did you mean: nouveau_pixmap_bo ? :P | 09:54 |
| mlankhorst | I think you're worrying too much about scanout, tbh.. | 09:56 |
| mlankhorst | RAOF: where do you see nouveau actually _using_ scanout? | 09:57 |
| mlankhorst | if you moved pScrn->displayWidth out from NVMapMem, I bet you could get rid of pNv->scanout entirely for xorgMir.. | 09:58 |
| RAOF | A bit in nv_accel, but mostly in drmmode_display. It probably can be just wrong. | 09:58 |
| mlankhorst | I would think so :p | 09:58 |
| mlankhorst | bet it's the same for ati though | 10:00 |
| katie | tvoss, ping | 10:00 |
| tvoss | katie, pong | 10:00 |
| RAOF | mlankhorst: Probably, yeah. | 10:01 |
| RAOF | mlankhorst: Do you want to patch that out locally, or do you need me to push a patch for it? | 10:04 |
| mlankhorst | sec | 10:05 |
| mlankhorst | testing if nvmapmem can be skipped entirely | 10:05 |
| RAOF | Looks like it can, although fbScreenInit is probably going to want *something* moderately sane as displayWidth. | 10:06 |
| mlankhorst | yeah but it should | 10:10 |
| mlankhorst | probably unconditionally set it from earlier | 10:10 |
| mlankhorst | RAOF: you still failed :P | 10:13 |
| RAOF | Booo | 10:13 |
| mlankhorst | hm GetScreenPixmap is null | 10:13 |
| RAOF | Wat now? | 10:13 |
| RAOF | How is getscreenpixmap null? | 10:13 |
| duflu | tvoss: I have tested all the hardware I can test, and can't see any change in behaviour... but this might fix the test lab radeon issue: lp:~vanvugt/mir/bypass-drmModeAddFB2 | 10:14 |
| RAOF | That's not my fault :) | 10:14 |
| mlankhorst | ok it might want some more sanity for displayWidth then. | 10:14 |
| tvoss | mlankhorst, can you test lp:~vanvugt/mir/bypass-drmModeAddFB2 | 10:16 |
| tvoss | ? | 10:16 |
| tvoss | mlankhorst, I'm mostly done setting up my amd machine, too | 10:17 |
| duflu | tvoss: Still can't boot saucy with today's images either | 10:17 |
| duflu | Maybe I will have to try a BIOS. Somehow | 10:17 |
| mlankhorst | RAOF: hm the pixmap you create has no bo, and now nouveau_xmir_copy_to_mir crashes on that ;P | 10:19 |
| RAOF | mlankhorst: Huh. I don't immediately see why that would be the case. | 10:21 |
| mlankhorst | are you using createpixmap instead of createpixmap2? :p | 10:25 |
| tvoss | duflu, I can totally reproduce the garbled screen issue on ati with qa-testing \o/ | 10:26 |
| tvoss | duflu, there is hope ;) | 10:26 |
| mlankhorst | hm seems so.. | 10:26 |
| duflu | tvoss: Woo | 10:26 |
| RAOF | mlankhorst: Neither; I'm using Screen->CreatePixmap | 10:26 |
| duflu | tvoss: How garbled? Any lines? | 10:26 |
| tvoss | duflu, completely garbled, I couldn't see a thing | 10:27 |
| duflu | tvoss: Sounds like what I see with radeon on raring. I only assumed saucy would fix it cos alf said it worked for him | 10:27 |
| tvoss | duflu, not working here | 10:28 |
| tvoss | duflu, anyway, I can at least reproduce, compiling packages from your branch right now | 10:28 |
| RAOF | mlankhorst: Ah, maybe nouveau needs to migrate the pixmap in nouveau_xmir_copy_to_mir | 10:28 |
| RAOF | ? | 10:28 |
| duflu | tvoss: Excellent, thanks | 10:28 |
| tvoss | duflu, ack | 10:28 |
| mlankhorst | RAOF: probably.. | 10:28 |
| mlankhorst | RAOF: actually nouveau shouldn't, xmir should :P | 10:29 |
| RAOF | mlankhorst: Why? | 10:29 |
| RAOF | There's no driver-independent way of doing that, at least that I know of. | 10:30 |
| RAOF | It's a DDX-internal (or, really, EXA internal) implementation detail. | 10:30 |
| mlankhorst | exa is doing it :P | 10:30 |
| mlankhorst | RAOF: in that case is there any way to force it to be migrated into the driver? | 10:31 |
| RAOF | You just need to throw an exaMoveInPixmap(src) at the top of nouveoau_xmir_copy_to_mir | 10:31 |
| mlankhorst | any idea why I didn't hit this before, though? | 10:33 |
| RAOF | mlankhorst: Because we weren't changing the screen resolution, so you got the fully-accelerated thing that nouveau creates on startup. | 10:37 |
| mlankhorst | also no luck.. | 10:38 |
| RAOF | No fixy? | 10:39 |
| RAOF | Still no bo after exaMoveInPixmap()? | 10:39 |
| mlankhorst | hm seems there is simply no bo, driverprivate exists | 10:39 |
| mlankhorst | so width = 0 or height = 0 at time of creation, breaking on nouveau_exa_create_pixmap shows both were 0 at time of CreateScreenResources.. | 10:46 |
| RAOF | Oh! You're not hitting this after resize, but on startup? | 10:47 |
| mlankhorst | yeah | 10:49 |
| RAOF | Oh. You're no longer creating pNv->scanout, are you? | 10:49 |
| mlankhorst | indeed | 10:49 |
| RAOF | So when NVCreateScreenResources refs pNv->scanout into GetScreenPixmap()->bo… | 10:50 |
| mlankhorst | well I fixed that one | 10:50 |
| mlankhorst | and that only happens later, it dies in createscreenresources before that point | 10:51 |
| mlankhorst | hm or not, let me rebuild just to be sure | 10:51 |
| RAOF | Yeah, but you map anything into GetScreenPixmap()->bo? | 10:51 |
| mlankhorst | hm no, should it? | 10:52 |
| RAOF | Probably; as you say, the screen pixmap is created in miCreateScreenResources with width = height = 0 and then ModifyPixmapHeader'd. | 10:54 |
| mlankhorst | how nasty.. | 10:54 |
| RAOF | Yeah, I'm not entirely sure why it does that. | 10:56 |
| mlankhorst | setscreenpixmap is not even called though :P | 10:57 |
| mlankhorst | miSetScreenPixmap isn't, at least | 10:58 |
| mlankhorst | RAOF: does xserver always use ModifyPixmapHeader to change resolution? | 11:00 |
| RAOF | Hahahahahahha! | 11:00 |
| RAOF | Modify resolution! Surely you jest! | 11:00 |
| mlankhorst | ugh w/e | 11:00 |
| mlankhorst | s/change/during/ | 11:00 |
| RAOF | No; xserver doesn't modify resolution. It delegates that entirely to the driver. | 11:00 |
| mlankhorst | ok so how does xmir handle it :P | 11:01 |
| RAOF | c/o randr. | 11:01 |
| RAOF | I use Screen->CreatePixmap(new_width, new_height, ...) | 11:01 |
| RAOF | Then set the screen pixmap & root window pixmap. | 11:01 |
| RAOF | But that code doesn't get called on startup. | 11:02 |
| RAOF | On startup it's just miCreateScreenResources shoving stuff directly into pScreen->devPrivate. | 11:03 |
| mlankhorst | hm adding exaMoveInPixmap(src) to createscreenresources probably worked | 11:09 |
| duflu | RAOF: tvoss showed me webcam of what looks like bypass working on radeon. But the stride is all messed up. Have you fixed any radeon stride-ness? | 11:09 |
| mlankhorst | something crashed though :P | 11:09 |
| mlankhorst | but might just be the gpu *checks* | 11:09 |
| RAOF | duflu: What version of radeon/xmir? | 11:10 |
| tvoss | RAOF, archive | 11:10 |
| tvoss | RAOF, or better qa-testing, which is archive | 11:11 |
| * RAOF tries to page that version of the driver back into my brain. | 11:11 | |
| tvoss | RAOF, sorry for the context switch | 11:12 |
| RAOF | duflu: There have certainly been stride-related *changes* between there and qa-testing2 | 11:12 |
| duflu | So... get the DDX from qa-testing2? | 11:12 |
| RAOF | You'd need both the DDX and xserver from qa-testing2 | 11:14 |
| duflu | OK, same bug or not, I'm reinstalling radeon. BRB | 11:14 |
| tvoss | duflu, qa-testing shows the same pattern | 11:14 |
| tvoss | duflu, slightly more noisy though | 11:15 |
| duflu | tvoss: So the new branch made no difference. I recommend the old one (in qa-testing) | 11:15 |
| duflu | Going to put radeon back in | 11:15 |
| duflu | 5 min | 11:15 |
| === alan_g is now known as alan_g|afk | ||
| tvoss | hah, egl-triangle works perfectly fine :) | 11:16 |
| tvoss | RAOF, would it work if I take X and radeon from qa-testing2? | 11:17 |
| RAOF | tvoss: Should, yes. | 11:17 |
| tvoss | RAOF, ack | 11:18 |
| RAOF | Well, obviously modulo the Mir bugs you're trying to track down :) | 11:18 |
| tvoss | RAOF, ;) | 11:18 |
| tvoss | duflu, \o/ egltriangle is working perfectly fine on qa-testing | 11:18 |
| tvoss | with the noise in the background ;) | 11:18 |
| duflu | tvoss: Umm, what?! | 11:18 |
| tvoss | duflu, wanna see? | 11:19 |
| duflu | Sure | 11:19 |
| tvoss | duflu, calling you on g+ | 11:19 |
| tvoss | duflu, can you invite me to a hangout again? | 11:19 |
| mlankhorst | RAOF: but I think adding exaMoveInPixmap is enough.. | 11:22 |
| mlankhorst | to NVSetScreenPixmap | 11:22 |
| RAOF | Oooh, yeah. That's even better! | 11:22 |
| tvoss | RAOF, ? | 11:23 |
| mlankhorst | RAOF: oh and add this to your .quiltrc | 11:23 |
| mlankhorst | QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-index" | 11:23 |
| RAOF | tvoss: mlankhorst's suggestion of moving the screen pixmap into VRAM in SetScreenPixmap. Rather than in nouveau_xmir_copy_to_mir. | 11:23 |
| RAOF | mlankhorst: OOOOH AWESOME. | 11:23 |
| mlankhorst | QUILT_NO_DIFF_INDEX=1 | 11:24 |
| mlankhorst | QUILT_NO_DIFF_TIMESTAMPS=1 | 11:24 |
| mlankhorst | and that :P | 11:24 |
| hikiko | alan_g|afk, I have an idea of something that might be wrong in the mir-on-mir design but I am not sure... | 11:24 |
| mlankhorst | hm I guess that one is more thorough | 11:24 |
| === alan_g|afk is now known as alan_g | ||
| tvoss | RAOF, I need xserver-xorg-common, xserver-xorg-core, xserver-xorg-xmir. Correct? | 11:28 |
| alan_g | hikiko: tell me | 11:28 |
| RAOF | tvoss: Correct. | 11:28 |
| RAOF | Technically you don't need xserver-xorg-common, but dpkg will complain if you don't have matching versions :) | 11:28 |
| tvoss | RAOF, exactly | 11:29 |
| duflu | Argh. Nested display stuff has broken bypass builds | 11:29 |
| tvoss | duflu, why is that? | 11:29 |
| alan_g | duflu: how? | 11:29 |
| duflu | Class changes... | 11:30 |
| duflu | Or has my system switched to gcc-4.7 by accident too? | 11:31 |
| tvoss | duflu, RAOF a lot better, but still not there | 11:32 |
| tvoss | duflu, can you invite me to a hangout? | 11:32 |
| duflu | What's a lot? | 11:32 |
| tvoss | duflu, I can log in to my session, and run glmark2 | 11:33 |
| hikiko | alan_g, I am not sure but as we have designed it we call the create_nested_display with a parameter that is the native display constructor which means that the native display constructor is called before the nested one and we initialize the gbm/drm etc before we have a nested platform and a connection etc but I am not sure if this is bad and if this has anything to do with the bug I have | 11:33 |
| hikiko | still investigating | 11:34 |
| duflu | tvoss: Lost you... ? | 11:34 |
| alan_g | hikiko: *if* we need to initialize gbm after connecting to the host then that just means we shouldn't do it in the NativeDisplay constructor. | 11:37 |
| hikiko | yes, that's what I am checking now | 11:37 |
| hikiko | if moving this part | 11:37 |
| hikiko | will solve the issues | 11:37 |
| RAOF | mlankhorst: Are you able to upload to qa-testing2 / push a merge request to github? | 11:38 |
| tvoss__ | duflu, can you call me again please? | 11:38 |
| tvoss__ | duflu, internet connection dropped | 11:38 |
| RAOF | mlankhorst: 9:30 says “you're too tired to do any real work, go to sleep” | 11:38 |
| hikiko | alan_g, the thing is if I add the gbm code to the nested platform then it won | 11:41 |
| hikiko | mmm nothing :) | 11:41 |
| alan_g | duflu: I see - you're changing the DisplayBuffer interface and that is implemented in nested. | 11:42 |
| * alan_g wishes folks would let code land instead of keeping it on branches for days on end | 11:43 | |
| alan_g | duflu: want me to MP a fix? | 11:44 |
| duflu | alan_g, please | 11:44 |
| mlankhorst | RAOF: well dno about the merge request stuff | 11:44 |
| alan_g | hikiko: ? | 11:46 |
| hikiko | nothing I fixed it :) | 11:47 |
| hikiko | I changed the drm.setup call and now I get an exception that mir tries to get a drm device it shouldnt but that's easier to fix :) | 11:48 |
| alan_g | hikiko: cool | 11:48 |
| alan_g | duflu: https://code.launchpad.net/~alan-griffiths/mir/prepare-nested-for-bypass/+merge/182610 | 11:58 |
| === alan_g is now known as alan_g|lunch | ||
| tvoss__ | mlankhorst, can you check if XMir on nouveau with qa-testing is working? | 12:09 |
| * duflu -> dinner | 12:18 | |
| tvoss__ | greyback, got a machine with an nvidia card? | 12:21 |
| greyback | tvoss__: I do, but at home (am in my office) | 12:21 |
| tvoss__ | greyback, ack | 12:21 |
| tvoss__ | anyone with an nvidia card around? | 12:22 |
| mlankhorst | tvoss__: oh seems to work btw | 12:22 |
| tvoss__ | mlankhorst, can you try x vs. xmir vs. xmir bypass with glmark2 please? | 12:24 |
| mlankhorst | how? :P | 12:25 |
| mlankhorst | not sure if it's going to be accurate either | 12:25 |
| tvoss__ | mlankhorst, well, it's a bit tedious, and involves installing and uninstalling | 12:26 |
| tvoss__ | mlankhorst, got time for that right now? or are you busy with other stuff? | 12:26 |
| mlankhorst | not that busy, waiting for some compiles | 12:26 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| tvoss__ | mlankhorst, do you know your way around the xmir radeon driver? | 12:41 |
| mlankhorst | sort of | 12:41 |
| === alan_g|lunch is now known as alan_g | ||
| mlankhorst | raof knows the pure X stuff a lot better than me, so for any deep architectural questions ask him, small things I can probably do :P | 12:42 |
| tvoss__ | mlankhorst, can I show you something on a hangout? I think you know how to fix it | 12:42 |
| kgunn | tvoss__: can i join for a status/data dump ? | 12:43 |
| tvoss__ | kgunn, sure | 12:43 |
| mlankhorst | word description would be easier I think, if it's small :P | 12:43 |
| tvoss__ | mlankhorst, well, with bypass, I'm pretty sure we have one stall frame coming from the X side | 12:43 |
| tvoss__ | mlankhorst, easier if I can just show you what I'm seeing | 12:43 |
| mlankhorst | hm raof would know this kind of thing a lot more than me, I probably don't know about that ;P | 12:44 |
| tvoss__ | mlankhorst, can you point me to the branch we are building from? | 12:45 |
| tvoss__ | mlankhorst, will look myself then | 12:45 |
| mlankhorst | raof's github, xf86-video-ati | 12:46 |
| mlankhorst | the ones in the archive are on debian | 12:46 |
| mlankhorst | http://anonscm.debian.org/gitweb/?p=pkg-xorg/driver/xserver-xorg-video-ati.git;a=shortlog;h=refs/heads/ubuntu | 12:47 |
| kgunn | tvoss__: appears to be branch foo | 12:48 |
| mlankhorst | the foo branch is for mm support | 12:49 |
| tvoss__ | mlankhorst, ack and thx | 12:53 |
| tvoss__ | olli, kgunn wanna jump on a hangout real quick? | 12:53 |
| === chihchun is now known as chihchun_afk | ||
| kgunn | tvoss__: good for me | 12:54 |
| olli | wfm, give me 2min | 12:55 |
| tvoss__ | kgunn, sent you an invite | 12:55 |
| tvoss__ | kgunn, can you open a hangout and invite me? | 12:55 |
| kgunn | tvoss__: :)) sure | 12:56 |
| === hikiko is now known as hikiko|lunch | ||
| duflu | Oh, hello USA. I must be in the wrong place | 13:26 |
| duflu | tvoss__, I'm finding new ways to make radeon do the same thing (noise without errors) but getting nowhere. Do you need me online? | 13:28 |
| duflu | kgunn^ ? | 13:29 |
| tvoss__ | duflu, not right now | 13:29 |
| tvoss__ | mlankhorst, do you have any idea what radeonShadowWindow is supposed to do? | 13:42 |
| mlankhorst | hold on let me check | 13:42 |
| mlankhorst | return a pointer to the window in shadowfb | 13:44 |
| === chihchun_afk is now known as chihchun | ||
| mlankhorst | shadowfb is just a b ig slab of memory encompassing all screens :) | 13:49 |
| * kgunn notes... kgunn^ didn't alert me...huh | 13:54 | |
| === hikiko|lunch is now known as hikiko | ||
| tvoss__ | mlankhorst, in radeon_kms.c | 14:07 |
| tvoss__ | mlankhorst, line 205: mind explaining to me the stride calculation? | 14:07 |
| tvoss__ | mlankhorst, that should be the stride in pixels, under the assumption that every pixel has got 8 byte, correct? | 14:09 |
| alan_g | hikiko: any progress towards nested GBM? | 14:10 |
| mlankhorst | tvoss__: no, *BITS*perpixel :P | 14:11 |
| mlankhorst | eg / 8 | 14:11 |
| hikiko | yes alan_g | 14:13 |
| hikiko | I found a bug | 14:13 |
| hikiko | https://code.launchpad.net/~hikiko/mir/mir.fix-drm-version/+merge/182653 | 14:13 |
| alan_g | hikiko: \o/ I'll take a look | 14:14 |
| hikiko | alan_g, I don't know if it's relevant to RAOF-duflu task but since it includes drm code I added them as reviewers | 14:15 |
| hikiko | (alf is on holidays :/) | 14:16 |
| === sam113101 is now known as sam113101_afk | ||
| mlankhorst | hikiko: considering freeing NULL is allowed, maybe you can come up with a more compat version? | 14:26 |
| hikiko | true :) I'll fix it | 14:28 |
| mlankhorst | eg if (!(drm_version = drmGetVersion(tmp_fd)) || !(drm_version->version_major < 1) || (drm_version->version_major == 1 && drm_version->version_minor < 4)) { drmFreeVersion(drm_version); } ; etc :P | 14:28 |
| hikiko | oh | 14:29 |
| mlankhorst | but I think that would fail, did you actually test it with drm as the only user? | 14:29 |
| hikiko | I thought you mean I free something that is null | 14:29 |
| hikiko | what do you mean by drm as the only user? | 14:30 |
| hikiko | I tested with mir_server_basic mir_server_shell and nested mir mlankhorst | 14:30 |
| hikiko | I just ran it and print the version numbers with and without the change | 14:31 |
| hikiko | without the change nested mir couldnt allocate any device with drm 1.6 | 14:31 |
| hikiko | do you think I have to test something more? | 14:32 |
| mlankhorst | I don't think they're identical, let me check.. | 14:33 |
| hikiko | ok | 14:34 |
| mlankhorst | drmGetVersion gets the driver version, which is dd_major/minor | 14:35 |
| hikiko | so I should get the di | 14:35 |
| hikiko | you are right | 14:35 |
| mlankhorst | and is different for each driver | 14:35 |
| hikiko | if we want the interface version | 14:36 |
| hikiko | why do we do it in a loop? | 14:36 |
| mlankhorst | a misguided attempt.. | 14:36 |
| mlankhorst | at fixing a race condition, but it does not work | 14:36 |
| hikiko | ok I'll delete the MP then and check more tomorrow because it's almost the end of my day :) | 14:37 |
| mlankhorst | hikiko: who passes the fd, or do you open it yourself? | 14:37 |
| mlankhorst | if the fd is passed to you, you could kill the check and assume the version is correct | 14:37 |
| mlankhorst | fixing nesting | 14:37 |
| hikiko | yes that's what I did but then I thought that for some reason we need that check | 14:38 |
| hikiko | so I tried to "fix" it | 14:38 |
| mlankhorst | it's only required if opening the fd yourself the first time | 14:38 |
| hikiko | that's what I think we do | 14:39 |
| === alan_g is now known as alan_g|tea | ||
| hikiko | tmp_fd = open(dev_path, O_RDWR, O_CLOEXEC); | 14:39 |
| hikiko | but the thing is | 14:40 |
| hikiko | we run this code *after* we open the device | 14:40 |
| hikiko | and if the version is not the desired | 14:40 |
| hikiko | we close the device | 14:40 |
| hikiko | is this correct? | 14:40 |
| mlankhorst | drmSetInterfaceVersion is not really required for mir, just assume it's correct or other things would have broken down sooner.. | 14:40 |
| hikiko | ok then I ll do an MP without any check at all | 14:42 |
| mlankhorst | sec, I had a nice check in nouveau for it | 14:42 |
| mlankhorst | drmModeGetResources(fd), if it returns NULL kms is not supported :P | 14:44 |
| mlankhorst | freed with drmModeFreeResources | 14:45 |
| hikiko | mlankhorst, I think we do that check elsewhere let me see | 14:49 |
| mlankhorst | probably but if you do that check first it should be good enough | 14:49 |
| hikiko | yes we do it at the beginning | 14:50 |
| hikiko | so I guess there's no need to do it again | 14:50 |
| mlankhorst | well I think it's required for getting bus name, but meh | 14:52 |
| === alan_g|tea is now known as alan_g | ||
| tvoss__ | mlankhorst, how am I supposed to test mm from qa-testing2? Seems like xserver-xorg-xmir in there is built against trunk | 14:54 |
| mlankhorst | tvoss__: dpkg -i --force :P | 14:55 |
| mlankhorst | it's what I did anyway | 14:55 |
| === sam113101_afk is now known as sam113101 | ||
| hikiko | http://manpages.ubuntu.com/manpages/raring/man3/drmModeGetResources.3.html mlankhorst it doesnt seem to give any information on the version | 14:58 |
| mlankhorst | hikiko: not really, but it only works if kms is available | 14:58 |
| mlankhorst | if (!drm_core_check_feature(dev, DRIVER_MODESET)) | 14:59 |
| mlankhorst | return -EINVAL; | 14:59 |
| hikiko | ok that check is done at mir initialization | 14:59 |
| hikiko | so we don't need to do it one more time | 14:59 |
| mlankhorst | yeah but I fear it might break things, so try testing at least once without plymouth | 14:59 |
| hikiko | I am not using plymouth as far as I know mlankhorst | 15:00 |
| hikiko | :s | 15:00 |
| hikiko | how can I check if I use plymouth? | 15:00 |
| mlankhorst | hikiko: it's part of the boot sequence | 15:01 |
| hikiko | if you run unity I guess? | 15:01 |
| mlankhorst | removing splash from linux cmdline options might be enough | 15:01 |
| mlankhorst | no, plymouth is the boot splash thing | 15:02 |
| hikiko | ah ok I have disabled the splash and everything the first day I installed ubuntu :D | 15:02 |
| hikiko | so I don't have plymouth | 15:02 |
| === chihchun is now known as chihchun_afk | ||
| === dholbach_ is now known as dholbach | ||
| === dholbach_ is now known as dholbach | ||
| === alex_abreu is now known as alex-abreu | ||
| === alan_g is now known as alan_g|EOD | ||
| === bschaefer_ is now known as bschaefer | ||
| kgunn | mlankhorst: you still on ? | 17:28 |
| tvoss__ | jibel, ping | 18:03 |
| jibel | tvoss__, pong | 18:07 |
| hoodoowoo | balloons: are you handy? I had a conversation with you yesterday, but I don't know if you're the one I should ping now (so please redirect as appropriate). I'm eager to respond to a question, but I need a follow up to this question: https://bugs.launchpad.net/unity-system-compositor/+bug/1217262/comments/3 | 18:12 |
| ubot5 | Launchpad bug 1217262 in Unity System Compositor ""sudo restart lightdm" always hangs/fails when using unity-system-compositor" [Undecided,Confirmed] | 18:12 |
| balloons | hoodoowoo, perhaps you had a different nick yesterday? :-p | 18:15 |
| hoodoowoo | balloons: heh, yes, different computer | 18:16 |
| hoodoowoo | /account/work rules, etc. | 18:16 |
| hoodoowoo | frothnicator | 18:16 |
| balloons | hoodoowoo, ok, I saw your thread | 18:19 |
| hoodoowoo | the joys of being a friendly tester but without the development background to have no questions ... | 18:20 |
| balloons | the ppa is frozen during testing, so you would have to build from trunk i'd guess.. or use the unstable ppa, if the team is building it and they think that is sane | 18:20 |
| balloons | http://unity.ubuntu.com/mir/building_source_for_pc.html | 18:20 |
| balloons | I'd defer to others in here on that | 18:21 |
| tvoss__ | mlankhorst, around? | 18:21 |
| hoodoowoo | balloons: noted. I'm now on the idea of automated testing. Have y'all thought about have a script as part of the PPA that testers can execute? I ask because though I tried to go through the test scenarios, I don't know exactly what the developers need to see. A script could extract these automatically. | 18:32 |
| balloons | hoodoowoo, there was an idea for a script that olli had, but time constraints led us here ;-) | 18:35 |
| hoodoowoo | roger. | 18:35 |
| hoodoowoo | balloons: from the outside, it seems like that script could be rather useful going forward. Otherwise, you get stupid testers like me who don't know what their doing. ;-) | 18:36 |
| balloons | hoodoowoo, :-) Just testing it and giving a thumbs up or thumbs down is important | 18:36 |
| balloons | automated tests are useful but they don't replace your experience, your machine, etc | 18:38 |
| hoodoowoo | well, then, thumbs up for the work in general (was impressed by the KMS integration, and auto-detection of the VGA cable). | 18:38 |
| balloons | and they aren't as smart as someone look at it | 18:38 |
| balloons | thanks for testing :-) | 18:39 |
| hoodoowoo | balloons: ah, I was looking at the fact that the devs (I assume y'all?) don't have access to every machine, but do know exactly what you need to see. On the other hand, various testers (like me), have machines and configurations that you don't have. Hence the idea for the test script that you write, but I run. But gotcha. Hope I was helpful. | 18:39 |
| hoodoowoo | ... thumbs up for work in general ... thumbs down for ability to complete some of the test scenarios, etc. | 18:40 |
| kgunn | hoodoowoo: thanks for testing....yeah, would've loved to get a bit more automated....but...clock killed us :) | 18:42 |
| balloons | I'm not a dev, so I won't take any credit.. but I'm sure they are very happy to receive your praise. | 18:42 |
| hoodoowoo | kgunn: roger. I don't know Canonical's internal time table, other than the stage freezes. But again, I stress "going forward". On that note, I'm out. Time for a tester to stop wasting your time. Thanks very much for the hard work. | 18:43 |
| === bschaefer_ is now known as bschaefer | ||
| tvoss__ | okay, it becomes interesting | 19:41 |
| === bschaefer is now known as bschaefer|lunch | ||
| === bschaefer|lunch is now known as bschaefer | ||
| bschaefer | kgunn, hey, got around to testing the u-s-c ppa and I get a black screen on boot :(, on ati 5670 | 22:59 |
| bschaefer | just with 1 monitor | 22:59 |
| * bschaefer didn't find anything to crazy about the logs | 22:59 | |
| kgunn | bschaefer: ok...so purge that....get to a saucy only...then download & force install the xserver & x-driver from ppa:/mir-team/qa-testing2(not apt-get) | 23:00 |
| kgunn | it should boot to single monitor fine | 23:01 |
| bschaefer | kgunn, alright Ill give that a try! | 23:01 |
| bschaefer | yeah, thats what i was wondering about... | 23:01 |
| bschaefer | kgunn, but mir doesn't seem to like my ati card atm anyway | 23:01 |
| bschaefer | when I try to run it natively | 23:01 |
| kgunn | yeah...the guys updated the drivers on the problem platforms | 23:01 |
| bschaefer | cool, but I think my problem is a bit different, its this gbm buffer failed to create (failing on a mmap) | 23:02 |
| bschaefer | which I need to sill dig into the radeon.ko stuff in the kernel... | 23:03 |
| bschaefer | kgunn, ill give it a try any way though, possibly something fixes it :) | 23:03 |
| bschaefer | kgunn, well single monitor works fine on saucy with xmir soo thats good, ill attempt MM now... | 23:16 |
| kgunn | drum roll (don't expect much) | 23:16 |
| bschaefer | haha, well we shall see :) | 23:17 |
| RAOF | Woo! | 23:18 |
| RAOF | What fixed it for youL | 23:18 |
| RAOF | ? | 23:18 |
| bschaefer | RAOF, hmm well im not sure why xmir is working ... but not native mir? | 23:19 |
| bschaefer | RAOF, as i've only ever had a problem with native mir | 23:19 |
| RAOF | usc doesn't try to allocate a cursor :) | 23:20 |
| bschaefer | RAOF, which is just a work around then :), cause I could get around that with native mir as well, but couldn't draw to a mir region... | 23:20 |
| bschaefer | ill have to find sometime to do some digging into that problem | 23:20 |
| bschaefer | got a fun error in x-0.log: X: ../../../../include/privates.h:123: dixGetPrivateAddr: Assertion `key->initialized' failed. | 23:33 |
| bschaefer | and screen was black | 23:33 |
| bschaefer | using xserver video ati, xserver from qa-testing2 | 23:34 |
| bschaefer | kgunn, ^ | 23:34 |
| RAOF | bschaefer: Oooh, urgh. | 23:35 |
| RAOF | Why is your machine so odd :) | 23:35 |
| bschaefer | idk...I usually use my laptop haha | 23:35 |
| bschaefer | but its fired atm... | 23:35 |
| bschaefer | RAOF, good for testing I suppose :) | 23:35 |
| RAOF | kgunn: Do you happen to know the status of nouveau MM? | 23:36 |
| bschaefer | or bad...depending on how you look at it | 23:36 |
| bschaefer | grabbing these *.debs from qa-testing2... possibly I should have installed something else? | 23:37 |
| bschaefer | xserver-common xserver-xorg-core xserver-xorg-video-ati xserver-xorg-xmir | 23:37 |
| RAOF | bschaefer: Oh, you need xserver-xorg-video-radeon | 23:43 |
| RAOF | bschaefer: xserver-xorg-video-ati is a wrapper that just calls -radeon. | 23:43 |
| bschaefer | RAOF, let me try that! | 23:45 |
| * bschaefer should have seen that based on the size of the ati one.. 25kb | 23:46 | |
| * bschaefer reboots | 23:47 | |
| bschaefer | awesome! Things seem to be working | 23:53 |
| bschaefer | have a nice 640x480 resolution on both | 23:53 |
| bschaefer | but no overdraw/underdraw on my hdmi monitor which is very nice | 23:53 |
| RAOF | I suspect that trying to change the resolution at this point will cause sorrow. | 23:54 |
| bschaefer | it wont even let me :), well I could force it...but | 23:55 |
| bschaefer | sorrow sounds bad | 23:55 |
| * bschaefer tires it anyway | 23:56 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!