mir's internal renderer + other shells
Daniel van Vugt
daniel.van.vugt at canonical.com
Tue Apr 1 01:29:58 UTC 2014
I think this is essentially what I was trying to get at in the
"Compositor / Renderer" thread on 21 March. So we're on the same page.
It's worth noting that the concepts:
DisplayBufferCompositor
DefaultDisplayBufferCompositor
Renderer
GLRenderer
are all specific to MultithreadedCompositor. If a shell replaces
"the_compositor()" then it is replacing all of those classes in a single
blow. That's exactly what qml-demo-shell does so it doesn't know or care
what a DisplayBufferCompositor or Renderer are. Although, the price
qml-demo-shell pays for that is lower performance (no bypass) and no
multi-monitor support, so it's obviously not a permanent solution.
I agree completely if these are to remain useful abstractions, they
should become useful to Unity too. And that is at the back of my mind
(despite what it looks like).
- Daniel
On 01/04/14 06:04, Kevin DuBois wrote:
> I too think we should steer clear of a toolkit, and can assume people
> want to write their own GL and GLSL. I'm concerned though that we don't
> have an obvious location that we want people to plug in new rendering
> engines though.
>
> My big concern right now is that I don't see us rallying around the same
> Renderer/Compositor interfaces in order to plug the QtSg and (USC/demo
> shells). We're evolving, but divergently. It needs to be obvious what we
> want the new-shell-writer to replace. Right now, its not obvious, and we
> have the demo shell evolving along the lines of "expand mc::GLRenderer"
> and the QtSG stuff evolving more along the lines of "replace the
> DefaultDisplayBufferCompositor".
>
> Our examples/ directory is where the new-shell-writer would probably
> look first to learn how to do something cool, so we should point them in
> the direction we want them to go. There's a split between what we
> recommend in our examples, and what we're actually planning on using for
> the unity8 shell.
>
> The best way I can see to rectify this is to allow for people to rewrite
> the DefaultDisplayBufferCompositor, meaning we have a USC compositor
> implementation, a fancy demo shell implementation, and a QtSG
> implemenation. [1]
> We are object-oriented after all :) This lets us arrange our interfaces
> flexibly, we have a the different needs between the three.
>
> The next step for driving at the triad of implementations would just be to
> 1) Continue making DefaultDisplayBufferCompositor smaller and smaller
> (which I'm working on anyways to get overlays all hooked up)
> 2) split the GLRenderer somehow, instead of having one implementation
> with different internal parts being overridden. We make it two
> implementations, or we make it a cobbling together of different useful
> GL parts (I prefer the two implementations, we are object oriented. The
> end result here would be that mc::Renderer would get buried into the
> private headers, or be a header private to examples/. [2] This also has
> the added benefit that we don't have latent demo code in USC's call path.
>
> Cheers
> Kevin
>
> [1] Last I've heard about QtSG, DefaultDisplayBufferCompositor is the
> place that needs replacement). Correct me if things have changed :)
> [2] IIRC, historically, mc::Renderer was originally just to test the
> interactions between the compositor and the GL code. At some point it
> was made public and overridable, and became a much bigger/more important
> interface than we originally intended
>
>
> On Mon, Mar 31, 2014 at 6:38 AM, Kevin Gunn <kevin.gunn at canonical.com
> <mailto:kevin.gunn at canonical.com>> wrote:
>
>
>
>
> On Sun, Mar 30, 2014 at 9:06 PM, Daniel van Vugt
> <daniel.van.vugt at canonical.com
> <mailto:daniel.van.vugt at canonical.com>> wrote:
>
> This topic sounds like what I've been working on - moving the
> pieces around so that anything and everyone can play nicely with
> Mir. It's really an evolution toward reaching some common
> interface that Unity8/Qt and other pure OpenGL shells could use
> simultaneously.
>
> On kdub's points:
>
>
> > Does it mean that you don't have to write GL? [1]
> At the moment, yes you have to use GL or a toolkit which uses GL
> (Qt). However we are aiming to not even be dependent on GL if
> something else was available.
>
>
> by this do you simply mean the interface between Compositor &
> Renderer will be devoid of GL ?
> and the "something else" could be HWC i suppose ?...but even then,
> we assume GL as a fallback.
>
>
> > Does it mean that you don't have to write common GL
> algorithms? (eg,
> > tesselation, drawing, texture stuff)
> You can use the built-in drawing methods of GLRenderer (which
> themselves are evolving and subject to change). In the purest
> sense I think all of GLRenderer would become shell-specific.
> However that's not likely to happen while it still contains
> important boiler-plate logic. I'm slowly working to try and push
> boiler-plate into Mir and GL-bling into the shell.
>
>
> yeah, but +1 to what you describe. this actually allows gets that
> nice split of "convenience" for those that just need to use
> boiler-plate....and then "flexibility" for those that want to go all
> bling-y.
>
>
> > Does it mean that we give some pretty basic, simple
> interfaces that you can plug your stuff in?
> Yes, working on that re-"Compositor / Renderer". But I'm
> conscious that we don't want to build a toolkit. We're not
> building a "toolkit" in the normal sense but a set of interfaces
> for building shells.
>
> agreed, and i think its good to restate this. I think the creep of
> "toolkit into mir" is something we have to be on guard for.
>
>
> > Does it mean that when mir's compositor is overridden
> libmirserver.so
> > does not touch GL state at all?
> Ideally that should be possible. GL should just be an option
> anyway. Although the GL context is tangled up in the
> DisplayBuffer design right now.
>
> - Daniel
>
>
>
> On 29/03/14 03:48, Kevin DuBois wrote:
>
> Hello mir folks,
>
> We have 4 users of mir in-flight right now:
> 1) unity8 (driving at using QtSG)
> 2) USC (using the default mir implementation)
> 3) the demo shell (using the default mir implementation, and
> overriding
> its functionality in some areas)
> 4) the demo server (using the default mir animation)
>
> I mostly want to think about 2, 3 and 4 at this email
> discussion, that
> is, how do we arrange for sharing the default mir compositor
> implementation with USC and the demo shell. (unity8 has its
> own ball
> rolling already with an effective fork of the mir
> implementation)
>
> Now USC is obviously important because its in production,
> and the demo
> shell is important too, because its making sure its easy to
> write a
> sensible shell from scratch.
>
> Now, 'easy to write a sensible shell from scratch' is a bit
> vague, we
> should hash out what that means in this email chain.
>
> Does it mean that you don't have to write GL? [1]
> Does it mean that you don't have to write common GL
> algorithms? (eg,
> tesselation, drawing, texture stuff)
> Does it mean that we give some pretty basic, simple
> interfaces that you
> can plug your stuff in?
> Does it mean that when mir's compositor is overridden
> libmirserver.so
> does not touch GL state at all?
>
> kdub's opinion:
> //begin
> Its kinda tricky to think about; I like to approach it from the
> perspective of someone who doesn't know much about mir's
> internals, but
> has written a GL game/program before and wants to try their
> hand at
> writing a shell, or perhaps someone with toolkit/GL
> experience who wants
> to try a shell. [2]
>
> Given this, what I would want is mir to handle all the junk
> about
> clients, ipc, buffer swapping, etc. I'd just want to write
> GL; my own
> shaders, my own algorithms, my own GL state. [3] I wouldn't
> really be
> interested in using mir's GL stuff (triangle tesselation?
> bah! I want to
> write zany jigsaw tessellations and name the vertex attrib
> what I want
> to name it!)
>
> So given this, I'd like to see the demo shell forking the
> USC rendering
> functionality at some point, not sharing very much at all.
> QtSG/unity8
> is already forking the rendering functionality. This kinda
> drives
> against the 'never duplicate code' instinct, but the 3rd
> party shell
> writer is probably /only/ interested in duplicating code.
>
> It also makes the USC/production default renderer
> implementation the
> lightest possible implementation one can get away with,
> while having the
> demo shell's implementation showing a more high power
> implementation.
>
> So maybe, we have to have 2 vertex/fragment shaders in the
> mir code
> base, as opposed to one set like we have now, but in the
> end, our
> interfaces are better for it, and the 3rd party implementers
> have an
> easier time bootstrapping too.
> //end
>
> Interested to hear other people's thoughts, I'd guess
> there's a few
> different 'how easy is easy?" answers floating around.
> Striking the
> right balance will get other shell rolling easily, without
> us having to
> support the myriad things in the USC implementation.
>
> Cheers,
> Kevin
>
> [1] we already have an approach aimed at the minimal-GL with
> unity8/QtSG/qml effort
> [2] There are of course lots of advanced coders who might be
> interested
> (like a phone vendor), but I tend to hearken back to my
> compiz fusion
> days https://www.youtube.com/watch?__v=9GtMu5afIKg
> <https://www.youtube.com/watch?v=9GtMu5afIKg>
> [3] Obviously, this is idealistic, the serious shell coder will
> eventually wade into more detail about the internal
> interactions of mir
> and its scene. But what gets people started coding is seeing
> its simple
> to plug your own stuff in there and see it hit the screen.
>
>
>
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com <mailto:Mir-devel at lists.ubuntu.com>
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/__mailman/listinfo/mir-devel
> <https://lists.ubuntu.com/mailman/listinfo/mir-devel>
>
>
>
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com <mailto:Mir-devel at lists.ubuntu.com>
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>
>
More information about the Mir-devel
mailing list