[03:40] <duflu> robert_ancell: Only coding style? :)
[03:41] <robert_ancell> duflu, that was the easy changes..
[03:42] <duflu> I expect more complaints. So many more that I would not recommend upstreaming right now
[03:42] <robert_ancell> duflu, I have a simplified branch that I'm trying to propose. It removes as much as possible to get a first step
[03:43] <duflu> robert_ancell: If you mean removing dri2 I would like to do that but it's critical to keep on desktop
[03:43] <robert_ancell> duflu, yeah, it's just software support
[03:43] <duflu> robert_ancell: Yeah please don't bother. Real desktops need the dri2 backend
[03:44] <robert_ancell> duflu, it's worth us having a smaller delta
[03:44] <duflu> robert_ancell: Well, if you're working in a separate branch then sure. Don't want to cripple the main one is all
[03:44] <robert_ancell> duflu, it's a separate branch
[03:45] <duflu> Ugh, same problems with Mesa. We really don't want to upstream egl-platform-mir with the open bugs we know about
[03:46] <duflu> Although that's less severe. Not really blocking I guess
[03:48] <RAOF> No, we don't want to upstream egl-platform-mir because we're about to completely rewrite it.
[03:48] <RAOF> From the interface up.
[03:50] <RAOF> Bugs are fine when submitting upstream; knowing that you're about to change the whole platform is not.
[03:51] <duflu> RAOF: That's worse. At least now it's stable and mature-ish. If we rewrite it we won't have the same confidence and definitely can't upstream any time soon
[03:51] <RAOF> We don't want to upstream mature code.
[03:51] <duflu> But maybe soon is not a requirement
[03:51] <RAOF> We want to upstream code that we *want* to mature.
[03:51] <RAOF> Ideally we should be upstreaming code *well* before its mature.
[03:51] <duflu> Fair point. Trunk isn't a place for maturation
[03:52] <RAOF> Also, upstreaming is highly likely to involve changes.
[03:52] <RAOF> Possibly significant ones.
[03:53] <RAOF> “Upstreaming” is almost never “here is this perfectly fine code ready to just drop without changes into your project”. Although, because we're awesome, that totally applies to the Mir EGL platform :)
[03:53] <duflu> RAOF: Can you add any more bugs detailing what's missing to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bugs?field.tag=egl-platform-mir
[03:54] <RAOF> Huh. Why do you want EGL_SWAP_BEHAVIOUR_PRESERVED?
[03:54] <RAOF> That's guaranteed to be slow.
[03:54] <duflu> RAOF: I know... but Xmir. Either that or single buffering
[03:55] <duflu> Xmir dri/glx copy sub-buffer stuff
[03:55] <RAOF> Why do you need it?
[03:55] <RAOF> Ah.
[03:55] <RAOF> That stupid idea :)
[03:55] <duflu> Yep. And the apps already exist
[03:55] <RAOF> You can implement it just as efficiently in Xmir, you know.
[03:56] <duflu> RAOF: I know and I tried. Failed so far for reasons... not entirely clear
[04:03] <duflu> Probably the same reasons why our src/dest FBOs are wrong (the stuttering)
[04:03] <duflu> At a guess
[04:04] <duflu> Single buffering would actually be most appropriate and have no performance penalty either
[04:05] <RAOF> Well, you can do that with MirPresentationChain.
[04:06] <RAOF> Indeed, that solves all your problems.
[04:06] <RAOF> Mostly.
[04:12] <duflu> It's not a massive issue right now as offenders are (confusingly) copying sub-buffers that are the whole window
[04:12] <TheKit> is Intel GPU currently not supported by Mir?
[04:12] <duflu> TheKit: Intel GPUs are better supported than any other :)
[04:12] <duflu> Have been for several years
[04:13] <TheKit> ah, ok, thanks
[04:13] <duflu> Hmm, actually that might be another Xmir bug
[04:21] <RAOF> MirPresentationChain would make it very nearly easy to implement DRI3.
[04:21] <RAOF> And then you could ignore all the DRI2 madness.
[04:24] <duflu> OK, sounds good.
[04:25] <RAOF> (We'd need to add a MirBuffer constructor that took an fd, but that's easy)
[04:25] <RAOF> *
[14:53] <alan_g> greyback: just to alert you, the miral-qt stuff needs some tweaks for yakkety (unity-shell-application) and for mir trunk (new DisplayConfiguration fields).