Announcement

Collapse
No announcement yet.

Weston DRM Compositor Support Proposed For NVIDIA's TK1

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Weston DRM Compositor Support Proposed For NVIDIA's TK1

    Phoronix: Weston DRM Compositor Support Proposed For NVIDIA's TK1

    Support for running Wayland's Weston compositor directly off the DRM kernel driver for the NVIDIA Tegra K1 SoC found within the Jetson TK1 development board has been proposed for mainline Weston...

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

  • #2
    Does it all mean that we should expect tablets with TK1 and native Wayland running Plasma Active, Nemo, Sailfish and etc.?

    Comment


    • #3
      Weston DRM?

      I dont quite get it...
      Codethink rewrite Weston compositor, but instead of accessing KMS, it access DRM infrastructure?
      Whats that mean? Means that NVidia also can support Wayland in the same manner?
      Please, excuse my ignorance if Im saying too much non senses.

      Comment


      • #4
        Originally posted by rxonda View Post
        I dont quite get it...
        Codethink rewrite Weston compositor, but instead of accessing KMS, it access DRM infrastructure?
        Whats that mean? Means that NVidia also can support Wayland in the same manner?
        Please, excuse my ignorance if Im saying too much non senses.
        From having had a look at the patches, it seems they slightly modify the Weston DRM/KMS backend to support the mentioned device, which has to be handled in a different way than usual GPUs. I'm also not sure here, but I remember hearing that, while the GPU was under Nouveau territory, the display had to be handled with a different DRM driver - the Tegra. That may be the reason.

        As for the NVIDIA question, I believe not. NVIDIA's official driver does not use DRM nor KMS. Another backend for Weston would have to be developed to support whatever-NVIDIA-uses.

        Comment


        • #5
          Originally posted by kalrish View Post
          From having had a look at the patches, it seems they slightly modify the Weston DRM/KMS backend to support the mentioned device, which has to be handled in a different way than usual GPUs. I'm also not sure here, but I remember hearing that, while the GPU was under Nouveau territory, the display had to be handled with a different DRM driver - the Tegra. That may be the reason.

          As for the NVIDIA question, I believe not. NVIDIA's official driver does not use DRM nor KMS. Another backend for Weston would have to be developed to support whatever-NVIDIA-uses.
          thanks for the answer Kalrish.
          I googled for linux graphics stack and found out that NVidia cant implement a libdrm, unless they open sourced their code.

          Comment


          • #6
            is it about the nouveau driver? how much slower is this driver than the official nv driver? I hope if the official get weston support.

            Comment


            • #7
              How about MPG or H.264 acceleration on this box? E.g. VDPAU

              Comment


              • #8
                How about enclosures for this board?

                Comment


                • #9
                  Originally posted by rxonda View Post
                  thanks for the answer Kalrish.
                  I googled for linux graphics stack and found out that NVidia cant implement a libdrm, unless they open sourced their code.
                  NVidia (and fglrx) already have their own proprietary versions of libdrm/kms - so they just need to write a Wayland backend which can access it and then ship that with their drivers. It should all be fairly simple at this point, they just have to do it and then do all the regression testing necessary to make them feel comfortable supporting it.

                  Comment


                  • #10
                    Originally posted by smitty3268 View Post
                    NVidia (and fglrx) already have their own proprietary versions of libdrm/kms - so they just need to write a Wayland backend which can access it and then ship that with their drivers. It should all be fairly simple at this point, they just have to do it and then do all the regression testing necessary to make them feel comfortable supporting it.
                    Thanks for the answer Smitty.
                    But, when you mean "Wayland backend" you mean the compositor, right?
                    If so, NVidia would have to provide the nvidia-mutter-wayland, nvidia-efl-compositor, nvidia-kwin-compositor and so on?
                    And what about the optimus systems? It's up to the wayland client to choose the kms compositor or the nvidia compositor?
                    Im a bit confuse...

                    Comment


                    • #11
                      Originally posted by rxonda View Post
                      Thanks for the answer Smitty.
                      But, when you mean "Wayland backend" you mean the compositor, right?
                      If so, NVidia would have to provide the nvidia-mutter-wayland, nvidia-efl-compositor, nvidia-kwin-compositor and so on?
                      And what about the optimus systems? It's up to the wayland client to choose the kms compositor or the nvidia compositor?
                      Im a bit confuse...
                      Yes, he probably meant the Weston compositor. Wayland, by itself, is a protocol "for a compositor to talk to its clients", unrelated to OpenGL, EGL, DRM,... With Wayland, a client tells the compositor where is its buffer, and the compositor then puts it on the screen as convenient. The compositor, of course, must be able to access the buffer, which means that, if the client uses OpenGL, the compositor has to know how to handle OpenGL buffers.

                      And, yes. I guess that's why it isn't so "trivial" for the propietary drivers to support Wayland: they would either have to develop a backend for each compositor that supported their own private modesetting API, or switch to DRM/KMS. The later option, however, is not feasible, because of licenses, I think.

                      About your last question, I think you have confused the "platform" on which the compositor runs (DRM/KMS, Wayland, X11, propietary-modesetting-APIs,...), which is related to where the compositor's output is displayed and how the compositor takes input, and the GPU renderer that's used by clients. Optimus systems have two GPUs, and the ability to compute graphics with any of them in a per-application basis - for now, the user has to set an environment variable for the application to tell Mesa which GPU to use. A client could use any GPU to render its graphics; it would be up to the compositor to display its buffer on screen, using whatever means it had (DRM/KMS, Wayland, X11,...).

                      Comment


                      • #12
                        nVidia K1 has openmax api

                        Originally posted by dibal View Post
                        How about MPG or H.264 acceleration on this box? E.g. VDPAU
                        nVidia K1 has openMAX api
                        with working gstreamer
                        As far as I know VLC support openMAX too

                        Comment


                        • #13
                          Originally posted by kalrish View Post
                          Yes, he probably meant the Weston compositor. Wayland, by itself, is a protocol "for a compositor to talk to its clients", unrelated to OpenGL, EGL, DRM,... With Wayland, a client tells the compositor where is its buffer, and the compositor then puts it on the screen as convenient. The compositor, of course, must be able to access the buffer, which means that, if the client uses OpenGL, the compositor has to know how to handle OpenGL buffers.

                          And, yes. I guess that's why it isn't so "trivial" for the propietary drivers to support Wayland: they would either have to develop a backend for each compositor that supported their own private modesetting API, or switch to DRM/KMS. The later option, however, is not feasible, because of licenses, I think.

                          About your last question, I think you have confused the "platform" on which the compositor runs (DRM/KMS, Wayland, X11, propietary-modesetting-APIs,...), which is related to where the compositor's output is displayed and how the compositor takes input, and the GPU renderer that's used by clients. Optimus systems have two GPUs, and the ability to compute graphics with any of them in a per-application basis - for now, the user has to set an environment variable for the application to tell Mesa which GPU to use. A client could use any GPU to render its graphics; it would be up to the compositor to display its buffer on screen, using whatever means it had (DRM/KMS, Wayland, X11,...).
                          Thanks again Kalrish,
                          I always forgot that you have a device for produce the framebuffer's content and a device to decode and output the framebuffer's content to the screen itself.
                          So, Wayland's clients can talk EGL to the NVidia's proprietary blob to produce the framebuffer's content, but clients can't tell wayland to use NVidia's blob to output that framebuffer.

                          Comment


                          • #14
                            Originally posted by rxonda View Post
                            Thanks again Kalrish,
                            I always forgot that you have a device for produce the framebuffer's content and a device to decode and output the framebuffer's content to the screen itself.
                            So, Wayland's clients can talk EGL to the NVidia's proprietary blob to produce the framebuffer's content, but clients can't tell wayland to use NVidia's blob to output that framebuffer.
                            Well, applications (both X11 and Wayland clients) can't choose which EGL/OpenGL implementation they get; that's outside their scope. For instance, with Mesa, to choose an OpenGL renderer, the DRI_PRIME environment variable has to be set.
                            Code:
                            DRI_PRIME=1 very-heavy-game # render graphics with provider #1, which is more powerful
                            About your last question, if you're referring to changing the output of the compositor, there exists or is in its way a protocol called wl_randr or weston_randr, whose purpose is to allow changing monitor configuration (resolution, multi-monitor setups,...). However, if you're talking about switching the output, that is, changing from, say, being an X11 window to a Wayland surface, I think it isn't possible.

                            The example clients in the Weston tree are wells of information, so, if you know C, you could find some answers by hacking with Wayland.

                            Comment


                            • #15
                              Originally posted by kalrish View Post
                              Well, applications (both X11 and Wayland clients) can't choose which EGL/OpenGL implementation they get; that's outside their scope. For instance, with Mesa, to choose an OpenGL renderer, the DRI_PRIME environment variable has to be set.
                              Code:
                              DRI_PRIME=1 very-heavy-game # render graphics with provider #1, which is more powerful
                              About your last question, if you're referring to changing the output of the compositor, there exists or is in its way a protocol called wl_randr or weston_randr, whose purpose is to allow changing monitor configuration (resolution, multi-monitor setups,...). However, if you're talking about switching the output, that is, changing from, say, being an X11 window to a Wayland surface, I think it isn't possible.

                              The example clients in the Weston tree are wells of information, so, if you know C, you could find some answers by hacking with Wayland.
                              Thanks Kalrish,
                              I will do that.

                              Comment

                              Working...
                              X