"Atomic Display Framework" Shown For Linux

[robclark]

Hi Rob,
If I understand you, currently, HWComposer isn't meeting android's needs, but the proposed ADF can currently do this. The problem with it, as you've said, is that you are adding a separate "non-standard" driver target, and that the only problem it solves (atomic updates) can be added to kms/drm.
So, the current situation is that everyone wants to move to atomic partial page updates, but that no one is currently shipping a solution, but there are the above paths forward?

Thanks/Liam

well, you can say that KMS isn't currently meeting HWComposer's needs for composition bypass. Not really anything to do w/ partial page updates (whatever that is). But if you are using hw overlays for some surfaces, you need to be able to keep that in sync w/ the gpu rendered layers so all the updates happen in sync. (And, as I've mentioned before, this is nothing specific to android, weston or any other wayland compositor using hw bypass (overlays) needs the same thing.) KMS doesn't currently give a solution for this, although there are proposals about how to do it it. (Ie. atomic/nuclear modeset/pageflip.) Part of the reason that KMS atomic support hasn't moved forward in the last ~6mo or so is that since I left TI (and no longer had access to sgx driver code), I haven't had a driver with which to implement atomic prototype. Now that I have msm drm/kms driver, I'm closer to being able to work on atomic again.. I still need to implement kms plane (overlay) support in msm, and a few other bits and pieces, but hopefully I should be returning to atomic support in kms in the near(ish) future.

[liam]

Hi Ericg, what android (and weston) are missing is the ability to atomically update the primary scanout layer on the same vsync as the overlay layers. It isn't really related to what keithp is doing w/ dri3/present. There are a couple other (mostly minor) things, but it all can and will be added to KMS (and there are already proposals about how to do the atomic pageflip/modeset parts of it). So, can KMS *today* handle android's (and weston's) needs.. no. But what is missing can be added.

Hi Rob,
If I understand you, currently, HWComposer isn't meeting android's needs, but the proposed ADF can currently do this. The problem with it, as you've said, is that you are adding a separate "non-standard" driver target, and that the only problem it solves (atomic updates) can be added to kms/drm.
So, the current situation is that everyone wants to move to atomic partial page updates, but that no one is currently shipping a solution, but there are the above paths forward?

Thanks/Liam

[Ericg]

I don't think anything that KMS *can't* do, otherwise I'd be advocating a new display/modesetting framework ;-)

Which is why I ask haha, technology and ideas advance, assumptions get proven untrue. I know KMS was designed pretty damn recently, but mobile has upset quite a few other trends and thought processes in computing already so I just wanted to make sure that KMS was still holding its own (as far as we know, at least).

[robclark]

No I knew it wasn't related to his work with DRI3/Present, it just got brought up during the Q&A Of his talk at the end and this debate just jogged my memory (unless that question really was related to DRI3 and i misunderstood the original question >_>).

There anything else that was brought up in the ADF debate so far that KMS currently doesn't (but COULD) do? Or perhaps more important... anything that was brought up that KMS CANT do?

I think the other major thing he mentioned was scenarios where you need to combine multiple crtc's (currently) to drive ultra high resolution displays. One approach that was brought up was whether this couldn't be accomplished by explicitly exposing primary planes, and using two planes + one crtc. I need to find out more about the hw to see if that makes sense (vs one crtc, multiple encoders, for example). I think there are a couple other features that where not explicitly called out, but could be accomplished via custom (or semi-standard) properties. I don't think anything that KMS *can't* do, otherwise I'd be advocating a new display/modesetting framework ;-)

[Ericg]

Hi Ericg, what android (and weston) are missing is the ability to atomically update the primary scanout layer on the same vsync as the overlay layers. It isn't really related to what keithp is doing w/ dri3/present. There are a couple other (mostly minor) things, but it all can and will be added to KMS (and there are already proposals about how to do the atomic pageflip/modeset parts of it). So, can KMS *today* handle android's (and weston's) needs.. no. But what is missing can be added.

No I knew it wasn't related to his work with DRI3/Present, it just got brought up during the Q&A Of his talk at the end and this debate just jogged my memory (unless that question really was related to DRI3 and i misunderstood the original question >_>).

There anything else that was brought up in the ADF debate so far that KMS currently doesn't (but COULD) do? Or perhaps more important... anything that was brought up that KMS CANT do?

[robclark]

Hey Rob, I read the mailinglist discussion this morning and maybe you can clear up a few things here... The proposer brought up the issue where under Android is needs a composer of some kind to not get tearing. This reminded me of Keith's talk at linux.conf.au from last year where he said we were losing the idea of a Vsync and were now going to partial-updates-of-the-screen as the new "norm" and the problems it would

It was implied in the mailing lists that KMS couldn't handle that (at least not right now) and that this ADF DID handle it. So I ask you, since you've been doing mobile work, architecturally... can KMS handle Android's needs, or has mobile development shown a crack in the foundations of KMS that would, in your opinion, warrant ADF?

Hi Ericg, what android (and weston) are missing is the ability to atomically update the primary scanout layer on the same vsync as the overlay layers. It isn't really related to what keithp is doing w/ dri3/present. There are a couple other (mostly minor) things, but it all can and will be added to KMS (and there are already proposals about how to do the atomic pageflip/modeset parts of it). So, can KMS *today* handle android's (and weston's) needs.. no. But what is missing can be added.

[Ericg]

Yup, weston can combine both. Of course, it really needs atomic pageflip to be perfect. But with atomic pageflip, you need to use a debug mode (which puts a translucent solid color overlay over what is drawn by the gpu) in order to tell the difference between what is gpu and what is hw overlay.

Hey Rob, I read the mailinglist discussion this morning and maybe you can clear up a few things here... The proposer brought up the issue where under Android is needs a composer of some kind to not get tearing. This reminded me of Keith's talk at linux.conf.au from last year where he said we were losing the idea of a Vsync and were now going to partial-updates-of-the-screen as the new "norm" and the problems it would

It was implied in the mailing lists that KMS couldn't handle that (at least not right now) and that this ADF DID handle it. So I ask you, since you've been doing mobile work, architecturally... can KMS handle Android's needs, or has mobile development shown a crack in the foundations of KMS that would, in your opinion, warrant ADF?

[robclark]

Interesting, I wasn't aware of that. I thought Weston can use OpenGL (ES) *or* overlays to do compositing, but noth both at the same time with runtime switching.

Yup, weston can combine both. Of course, it really needs atomic pageflip to be perfect. But with atomic pageflip, you need to use a debug mode (which puts a translucent solid color overlay over what is drawn by the gpu) in order to tell the difference between what is gpu and what is hw overlay.

Well, the standard thing sort of is HWComposer, isn't it? Although it does not cover all what KMS does, and is very removed from the Linux kernel standard interfaces.

right, and it doesn't do much good for anything that is not just a reskinned android (from graphics/display stack, point of view). So not particularly useful for me ;-)

[brent]

which weston does too ;-)

Interesting, I wasn't aware of that. I thought Weston can use OpenGL (ES) *or* overlays to do compositing, but noth both at the same time with runtime switching.

The big concern is that we end up with a bunch of devices out there with no fbdev or drm/kms driver, and instead a custom non-standard thing. This sort of divergence of android will potentially be a big problem for anyone who wants to put something other than android on their device.

Well, the standard thing sort of is HWComposer, isn't it? Although it does not cover all what KMS does, and is very removed from the Linux kernel standard interfaces.

[robclark]

This seems quite useful because Android's compositor mixes overlay and framebuffer rendering to improve performance and reduce power consumption.

which weston does too ;-)

The big concern is that we end up with a bunch of devices out there with no fbdev or drm/kms driver, and instead a custom non-standard thing. This sort of divergence of android will potentially be a big problem for anyone who wants to put something other than android on their device.