Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 46

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

  1. #21
    Join Date
    May 2012
    Posts
    946

    Default

    Quote 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.

  2. #22
    Join Date
    Jan 2009
    Posts
    303

    Default

    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.

  3. #23
    Join Date
    Jun 2013
    Posts
    12

    Default

    Quote 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

  4. #24
    Join Date
    Feb 2008
    Location
    Santiago, Chile
    Posts
    263

    Default

    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?

  5. #25

    Default

    Quote 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.

  6. #26
    Join Date
    Jan 2013
    Posts
    1,462

    Default

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

  7. #27
    Join Date
    Jan 2012
    Location
    Moscow
    Posts
    61

    Default

    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.

  8. #28
    Join Date
    Dec 2011
    Posts
    2,195

    Default 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.

  9. #29
    Join Date
    Jan 2012
    Location
    Moscow
    Posts
    61

    Default

    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.

  10. #30
    Join Date
    Jan 2013
    Posts
    1,090

    Default

    Quote 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.

Posting Permissions

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