Page 11 of 14 FirstFirst ... 910111213 ... LastLast
Results 101 to 110 of 136

Thread: Mark Shuttleworth Declares Mir A Performance Win

  1. #101
    Join Date
    Nov 2008
    Location
    Old Europe
    Posts
    910

    Default

    Also

    Mir will work with proprietary drivers, because thatís just practical reality.
    Not sure if he refers to the Android drivers or if this implies that AMD/NVidia
    have (internally) promised to deliver required EGL capable blobs...

  2. #102
    Join Date
    Jul 2013
    Location
    USA
    Posts
    715

    Default

    Quote Originally Posted by entropy View Post
    Also



    Not sure if he refers to the Android drivers or if this implies that AMD/NVidia
    have (internally) promised to deliver required EGL capable blobs...
    NVidia promised to deliver required EGL capable blobs around 1 or 2 years ago...

  3. #103
    Join Date
    Nov 2008
    Location
    Old Europe
    Posts
    910

    Default

    Quote Originally Posted by LinuxGamer View Post
    NVidia promised to deliver required EGL capable blobs around 1 or 2 years ago...
    I should've googled that.

    BTW, what is actually required for a blob to support Wayland/Mir?

    I know that Wayland additionally requires the EGL buffer age extension.

    But apart from that it looks like the AMD blob supports EGL for quite some time:
    http://developer.amd.com/tools-and-s...opengl-es-sdk/

    So, what's missing here?

  4. #104
    Join Date
    Jul 2013
    Location
    USA
    Posts
    715

    Lightbulb

    Quote Originally Posted by entropy View Post
    I should've googled that.

    BTW, what is actually required for a blob to support Wayland/Mir?

    I know that Wayland additionally requires the EGL buffer age extension.

    But apart from that it looks like the AMD blob supports EGL for quite some time:
    http://developer.amd.com/tools-and-s...opengl-es-sdk/

    So, what's missing here?
    thats an SDK, Wayland need's KMS (EPIC WIN if it get's supported) and Supported EGL extension's in the Driver

    http://wayland.freedesktop.org

  5. #105
    Join Date
    Aug 2012
    Posts
    454

    Default

    Quote Originally Posted by Yedor View Post
    From that same Shuttleworth blog comment, that bloddy PR non-answer answer:

    QUESTION Brian: Is there a plan to go closed source at some point? Its clear that seems to be within the realm of possibility.
    ANSWER Marc: Mir is open source – GPL – just like pretty much everything we do.
    How is this a PR answer?

    Some Guy: Linus, will the kernel go closed source at some point? (By god, the money he'd make if he did.)
    Linus: The kernel is open source - GPL - just like pretty much everything we do.

    Seems reasonable to me...... I think its PR only in your head.

    Plus, how is GPL software going closed? AFAIK, the license prevents already GPL'd software from changing to non-GPL licenses.

  6. #106
    Join Date
    Aug 2012
    Posts
    454

    Default

    Quote Originally Posted by BO$$ View Post
    Just your usual Canonical haters want to reinterpret everything.
    Reminds me of FOX news watchers.

  7. #107
    Join Date
    Jul 2012
    Posts
    739

    Default

    Quote Originally Posted by LinuxGamer View Post
    thats an SDK, Wayland need's KMS (EPIC WIN if it get's supported) and Supported EGL extension's in the Driver

    http://wayland.freedesktop.org
    Wayland does not require KMS. You can use other types of modesetting.

  8. #108
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote Originally Posted by dh04000 View Post
    How is this a PR answer?

    Some Guy: Linus, will the kernel go closed source at some point? (By god, the money he'd make if he did.)
    Linus: The kernel is open source - GPL - just like pretty much everything we do.

    Seems reasonable to me...... I think its PR only in your head.

    Plus, how is GPL software going closed? AFAIK, the license prevents already GPL'd software from changing to non-GPL licenses.
    Have to agree with that. However, Canonical (and only Canonical, except in the case all of the contributors agree on that) can sublicense, which is additionally release the software under another license, but this is not retroactive. The consequence would be that they can make closed derivatives, while nobody else can (the only difference with having it under the MIT license is that the latter allows anyone to do the same thing).

  9. #109
    Join Date
    Jul 2013
    Posts
    1

    Default Does anyone here even read the source code??

    There my post says it. But lets educate everyone here a little.

    Firstly, Wayland is only a protocol, nothing more really. It specifies, essentially, the following:

    1) How a program (a wayland client) requests offscreen buffers from the compositor
    2) various messages to say "present" this buffer
    3) some message protocol for events

    There is the reference compositor Weston. Now how those buffers are created and how they are drawn to is a function of the system, the integration and the compositor. Nothing more. Over on the RasberryPi, there is a compositor that uses the display controller to present the window contents (i.e not even using OpenGL or OpenGL ES). What is key for a Wayland based system to get performance is that the buffers written to are the buffers being presented. A dumb, slow as molasses, implementation will make the buffers generic shared memory and the compositor would use glTexSubimage2D to upload the image data to GL. That is terrible and one of the worst ways to get the job done, and yet it is done in some places. Shudders.

    Over on freedesktop.org there is an EGL extension written up for this buffer image sharing, note that the extension is not in the OpenGL ES registry though. This is not really a big deal, but what is important is this: any system using Wayland needs to have a means to allocate cross-process image buffers where a client (program) writes to it and the server (Wayland compositor) draws them. That is it. Nothing more.

    On the issue of Mir. The main stink for Canonical for Wayland was event handling. In a nutshell, Wayland did not have a rich enough system for user events. If you take a look at http://wayland.freedesktop.org/docs/html/, you will see that Wayland's event system is lacking and not particularly rich. There was a long blab on the Wiki of Mir about the why, it was not a NIH issue, there were serious concerns with respect to input.

    Going on, I noticed a comment about OpenGL being too linked/reliant on X to use with Wayland. Epically wrong. The main issue is creating a GL context. Now, for X, one uses GLX (gee). However, EGL has a provision to create OpenGL (not just OpenGL ES) contexts as well.

    The post about memory consumption was a waste of bytes. Indeed, those numbers are so much tinier than how much RAM is on the system as to not worth noting; the real issue to look at is how much bandwidth does each system consume. That is where the real action with respect to performance is. On embedded systems, X has worked. Indeed both the N900 and N9 from Nokia have X. I do not think it was a good idea, but it did work and memory consumption was kept reasonable. The main stinks for X are the following:

    1) making good X.org drivers is a royal pain. Getting accelerated compositing working is another royal pain.
    2) X does lots of things, and in truth using X to get anything done is painful. It's input APIs suck, it's window API's suck, it has lots of API's that all suck to use
    3) and yet, most application draw all their content themselves (be it via Cairo, Qt, whatever) and do not use Xlib to draw anything. All they want is a surface to which to draw and a way to grab events

    Looking at the above, one sees that all one needs is something to allocate image buffers, notify on what buffer to present and to receive events. Wayland did the first fine, but the events just are not rich enough.

    At any rate, on desktop, the only player in Linux land that can get us out of X is Canonical. They are the only ones with enough clout to convince IHV's (namely NVIDIA and AMD/ATI) to make it possible to create GL contexts and such without X. Wayland has been around for several years now, and still nothing has been made for it that is used a great deal. My thinking of the why is essentially those folks are not in a position to push it to the correct people at the correct IHV's. There is a place for Wayland on embedded devices, but in truth for mobile, Android and iOS rule it... Maemo/Meego/Tizen look pathetic... there are some Tizen devices out there, but I am not impressed with Tizen at all.

  10. #110
    Join Date
    Jul 2013
    Location
    USA
    Posts
    715

    Default

    Quote Originally Posted by blackout23 View Post
    Wayland does not require KMS. You can use other types of modesetting.
    Like?
    you talking about Xwayland?

    DRM output (without X) requires Kernel Mode Setting (KMS) and the page flip ioctl
    http://wayland.freedesktop.org/building.html

Posting Permissions

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