Announcement

Collapse
No announcement yet.

OpenChrome DRM Still Being Ported To Newer Kernel, Lengthy Process

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

  • OpenChrome DRM Still Being Ported To Newer Kernel, Lengthy Process

    Phoronix: OpenChrome DRM Still Being Ported To Newer Kernel, Lengthy Process

    Self-appointed OpenChrome project maintainer Kevin Brace who for the past year or so has been single-handedly managing the open-source VIA "OpenChrome" graphics driver code-base, is still working towards getting the work-in-progress Direct Rendering Manager (DRM) driver working on newer builds of the Linux kernel...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I am full of doubts.
    What was the meaning of branch development 3.19. For years not patched kernel.

    What? Looking for distribution with the nopae kernel. Mercy. It takes 2 minutes to compile. As if I started looking for a current distribution with support under amd k6-2 (without cmov, sse), I would never have found one. And it works fine with the latest kernel on it 4.13.

    Comment


    • #3
      I still use the OpenChrome DDX 0.3.3 version. Because it works as it should.
      One of its first changes, it completely freezes the system.

      Maybe he started working again with 0.6.0 version. Only flaps again, because after running X server disappears the contents of the console.
      When you switch CTRL-ALT-F[0-7], you see a beautiful black screen. You do not see any system messages.

      I have tested openchrome DRM-3.19. I do not have any clear benefit from it, and the amount of deficiency is enormous. Did not work:
      -resume from suspend.
      -Xv,
      -sloooooowly moving pixmaps,
      -and more, more.

      Comment


      • #4
        I still use some VIA HW and I'll welcome any progress there. And e.g. Gentoo ("it's all about choice") will work nicely with older 32bit sytems. With or without SSE, CMOV, SSE2, PAE and whatsoever. Might be different if one wants to compile a recent Firefox - I don't know if this said SSE2 dependecy is hardcoded or not and if it is maybe "just" used for HTML video decoding acceleration or something.

        (about that 3.19 kernel: I guess he just took some recent version at the time he started to work on OpenChrome.)

        And by the way: Neither xf86-video-via nor UniChrome nor OpenChrome have ever been really feature complete or totally well-working. These are partially reverse engineered drivers and they always had a smaller team than e.g. nouveau and less specs than e.g. Radeon devs (which moreover are mostly AMD employees).
        Stop TCPA, stupid software patents and corrupt politicians!

        Comment


        • #5
          Strange that major distributions at the expense of 1% of users, reduced the performance and functionality of the rest. Is - Gentoo, linux from scratch, etc.

          A lot of software is no longer working on x86_32 i[45]86 class processors.
          Toolchain (gcc, glibc) still support - i386. Kernel - minimum i486.

          The last version of chromium that worked on k6-2 was 25, mayby 27 (cold start 90-120s).
          WebkitGTK, last version of that worked on i586 - 1.9.3. Newer required cmov (686).
          Luajit - required cmov.
          Go - required cmov and mmx. Gcc Go - working on 486.

          Coming back to openchrome DRM - next-4.13. I tried compiling, on gcc 7.1.1 ended up failing.

          Comment


          • #6
            Originally posted by Adarion View Post
            And by the way: Neither xf86-video-via nor UniChrome nor OpenChrome have ever been really feature complete or totally well-working. These are partially reverse engineered drivers and they always had a smaller team than e.g. nouveau and less specs than e.g. Radeon devs (which moreover are mostly AMD employees).
            Well, unichrome is where modesetting was born. It was where i realized that there is logic to what everyone said was "can't be done, only the big black biocks knows". It was less reverse engineered and more distilled out of the crap that was there. And while i got told i was full of shit, it is where the base (and badly implemented) ideas from RandR1.2 came from, and that eventually got badly turned into KMS, which then needed another decade to get anywhere, with a whole new generation of developers. The latter basically started with Nokia dying and my whole team running off to intel, and Ville starting atomic modesetting.

            Also, unichrome, and the knowledge and insights gained form doing it, is how we beat ATI and got code out at all... and docs, and whatnot, quite some of that has been reverted sadly, again, as usual, *sigh*.

            But then, the openchrome guys forked away from me, as they didn't agree with me and my apparently useless modesetting trip. I placed a nice big rant on unichrome.sf.net, back in 2005, stating "Sure, this driver currently doesn't have a few glittery bits, but ask yourself: what use are they if you are unable to display them in the first place? Will you still care about those a year or two from now? If an X developer, 10 years from now, passes over this driver to adjust it to X-side changes, what will he think about those glittery bits and will they survive?"

            To those two remaining user out there, does shoddily implemented mpeg2 acceleration still matter that much to you today? Or would you rather have solid display support back first? Oh, and remember that fun and games with SSE assembly, how fast was that thrown out?
            Last edited by libv; 25 August 2017, 06:46 PM. Reason: the assembly stuff was also more important than structure display initialization

            Comment

            Working...
            X