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

  • rxonda
    replied
    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.

    Leave a comment:


  • kalrish
    replied
    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.

    Leave a comment:


  • rxonda
    replied
    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.

    Leave a comment:


  • miskol
    replied
    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

    Leave a comment:


  • kalrish
    replied
    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,...).

    Leave a comment:


  • rxonda
    replied
    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...

    Leave a comment:


  • smitty3268
    replied
    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.

    Leave a comment:


  • dibal
    replied
    How about enclosures for this board?

    Leave a comment:


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

    Leave a comment:

Working...
X