Universal Plane Support Set For Linux 3.15

[phoronix]

Phoronix: Universal Plane Support Set For Linux 3.15

Landing a few hours ago into the drm-next code-base for merger into the Linux 3.15 kernel in the days ahead is the universal/primary plane support for the Direct Rendering Manager drivers...

http://www.phoronix.com/vr.php?view=MTY1MTg

[ArthurBorsboom]

What benefit do users have by having universal/primary plane support?

Is it that drivers can be easier developed, so therefore new drivers are quicker available?
Does it have performance or stability benefits? Code reduction, thus a smaller (and maybe faster) kernel/OS?

[robclark]

What benefit do users have by having universal/primary plane support?

Is it that drivers can be easier developed, so therefore new drivers are quicker available?
Does it have performance or stability benefits? Code reduction, thus a smaller (and maybe faster) kernel/OS?

It allows to expose some additional flexibility that is not uncommon in a lot of display controller blocks (especially in SoC's).. at least two or three drivers were already using a kms plane internally with their kms crtc implementation. Now with primary-plane, that internal private plane object that the crtc was using is decoupled so that userspace can have more flexibility and control it directly (rather than indirectly via the more limited crtc apis).

For example, previously if you were using a kms plane (hw overlay) to show video nearly fullscreen (with black bars), you would need to have both the crtc primary plane enabled (just scanning in a black buffer), plus a 2nd overlay plane for the video. With this, you could in theory get away with just a single plane enabled (and black fill pattern). So, a power savings. You could potentially also use that now spare plane for some other purpose (like OSD menu), which would not have been possible before.

The main thing is we wanted to get primary-plane in before atomic, to avoid later supporting an intermediate kernel API state (atomic with scanout fb directly attached to crtc, as opposed to connected via primary plane). It is just to avoid needing some backward-compat glue later. I don't really think userspace will use primary planes much via the current (soon to be legacy) API. It's really all in preparation for atomic which I'm *hoping* that we manage to land in 3.16.

This plus atomic and a few other things going on are part of an effort to bring drm/kms up to date with the requirements of a hw-composited UI like android or a weston. KMS was originally designed back when display controllers where much simpler things. In particular, it initially didn't even support overlays (planes). But display controllers (in at least i915 and the arm SoC's) are growing increasingly sophisticated as people (re)realize the performance/power benefits of offloading UI composition to the display controller. It's led to a situation where android feels the need to introduce ADF, rather than standardizing on drm/kms. But I feel that is throwing out the baby with the bathwater. KMS does a lot of things right (a lot of the modesetting parts, ADF nearly completely ignores). Not to mention that in non-android linux (where backwards compatibility is actually a thing), we can't just throw away existing drivers and subsystems and start from scratch.

Btw, Matt Roper from Intel has been the main one doing the work on primary plane. I rebased his patches on drm-next and hosted it in my git tree for Matt to give something that Airlie could pull (only because Matt didn't have a public git tree set up anywhere yet).

[ArthurBorsboom]

Thank you so much for taking the time to explain this.
I am an advanced Linux user, but not quite yet a kernel developer, therefore I understand about half of your explanation.
Please bare with me.

I try to understand what the benefits are for the Linux user in the short and long term.
For what I have understood, these are the possible benefits.

• Performance improvements and/or power consumption reductions by
  creating the possibility to use less planes for the same task;
  creating the possibility to let the graphics card do more work for user interfaces.

• New features are being made possible by
  providing more control to user space which gives new possibilities to application developers.

• New features are quicker available by
  preventing kernel developers to spend time on creating and maintaining backward-compatibility;
  preventing splitting up Linux kernel and Android developers.

Is the above list correct? If not, would you mind to explain what is incorrect or missing?

I am sorry to ask, but what do you mean by 'atomic' and what are the benefits of that to the Linux user?

[robclark]

Thank you so much for taking the time to explain this.
I am an advanced Linux user, but not quite yet a kernel developer, therefore I understand about half of your explanation.
Please bare with me.

I try to understand what the benefits are for the Linux user in the short and long term.
For what I have understood, these are the possible benefits.

• Performance improvements and/or power consumption reductions by
  creating the possibility to use less planes for the same task;
  creating the possibility to let the graphics card do more work for user interfaces.

yes.. although note that some of these features I don't expect to see much use under x11. It is more targeted at wayland compositors, and surfaceflinger.

(short version: the xserver/windowmanager split makes it more difficult to use hw composition effectively)

• New features are being made possible by
  providing more control to user space which gives new possibilities to application developers.

well, the primary target is giving new possibilities to the compositor. But I suppose indirectly, yes.

• New features are quicker available by
  preventing kernel developers to spend time on creating and maintaining backward-compatibility;
  preventing splitting up Linux kernel and Android developers.

Is the above list correct? If not, would you mind to explain what is incorrect or missing?

I expect most of the backwards-compat would be handled by drm core and it wouldn't end up being *that* big of a deal. But I wasn't really comfortable to propose merging two big things at the same time (atomic and primary-planes), and doing atomic first and primary-planes after seemed a bit silly.

I am sorry to ask, but what do you mean by 'atomic' and what are the benefits of that to the Linux user?

I think it's probably been covered on phoronix before, but I'm too lazy to find it. But tl;dr: atomic lets the compositor update multiple layers "atomically" in the same vblank. So if you are using hw composition for some window, and moving it around, it doesn't get out of sync with the rest of the UI. (Do you remember when Xv used to actually use hw overlays, back before gl window managers like compiz and gnome-shell... and you'd move a window around?)