What is a MirRenderSurface?

[Kevin DuBois]

On Fri, Sep 9, 2016 at 7:59 AM, Kevin DuBois <kevin.dubois at canonical.com>
wrote:

> Hmm, let me try to rephrase my point, I've lost track of what is in
> disagreement. We have a new thread "Does Mir have to pretend to be
> SurfaceFlinger" that we can talk about our relationship to drivers. So for
> further discussion, let's just assume we only have the Mesa platform.
>
> We have a few different technologies that we're supporting, or aim to
> support:
> EGL, Vulkan, software-rendering, multimedia decoders, multimedia encoders,
> nested-passthrough [1]
>
> The problem that I see with the current WIP header is that we assume for
> the user that they want to use EGL. When they get a MirRenderSurface, they
> can immediately plug that resource into the EGL driver. We then try to
> support the other technologies by transmuting transmute to other
> technologies from there. [2]
>
> If the answer to "What is a MirRenderSurface" is "A MirRenderSurface is
> the common interface that all technologies can use to upload pixel content
> to the mirserver" (and stop me here if this is not the right answer)
>

Synced up with Chris on IRC on this topic, and this seems to be the right
answer.

Internally, a MirRenderSurface is really just a mf::BufferStreamId. By
defining a EGL_KHR_platform_mir and adding appropriate hooks on the
driver-side for the various platforms, then we can pass the
mf::BufferStreamId to the drivers, and they can do what they want from
there.

The various non-egl technologies (software, encoders/decoders,
nested-passthrough) will take their mf::BufferStreamId and use
MirPresentationChain semantics on it.


> Then I think that we've already built this in MirPresentationChain.
>

And I'm wrong here because of eglstreams, which can't really use this idea.


>
> [1] nested-passthrough is really support for building a generic display
> server on top of the mirclient api.
> [2] We build MirBufferStream from MirRenderSurface here:
> http://bazaar.launchpad.net/~cemil-azizoglu/mir/mir-render-
> surface-v3/view/head:/src/include/client/mir_toolkit/
> mir_render_surface.h#L60
> and I'm going out on a limb to assume that there's a similar function for
> MirPresentationChain in the works.
>
> On Thu, Sep 8, 2016 at 2:18 PM, Cemil Azizoglu <
> cemil.azizoglu at canonical.com> wrote:
>
>>
>>> We quite literally cast MirRenderSurface* to EGLNativeWindowSurface in
>>> the current WIP:
>>> http://bazaar.launchpad.net/%7Ecemil-azizoglu/mir/mir-render
>>> -surface-v3/view/head:/playground/eglflash_render_surface.c#L112
>>>
>>
>> ​Perhaps, I should point out that our EGLNativeWindowType is not (and
>> cannot be) 'MirRenderSurface'. It's void*.​ This is because we (have to)
>> pretend to be other platforms (Android). That's what the cast is for. So if
>> we get technical, our EGLNativeWindowType is 'void*'. We are not painting
>> ourselves in a corner with a type that is not universal enough. So if Mir
>> appeared in an EGL header, it would have 'void*' not 'MirRenderSurface*' as
>> its native window type.
>>
>>
>>>
>>> This is why I'd much rather create an EGLNativeWindowType for the user
>>> than try to tell all the drivers out there that they have to adopt
>>> MirRenderSurface as their windowing type.
>>>
>>
>> I disagree. ​A platform absolutely has to define its own type, and the
>> drivers must adopt it. (Modulo the fact that we don't impose the
>> MirRenderSurface type as that because of the need to support Android.)
>>
>>
>>> Its mesa-specific thinking to think that we can define the window
>>> interface for every
>>>
>>
>> ​There is nothing Mesa-specific here. A platform defines the type and the
>> driver implementer adds support for it around that type. This is what every
>> platform has to do. (Except, for platforms that we pretend to be...like
>> Android).
>>
>> As you see I'm having to add 'except' to the statements above, because
>> Android is the exception, not Mesa.
>>
>> If we want to redefine our mesa interface, that's alright by me, and its
>>> even fine to define our mesa interface to /be/ the mir client interface.
>>> The problem is that we're trying to define our windowing type for platforms
>>> where we cannot define the windowing type.
>>>
>>
>> ​We absolutely can and should....except again for Android.​
>>
>>
>>
>>> It *does* have implications for how we implement MirRenderSurface on
>>>> Android; specifically, it means that MirRenderSurface needs to be a
>>>> SurfaceFlinger window. But even this doesn't tie Mir to EGL here - if
>>>> MirRenderSurface can masquerade as a SurfaceFlinger window it should also
>>>> work for Android Vulcan, which expects a SurfaceFlinger window, and *does*
>>>> also work for the HW video encoding, which expects a SurfaceFlinger window.
>>>>
>>>> 2) Its not obvious how to use this. The casting to an
>>>>> EGLNativeWindowType has to be pointed out in comment-headers, or gleaned
>>>>> from reading example code.
>>>>>
>>>>
>> Mir native window type is not in EGL headers yet. This "non-obvious-ness"
>> can easily be fixed when we add it in https://www.khronos.org/regist
>> ry/egl/api/EGL/eglplatform.h
>>  as a platform.​
>>
>>
>>
>>> 3) It puts MirPresentationChain and MirBufferStream as second-class
>>>>> citizens. Having to
>>>>>
>>>>
>> ​Who says that they should be first-class citizens? They are specific
>> implementations that are prone to change and deprecation. That said, the
>> fact that you can't use a MirRenderSurface without a backing of BS or PC
>> would still make them a "first class citizen" anyways.
>>
>> ​Regards,​
>>
>> ​Cemil​
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20160909/b69e1b12/attachment.html>