Announcement

Collapse
No announcement yet.

AMD Linux Graphics Driver Stack Cutting Down On PCI ID Table Duplication

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

  • AMD Linux Graphics Driver Stack Cutting Down On PCI ID Table Duplication

    Phoronix: AMD Linux Graphics Driver Stack Cutting Down On PCI ID Table Duplication

    Traditionally with the Linux graphics drivers there are PCI ID tables littered in multiple places throughout the driver stack from the DRM/KMS kernel drivers to the Mesa OpenGL/Vulkan drivers but also the potential for other areas like the increasingly less common DDX drivers and other components. AMD is looking to address the proliferation of PCI IDs throughout the stack and the maintenance burden of having to keep the list of IDs in sync across the different components...

    http://www.phoronix.com/scan.php?pag...ID-Proliferate

  • #2
    How can DDX drivers be increasingly less common if modesetting on the other hand is a mess (if talking about xorg specifically and ignoring wayland)?
    E.g. you reported about disabling atomic for modesetting DDX on xorg-master, as it's in a terrible state. And not even that worked out, as it completely broke pageflipping on Intel (and no one seems to care much until now).

    Comment


    • #3
      Originally posted by aufkrawall View Post
      How can DDX drivers be increasingly less common if modesetting on the other hand is a mess (if talking about xorg specifically and ignoring wayland)?
      E.g. you reported about disabling atomic for modesetting DDX on xorg-master, as it's in a terrible state. And not even that worked out, as it completely broke pageflipping on Intel (and no one seems to care much until now).
      Got a bug report for that, I'm struggling to understand what you've written

      Comment


      • #4
        The gist: Xorg modesetting driver has issues and is lacking features vs. DDX drivers.
        When Michael pretty much promotes it by describing DDX drivers as "increasingly less common" (How is that statement even backed, apart from increasing Wayland usage?), it's not really spreading useful information.

        Comment


        • #5
          Originally posted by aufkrawall View Post
          The gist: Xorg modesetting driver has issues and is lacking features vs. DDX drivers.
          When Michael pretty much promotes it by describing DDX drivers as "increasingly less common" (How is that statement even backed, apart from increasing Wayland usage?), it's not really spreading useful information.
          I think FireBurn makes a really good point.

          Comment


          • #6
            Originally posted by aufkrawall View Post
            The gist: Xorg modesetting driver has issues and is lacking features vs. DDX drivers.
            When Michael pretty much promotes it by describing DDX drivers as "increasingly less common" (How is that statement even backed, apart from increasing Wayland usage?), it's not really spreading useful information.
            I think you've answered your own question.

            1. Wayland
            2. Lots of people using modesetting

            Pretty much by definition, since neither of those used to be the case, there is therefore less DDX driver usage.

            Comment


            • #7
              So, this seems like it should be done by default for all PCI device IDs, having a centralized location for them despite manufacturer. I am guessing it isn't currently the case then?

              Comment


              • #8
                Originally posted by dragorth View Post
                So, this seems like it should be done by default for all PCI device IDs, having a centralized location for them despite manufacturer. I am guessing it isn't currently the case then?
                device ids are located in device roms. subj is about mapping device id to some properties like chip family

                Comment


                • #9
                  Originally posted by pal666 View Post
                  device ids are located in device roms. subj is about mapping device id to some properties like chip family
                  OK? The Device IDs are also located in the source for the driver, which is what this subj is about. My question was why this would be handled by the driver developer, rather than a general function with a list of device cases. One of the first tasks the Kernel would need to do is go through this list, to initialize these devices, so why wouldn't all Device IDs be located near that function. Even just an RO file per device type with a list of Device IDs and their respective drivers would make maintaining this simple.

                  So my question was, what is the reason something like this approach isn't taken?

                  Comment


                  • #10
                    Originally posted by dragorth View Post

                    OK? The Device IDs are also located in the source for the driver, which is what this subj is about. My question was why this would be handled by the driver developer, rather than a general function with a list of device cases. One of the first tasks the Kernel would need to do is go through this list, to initialize these devices, so why wouldn't all Device IDs be located near that function. Even just an RO file per device type with a list of Device IDs and their respective drivers would make maintaining this simple.

                    So my question was, what is the reason something like this approach isn't taken?
                    The drivers have the device ids so they can determine which devices they can bind to and drive. The driver developers know best what devices their driver supports.

                    Comment

                    Working...
                    X