| === OutOfControl is now known as benonsoftware | ||
| alf__ | greyback: Good morning! | 10:01 |
|---|---|---|
| greyback | alf__: hey | 10:02 |
| alf__ | greyback: I am looking at the QtSG source code and I have some questions. | 10:02 |
| greyback | alf__: shoot | 10:02 |
| alf__ | greyback: I see that each rendering thread (in qsgthreadedrenderloop.cpp) creates its own gl context, possibly shared with another context. How does this interact with the context provided by the DisplayBuffers? | 10:03 |
| alf__ | greyback: i.e. at some point there is "gl = new QOpenGLContext();", how do we manage to tell Qt to use our context instead? Or do we do something different? | 10:06 |
| greyback | alf__: where do you see it actually creating the context? It should be asking the QPA (platform abstraction plugin) to create the gl context for it | 10:06 |
| alf__ | greyback: ah, so QOpenGLContext() ends up calling our QPA to do the actual context creation? | 10:06 |
| greyback | alf__: right, I implemented QPlatformOpenGLContext, which should on construction creates & wraps a gl context, exporting swapBuffers & makeCurrent and other methods | 10:09 |
| greyback | what I actually do I just wrap the DisplayBuffer object from mir, knowing that the DB created the gl context, and connecting the makeCurrent and swapBuffers methods | 10:10 |
| alf__ | greyback: hmm, how will that work with multiple display buffers? How could we know which DisplayBuffer to use when we get a call to create a context? | 10:12 |
| greyback | alf__: Each QWindow can have its own gl context. I wrap each DisplayBuffer with QOpenGlContext, and can ensure that each QOpenGlContext is used by a different QWindow. Then I'm hoping that Qt will just do the right thing | 10:16 |
| greyback | since it has a render thread per QWindow | 10:17 |
| greyback | that is what I need to check | 10:17 |
| alf__ | greyback: Since QOpenGLContext(); is called without any arguments, how can we know which QWindow this context is targeted for and hence which display buffer to use? | 10:19 |
| alf__ | greyback: unless there is some strict ordering that we need to follow so that QWindows match with the correct QPA gl contexts, but this seems very fragile... | 10:20 |
| greyback | alf__: I agree it's not ideal, this is abusing Qt's window-based architecture a bit. But see that QSGRenderThread calls gl->makeCurrent(window), there is specifies which QWindow, and thus which DisplayBuffer to use | 10:27 |
| greyback | alf__: QSGRenderThread::run I mean | 10:28 |
| alf__ | greyback: ok, so the QOpenGLContext we provide has access to all the DisplayBuffers and can decide which one at makeCurrent() time? Yeah, that could work. | 10:29 |
| greyback | alf__: right | 10:30 |
| alf__ | greyback: Do you have that code somewhere? I want to take a look to find the best point to integrate the request for context properties (depth, stencil etc). | 10:32 |
| greyback | alf__: lp:~unity-team/+junk/qpa-mirserver/ and the code you want is in src/platforms/mirserver | 10:33 |
| alf__ | greyback: great, thanks! | 10:33 |
| greyback | alf__: if you want to build to test, you need the unity-api branch mentioned in https://docs.google.com/a/canonical.com/document/d/1IiHBDIW_e0qnGt-po1D2z5HJKrNhBwh6pdILeEN2sgA/edit?usp=sharing | 10:34 |
| alf__ | greyback: do you know if this works on the desktop? | 10:35 |
| greyback | alf__: it did with Qt5.0, I've not tested with 5.2. Gimme 10 mins & I'll check | 10:36 |
| * greyback has a secondary computer at hand now, won't be cursing Mir locking his VT so much any more :) | 10:37 | |
| alf__ | greyback: btw, one thing I forgot to mention yesterday, is that between a Compositor::stop() and the next Compositor::start() the DisplayBuffers may have been invalidated, so we need to take this into account when stoping/restarting the Qt renderers. | 10:42 |
| greyback | alf__: makes sense. I've not considered that at all yet | 10:42 |
| alf__ | greyback: (i.e. you can't assume any DisplayBuffer references will be valid, because of display reconfiguration changes) | 10:43 |
| alf__ | greyback: ok | 10:43 |
| greyback | alf__: what I was hoping to test was, when Compositor::stop() called, I send a "hidden" event to all QWindows, which will block the next rendering pass. However am worried that's already too late | 10:44 |
| greyback | alf__: how does that work in Mir? Could a DisplayBuffer be invalidated /while/ the renderer is working? | 10:45 |
| alf__ | greyback: No, when we get a display config changed event, we first stop() the compositor and then proceed with dealing with reconfiguration. | 10:47 |
| === alan_g is now known as alan_g|lunch | ||
| kgunn | alf__: greyback ...i read your discussion about about matching the DB & QWindow gl context...one wonder on my part wrt multimonitor...how would that work if you wanted your QWindow to span 2 moniters? would scene just help track & toggle that QWindows glcontext mapping ? | 13:38 |
| greyback | kgunn: not possible with Qt, it relies on 1 GL context per window | 13:39 |
| alf__ | kgunn: it's one qwindow per output, like we have one DisplayBuffer per output | 13:39 |
| alf__ | kgunn: greyback: but multiple qwindows can render parts of the same scenegraph, right? Or would we have separate SGs? | 13:40 |
| greyback | alf__: I think both options are available to us | 13:41 |
| kgunn | ah so there'd be a way around | 13:41 |
| greyback | yeah, visually I think it possible to have a spanned desktop with the 2 windows | 13:41 |
| kgunn | and greyback do i understand it right that QWindow is effectively a Qt app window surface ( not == screen) | 13:41 |
| greyback | is something I need to prototype | 13:41 |
| greyback | kgunn: right, usually QWindow is just that, a window. However I'm tricking it that a window corresponds to a Mir DisplayBuffer | 13:42 |
| alf__ | greyback: @extended desktop, it should be fine (and perhaps transparent), since we deal in virtual coordinates. We only need to say that this windows displays the scenegraph viewport x,y@w,h | 13:43 |
| alf__ | greyback: (hopefully qt can do that :)) | 13:44 |
| greyback | alf__: honestly I'm not sure it does. If there's 1 scenegraph tree for a root window, you can tag a subtree to be the SG for a child window, but then that subtree ignored by the root window's renderer | 13:48 |
| kgunn | ack the QWindow foolery to DB | 13:48 |
| greyback | alf__: spreading 1 scene over 2+ windows is not really an application use-case | 13:48 |
| greyback | alf__: I need to see if working around it is easy, else can change the scenegraph renderer (which will be done anyway for HWC support) | 13:49 |
| greyback | hmm, just had flashback to the unity2d days, when were were essentially doing this very thing | 13:51 |
| alf__ | greyback: hmm, some SG elements may need to be used multiple times (e.g. a surface between monitors). It would be ideal to have a single SG and just render with different clip borders for different outputs. | 13:52 |
| greyback | alf__: yep | 13:52 |
| greyback | most definitely | 13:52 |
| alf__ | greyback: I spy QSGClipNode which seems relevant | 13:54 |
| === alan_g|lunch is now known as alan_g | ||
| greyback | alf__: that clips its subtree | 14:00 |
| greyback | why need to clip the border? | 14:00 |
| greyback | if you render outside the viewport of the current gl context, that doesn't appear on another display, does it? | 14:01 |
| alf__ | greyback: no | 14:01 |
| === dandrader is now known as dandrader|afk | ||
| alf__ | greyback: gl does primitive clipping, but it would be even better to not process irrelevant nodes (= unnecessary GL vertices) at all, so that's clipping at the SG level. But I guess we can worry about this later. | 14:13 |
| greyback | alf__: it's something I need to check up on, but I suspect Qt's renderer doesn't do any such checking | 14:14 |
| greyback | which means for 1 SG with N multiple monitors, lots of gl calls are doing stuff off screen N-1 times | 14:14 |
| === dandrader|afk is now known as dandrader | ||
| anpok | I thought qt has a copy step that transfers the qml model into a scene graph to be consumed by the renderer thread for each(?) frame. | 14:29 |
| greyback | anpok: it does | 14:32 |
| anpok | I mean in that case there would be one qml scene, and two renderer scenes.. | 14:32 |
| anpok | or n renderer scenes.. | 14:32 |
| anpok | I wanted to say that we might be able to limit the scene at that copy step | 14:33 |
| greyback | possible | 14:33 |
| alf__ | anpok: greyback: copying the qml model to scene graph for each frame sounds expensive :/ Is there some caching (or other optimization) going on? | 14:35 |
| greyback | but that copy step is very much 1 qml scene -> 1 scenegraph afaik | 14:35 |
| greyback | alf__: yes, it doesn't copy each time, it updates only the dirty nodes for each frame | 14:35 |
| anpok | ah so I understood you correctly you were discussing qml scene -> scenegraph -> n renderers on the same screengraph but with clip nodes | 14:41 |
| greyback | anpok: right, that's one option | 14:41 |
| anpok | alf__: the issues they tried to solve was the js model taking too much time to settle and having too large variance in the settle time to have steady frame rate.. | 14:44 |
| anpok | I think they thought about providing some concept of "global properties" that could change more frequently than the js model to do those animations that shall be updated every frame | 14:45 |
| greyback | anpok: alf__ Qt apps have a rendering thread, and a GUI thread. The QML engine (including the JS engine) live in the GUI thread. QML animations with *Animation{} are controlled by the GUI thread, as QML wants to know the progress of that animation. This isn't ideal as the GUI thread might block the rendering thread during animations. But Qt5.2 introduced *Animator{} which runs animations on the render thread | 14:50 |
| greyback | with the sacrifice that QML doesn't know the progress of that animation | 14:50 |
| greyback | so it's a fire and forget kind of animation | 14:50 |
| greyback | we're not using it anywhere yet, and will be interesting to see what improvement it makes, if any. | 14:51 |
| greyback | another place where GUI thread can block the rendering thread is if there's intensive javascript running, and that's generally bad coding | 14:52 |
| anpok | hm but it would only block updates there... not really block | 14:52 |
| kgunn | greyback: so for anything with input sync i'd think you'd want "Animation" GUI...and where you don't care about input, that'd be "Animator" | 14:52 |
| kgunn | ? | 14:52 |
| greyback | kgunn: right | 14:52 |
| greyback | anpok: if updates block, then the SG tree is not considered dirty, so the renderer does not do a pass for that frame | 14:53 |
| kgunn | SG not considered dirty for that app...right?...could be others not blocked | 14:54 |
| greyback | yes, just that app | 14:54 |
| mterry | Can I get a Mir expert's eyes on https://code.launchpad.net/~mterry/unity-system-compositor/switch-after-buffers/+merge/211776 ? I think I do some sketchy stuff | 15:21 |
| alf__ | greyback: looking at miropenglcontext.cpp ... are we sure we don't need the EGL display an config? The m_format variable is set using these. | 15:24 |
| === alan_g is now known as alan_g|tea | ||
| greyback | alf__: yeah, you're right, it's needed. And that's not possible to get from the current context with egl* methods? | 15:26 |
| alf__ | greyback: it's possible if there is a current egl context, but I don't think there is at that point in the constructor. | 15:27 |
| greyback | alf__: fair point | 15:27 |
| alf__ | greyback: However, we could get an EGL context from the mg::Display and make that current temporarily to get all the info. | 15:28 |
| alf__ | greyback: mg::Display::create_gl_context() | 15:29 |
| greyback | alf__: I'm in your hands here, whatever you think best. | 15:29 |
| greyback | I don't see why that wouldn't work anyway | 15:30 |
| alf__ | greyback: yeah, let's start with that and see how it goes | 15:31 |
| alf__ | :) | 15:31 |
| greyback | alf__: ok | 15:31 |
| === alan_g|tea is now known as alan_g | ||
| kdub | alan_g, I'm considering making a std::list of renderables from the scene to unblock some of the DefaultDisplayCompositor/hwc stuff | 15:35 |
| kdub | and I'm debating whether to add a method to mc::Scene, or to use the filters/operators to generate the list and leave mc::Scene alone | 15:36 |
| kdub | I sort of prefer the 2nd approach, but was wondering what you thought before embarking on that | 15:36 |
| alan_g | kdub: My preference is to pass the selection criteria to scene and for it to pass the collection to a supplied object. | 15:38 |
| alan_g | And rework the "lock the world" stuff into that. | 15:39 |
| kdub | so pass a collection of filters in, and then have the scene generate a the list based on that... so the second approach more or less | 15:40 |
| alan_g | "second approach" from "vision" doc. Yes | 15:40 |
| kdub | and also, I plan on it being a snapshot of the scene, eg, having a mg::Renderable(ms::BasicSurface const&) constructor | 15:40 |
| alan_g | after talking to gerry I think it will work better than "option 1" | 15:41 |
| alan_g | Slicing the BasicSurface? Why? | 15:42 |
| alan_g | I was thinking along the lines of std::copy_if(surfaces.begin(), surfaces.end(), selector, back_insert_iterator(renderables)) | 15:43 |
| kdub | looking through code, that could work too | 15:45 |
| kdub | I guess my main point here is that it would be a snapshot by copying rather than a reference into the surfaces like it is now | 15:46 |
| alan_g | Basically we need to lock the "scene" during the copy, but the renderables(surfaces) can be accessed concurrently | 15:46 |
| alan_g | Can't we just copy the shared_ptrs? | 15:46 |
| kdub | I guess I just like locking, copying, and not worrying about the changes to the scene that happen between the copy and the render | 15:49 |
| kdub | although, it might be simpler to just give the reference, even if that means some surfaces have that extra sliver of time to update their information whereas other surfaces would be accessed sooner and would have to wait til the next frame | 15:50 |
| alan_g | Yes, I'm just questioning how deep the copy has to be. | 15:50 |
| kdub | well, I guess I'll see in when I go to do the work... the first pass though will at least minimize how long the vector that holds all the surfaces is locked | 15:52 |
| Saviq | hey guys, is there an ABI break between trunk and devel atm? | 15:53 |
| alan_g | the buffer swapper can be shared. What else do you use? | 15:54 |
| alan_g | Saviq: I have to check. .. | 15:54 |
| Saviq | alan_g, not if it takes more than a minute or two, we'll know soon enough | 15:55 |
| alan_g | Saviq: I don't see anything that's a definite "yes" | 15:56 |
| Saviq | alan_g, ok, good enough | 15:56 |
| Saviq | kgunn, ↑ | 15:56 |
| mterry | kgunn, also https://code.launchpad.net/~mterry/unity-system-compositor/switch-after-buffers/+merge/211776 will likely need a careful Mir eye. I think I do some sketchy stuff in it. If you know someone that has spare cycles | 16:03 |
| kgunn | mterry: ack...i see its a nice small code change :) | 16:04 |
| mterry | kgunn, of course :) | 16:05 |
| kdub | I've seen two failures on TestClientInput in CI lately (with branches far away from input), has anyone else seen this? | 16:27 |
| kdub | looks like a racy leak maybe | 16:29 |
| alan_g | kdub: I've not noticed it - but that doesn't mean it doesn't happen | 16:44 |
| kdub | there's a bug tracking it now if anyone else sees the same thing | 16:44 |
| kdub | https://bugs.launchpad.net/mir/+bug/1295231 | 16:44 |
| ubot5 | Ubuntu bug 1295231 in Mir "TestClientInput memory leak in CI" [Medium,New] | 16:45 |
| === dandrader is now known as dandrader|lunch | ||
| alan_g | Tried reproducing locally? (Sometimes needs use_debflags, valgrind and patience) | 16:45 |
| === om26er_ is now known as om26er | ||
| kgunn | mterry: definitely a few breaks on that branch...sorry, getting hit from multiple sides, got really distracted...as i said, i'll gen up the mp's add them to that silo/reconfig and we'll build... | 17:13 |
| === dandrader|lunch is now known as dandrader | ||
| === alan_g is now known as alan_g|EOD | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| Saviq | hey folks, can't cross-build Mir in a trusty chroot: bug #1295364 | 20:55 |
| ubot5 | bug 1295364 in Mir "Mir fails to cross-build a deb package" [Undecided,New] https://launchpad.net/bugs/1295364 | 20:55 |
| kdub | Saviq, confirmed that bug, I've seen that too | 21:09 |
| Saviq | kdub, thanks | 21:17 |
| === seb128_ is now known as seb128 | ||
| === marrusl is now known as marrusl_afk | ||
| === marrusl_afk is now known as marrusl | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!