Linux GPU Drivers Prepare For Global Thermo-Nuclear War

[robclark]

This is all cool and all but as long as the KMS symbols are _GPL only, it sucks (at least for nvidia card owners, open source radeon drivers are good, can't say the same for nouveau).

Overwhelming majority of the symbols in drivers/gpu/drm are EXPORT_SYMBOL(). Offhand, I don't know the story behind the few EXPORT_SYMBOL_GPL() but there are not many.

That said, an out-of-tree drm/kms driver doesn't seem like a terribly good idea.

[r3pek]

Overwhelming majority of the symbols in drivers/gpu/drm are EXPORT_SYMBOL(). Offhand, I don't know the story behind the few EXPORT_SYMBOL_GPL() but there are not many.

That said, an out-of-tree drm/kms driver doesn't seem like a terribly good idea.

It's actually on the DMA-BUF side of things mostly I think (http://www.phoronix.com/scan.php?pag...tem&px=MTIwNDI)
But AFAIU, it has some ramifications to KMS and that's mostly why binary blobs don't do KMS (feel free to point me out if I'm wrong)

[Guest]

fwiw, it is mostly an issue with hw composition (ie. using overlays/planes to bypass gpu for some windows/surfaces). I'm not sure how much it will benefit traditional desktop gpus. It will definitely help anyone with overlays (ie. pretty much all SoC's, plus at least some intel), so we can actually use that hw in the display controller to offload the gpu, helping performance (reducing latency) and power.

Basically, wayland (central compositor) lets us start taking advantage of these extra features in hw.. but now we need a kernel API that lets us update them all in sync so you don't see things in the wrong place (ie. remember moving windows with video back in the old Xv / non-compositing window mgr days, when the video and window position would get momentarily out of sync as you moved the window?)

On the desktop side of things, probably atomic modeset is a bigger deal. For example, some generations of intel can drive 3 displays but only with 2 plls, so two of the displays have to "match". Various generations of nv/amd have various similar/weird multi-display contraints. Atomic will give us a way to tell userspace which combinations of resolutions will work together so UI can dtrt. Much easier than trying to explain the magic sequence of xrandr commands to disable then re-enable all three displays in the correct sequence with a set of resolutions that will work across them.

So, with these kernel changes, changing resolution and enabling multiple monitors should be more reliable and flicker-free, right?

Is the code ready for testing yet? Which branch do I need to compile to test this?

[liam]

At least the way it is shaping up, adding atomic support should be relatively easy for most drm drivers. At least most of the mobile display controllers I have seen have "GO" bits (ie. they let you program a bunch of registers to setup next frame, but changes don't take effect until you write some flush/go bit(s) in some register).. which makes what we want to do rather easy from a hw perspective. So far, it seems the hardest SoC driver to implement this for will be i915 :-P

His reasoning is partially correct, in that the changes in drm core are not so straightforward. (And it is more than just atomic.. we've been busy adding drm_bridge, drm_panel, etc to better handle complex video paths, share encoder and panel drivers, etc.) And getting all these changes upstream takes some time. But I think the end result will be better, easier to implement for drivers, more shared code, etc. And it won't require throwing away all the good parts of KMS (modesetting helpers, hotplug infrastructure, edid (incl. all the quirks for buggy edids), etc, etc, like you would w/ ADF.

My impression from the outside looking in, when it comes to doing things with existing driver infrastructure the google android folks tend to look at it for 3 minutes, then give up and invent their own thing. I suppose it is easier in the short term. And it isn't google who has to deal with writing two different display drivers for their SoC now :-(

Wait, is ams expected to actually speedup mode setting so much that we can expect GO bit enabled display controllers to be able to change the modes within a single vblank, or is this more about sending all properties over with the single ioctl (presumably after setting GO) like pekka mentioned (which I thought more page flip related)?
The Intel chips don't support that bit? Or is it that until ams you didn't have a way to synchronize things so they just didn't bother using it (yeah, I don't believe that either)? If they don't use GO registers they'll just have to do the same thing as non mobile GPUs? It's not as nice but they've got the manpower, clearly, to support marinating their own gallium-free driver
So, was ams necessary in order to decouple kms from the drm model of a display chain or was it orthogonal? Is this going to cause api breakage?
Regarding goog, that was my impression as well. I still remember the binder/dbus...misunderstandings. There's obviously not a culture of "upstream first" like with RH, but they're not quite hostile to the community. My guess is that it's at least partially due to the managerial pressure, especially as android became a more important part of their business.

[V10lator]

as long as the KMS symbols are _GPL only, it sucks

There is no such thing as a _GPL symbol in the kernels license, so using none _GPL only doesn't protect you from copyright laws. Nvidia just tries to go the "safe route" by using such symbols only but just because nobody (no copyright holder) cares doesn't mean it's any more legal than if they would use _GPL symbols.
Other than that even if _GPL symbols would be covered by the license removing the _GPL from one symbol would require the same as changing the kernels license: Every copyright holder must agree. As that won't be the case (and some copyright holders might even be death or unreachable for various reasons) it would never happen.

[robclark]

Wait, is ams expected to actually speedup mode setting so much that we can expect GO bit enabled display controllers to be able to change the modes within a single vblank, or is this more about sending all properties over with the single ioctl (presumably after setting GO) like pekka mentioned (which I thought more page flip related)?

well, GO bit stuff is more for "pageflip" updates than "modeset" updates.. there has been some talk about possibly allowing for asynchronous modeset to speed up boot/resume. Which wouldn't make modeset any faster but could at least parallize things. Might be worth looking into one of these days once the rest of the basics are in place.

The Intel chips don't support that bit? Or is it that until ams you didn't have a way to synchronize things so they just didn't bother using it (yeah, I don't believe that either)? If they don't use GO registers they'll just have to do the same thing as non mobile GPUs? It's not as nice but they've got the manpower, clearly, to support marinating their own gallium-free driver

afaiu they do not have something like 'GO' bit. They have some other constraints / shared resources to manage as well, so that isn't the only thing. Some of the complexity may also just be that intel are the ones who have pushed their hw capabilities a lot further compared to the other drivers ;-)

So, was ams necessary in order to decouple kms from the drm model of a display chain or was it orthogonal? Is this going to cause api breakage?

That is more about the universal (primary/cursor) plane stuff (exposing crtc scanout and cursors via plane API). It is backwards compatible between userspace and kernel. Backwards compat is a non-negotiable requirement.

Regarding goog, that was my impression as well. I still remember the binder/dbus...misunderstandings. There's obviously not a culture of "upstream first" like with RH, but they're not quite hostile to the community. My guess is that it's at least partially due to the managerial pressure, especially as android became a more important part of their business.

Yeah, not hostile to community, ofc. But they just don't seem to put much effort into community/upstream. I understand product schedule in consumer devices does not wait for upstream. But you'd think a company with their resources could maybe hire one or two people to help work on android upstreaming. Afaiu all that work is done by folks outside of google (ie, linaro, etc).

[r3pek]

There is no such thing as a _GPL symbol in the kernels license, so using none _GPL only doesn't protect you from copyright laws. Nvidia just tries to go the "safe route" by using such symbols only but just because nobody (no copyright holder) cares doesn't mean it's any more legal than if they would use _GPL symbols.
Other than that even if _GPL symbols would be covered by the license removing the _GPL from one symbol would require the same as changing the kernels license: Every copyright holder must agree. As that won't be the case (and some copyright holders might even be death or unreachable for various reasons) it would never happen.

I know that. All kernel code is GPL'd, _GPL or not. Still, they would use it if it wasn't for that....