Announcement

Collapse
No announcement yet.

Kernel-Based X11 Server Claims 2x Performance Over X.Org

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

  • #21
    Originally posted by Kayden View Post
    ..leading to a security and compatibility nightmare...all for...what exactly?
    Once in a while there pops up a hacker or a group of hackers somewhere with really stupid utopic ideas, like "let's create a better MS-DOS and kill Win7 with it", "let's work on Hurd", "let's optimize the telegraph and try to outcompete the e-mail", "let's supercharge the AVI container and kill MKV".

    In this case another hacker (read idiot) decided to supercharge ancient technology (read crap) instead of being realistic - it's nothing new, there's lots of stupid people with lots of time, I should know I did stupid shit myself until I started to value my time.

    Comment


    • #22
      Its no supprise they can do this. X.org performance is absolutely horrendous in many cases.... and this is markedly worse the older the hardware you try to use it on. I would love to use something like this on my Transmetta Crusoe based latptop since it just doesn't have the oomph for X.org.

      That said this is completely worthless to me... I run custom kernels on my old machines so the kernels can be a tad slimmer/optimal. I like the idea of what they are doing but the execution is pretty poor imo. They've been sitting around with this tech for years... with little to show for it becauses they think that they just have to remain proprietary... well look at all the other failed proprietary X11 solutions there are still a few around but only because they are backed by hardware companies.

      Comment


      • #23
        Originally posted by siride View Post
        Have any of you naysayers considered that this might be a reasonable solution in certain scenarios? It uses less memory and is faster, so it may be good on low-end kiosk-type hardware. Security could be better, but with specific use cases, may not be that big of an issue.
        Low end Kiosk hardware have plenty of memory these days. Even a raspberry pi Type-B has 512MB and an Ouya ($99), has 1GB. In fact, most media players these days have at least 512MB of ram..

        And, there are already plenty of RAM-efficient X implementations (such as TinyX by Keith Packard), http://www.pps.univ-paris-diderot.fr...re/kdrive.html

        And, any application where speed would be beneficial, stability would be a factor (in a kiosk, kernel panics would be embarrassing). Sorry, but, I honestly cant think of many scenarios where performance is important, and RAM is important. It would also likely introduce significant security issues long term.


        Its a cool project & idea (I'm particularly interested simply because it tells us what a near perfect/efficient Xserver implementation could achieve), but, in practice, the disadvantages outweigh the benefits, especially since GOOD hardware is cheap.

        Andrew

        Comment


        • #24
          Watch carefully the video. Performance with standard X is worse, check. CPU utilization is higher, check. But have you noticed the absolute lack of tearing in X versus the tearfest with microXwin?

          Comment


          • #25
            Originally posted by dh04000 View Post
            Anyone want to build a distro on this for the lolz?
            I would actually love to see it in action.

            Comment


            • #26
              Congrats are in order... I didn't know someone could make a display server even more horribly stupid and misguided than Mir.

              Comment


              • #27
                I'm afraid this testing is not representative because we haven't seen the X.org config and we cannot tell how the X.org server renders things. Is it rendering on CPU or using VMware's XA state tracker passed to host via Gallium3D (where it very well may end up rendering in software anyway)?
                How will it behave on real hardware? I believe software rendering is faster than actual GPU driver on everything except Intel GPUs and maybe on Nvidia with proprietary driver.

                Also, vsync is an issue. All those lightweight compositors are cool and stuff but have no real use cases because of tearing. MicroXwin seems to be rinding the bandwagon of lightweight-but-useless things. Vsync may also account for the X.org overhead.

                Comment


                • #28
                  Useless

                  It is proprietary software so it is totally irrelevant and useless.
                  Also, we're getting Wayland which is superior.

                  They should contribute back upstreams.

                  Comment


                  • #29
                    Technically Wayland mandates compositing which this thing does not even support. So I guess if compositing is costly on given hardware, Wayland is not really applicable.

                    Comment


                    • #30
                      Originally posted by Auzy View Post
                      Definitely sounds like it is a step backwards for everything except performance. Also, f you upgrade your kernel, there is probably more likelihood that the Xserver will need a recompiled/to be patched to work again.

                      In contrast, on Windows with Nvidia (and maybe other drivers), and possibly Wayland, if the graphics driver crashes, it may be possible to recover automatically without a reboot / work-loss.

                      Technically, its easier to get better performance probably out of anything by sticking it into the kernel, but, with a good design, you could probably obtain similar performance from user-land anyway (along with better security).
                      Current Xorg+Radeon opensource driver, playing a networked GL game in composited desktop (Xorg) and receiving GPU bug (fixed) that results in GPU hang; the driver is capable to successfully recover in a way that the game continues to run flawlessly; even if multiple crashes follow.

                      Comment

                      Working...
                      X