Page 3 of 3 FirstFirst 123
Results 21 to 27 of 27

Thread: Linux GPU Drivers Prepare For Global Thermo-Nuclear War

  1. #21
    Join Date
    Sep 2011
    Posts
    292

    Default

    Quote Originally Posted by r3pek View Post
    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.

  2. #22
    Join Date
    May 2012
    Posts
    11

    Default

    Quote Originally Posted by robclark View Post
    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)

  3. #23
    Join Date
    Jul 2011
    Posts
    76

    Default

    Quote Originally Posted by robclark View Post
    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?

  4. #24
    Join Date
    Jan 2009
    Posts
    1,496

    Default

    Quote Originally Posted by robclark View Post
    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.

  5. #25
    Join Date
    Mar 2011
    Posts
    412

    Default

    Quote Originally Posted by r3pek View Post
    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.

  6. #26
    Join Date
    Sep 2011
    Posts
    292

    Default

    Quote Originally Posted by liam View Post
    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.

    Quote Originally Posted by liam View Post
    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 ;-)

    Quote Originally Posted by liam View Post
    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.

    Quote Originally Posted by liam View Post
    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).

  7. #27
    Join Date
    May 2012
    Posts
    11

    Default

    Quote Originally Posted by TAXI View Post
    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....

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •