Announcement

Collapse
No announcement yet.

Cleaning Up The Linux Graphics Driver Stack

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

  • Cleaning Up The Linux Graphics Driver Stack

    Phoronix: Cleaning Up The Linux Graphics Driver Stack

    Yesterday Luc Verhaegen gave a talk at FOSDEM on reverse engineering a motherboard BIOS, but today we finally have X@FOSDEM for the last time. Luc has just begun his talk on unifying and simplifying the free software desktop's graphics driver stack. Here are his slides and we will be back with more updates and videos on Phoronix as the presentation progresses.

    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
    It doesn't look clear. I don't get anything from the diagrams... What's that for and what they want to achieve?

    Comment


    • #3
      they're just the slides without the actual talk. Hopefully it'll be clear once the videos arrive..

      Comment


      • #4
        This by far has been the most heated talk at X@FOSDEM in recent years... Video coming soon as a 3GB HD video upload goes through...
        Michael Larabel
        https://www.michaellarabel.com/

        Comment


        • #5
          PDF: click here. I'm really eager for this video .

          Comment


          • #6
            I am deeply impressed by the "unichrome" slide. I think it's urgent to handle this issue. The 3 parts had never been fixed together seamlessly in every distributions. Nearly every update of one component causes more or less regressions, especially for a cutting-edge distro user like me.(Archlinux)

            Comment


            • #7
              Originally posted by leeyee View Post
              I am deeply impressed by the "unichrome" slide. I think it's urgent to handle this issue. The 3 parts had never been fixed together seamlessly in every distributions. Nearly every update of one component causes more or less regressions, especially for a cutting-edge distro user like me.(Archlinux)
              Nothing is likely to change... It was basically discounted by other developers as either something tried and didn't work, don't care it's a problem, Unichrome is totally different from -intel, all we care about are features and performance, etc.
              Michael Larabel
              https://www.michaellarabel.com/

              Comment


              • #8
                Talent gone to waste

                Luc is a talented coder for hardware drivers, but unfortunately his work doesn't get into distro user's hands often because of his penchant to fork projects. The forks end up abandoned by everyone else (unichrome and radeonhd come to mind), probably because of his inflexible attitude (it's his way or the highway). He'd make a much bigger impact if he learned to coordinate with other FOSS programmers (we're all on the same team!) and accept some compromises.

                Comment


                • #9
                  oh come on ! do some lytebox/litebox/whateverbox for images on articles ;/ its hurting my mind to view all those slides without propper tool.

                  Comment


                  • #10
                    Originally posted by Michael View Post
                    Nothing is likely to change... It was basically discounted by other developers as either something tried and didn't work, don't care it's a problem, Unichrome is totally different from -intel, all we care about are features and performance, etc.
                    Unichrome doesn't have a kernel drm or mesa driver component.

                    Shipping drivers and expecting your users to enable the functionality they want with an xorg.conf is also fail, (radeonhd might have DRI enabled now).

                    This talk held nothing of interest really. *yawn*.

                    Intel ship releases every quarter with the recommended components are tested together, this stuff doesn't need to be in one tree, shipping out of tree kernel modules is also fail.

                    Dave.

                    Comment

                    Working...
                    X