Announcement

Collapse
No announcement yet.

It Looks Like AMDGPU DC (DAL) Will Not Be Accepted In The Linux Kernel

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

  • @bridgeman Late to the party, but have you guys ever considered building some DSLs and abstracting the tricky bits with source-translation at compile time, rather than a runtime abstraction layer? Maybe with a PEG/packrat parser and a good templating engine -- something as simple as awk can work wonders? That way you would still be reasonably confidant that things will work on Linux, while both making the upstream maintainers happy and reducing the burden of conformance/validation testing?

    I'm a long time game programmer with a technical background, I've worked on lots of different engines over the years, and it's been my observation that most everyone has been doing abstraction layers wrong, including myself. Extra layers of fine-grained abstractions end up being a nightmare to maintain and can end up causing performance issues.

    Anyway, I've recently had quite a bit of success doing our physicality based shading and material pipeline with a custom DSL that generates backends for HLSL, GLSL, PSSL and MSL. Also currently using the same idea to build and generate backends for our particle rendering system, allowing us to abstract rendering where geometry is generated and draw calls are batched on the CPU for OpenGL ES 2.0 profiles all the way up to where everything is done on the GPU.

    In both cases we're generating orders of magnitude more code (and a lot of it is high-performance stuff and very readable, code generation doesn't have to be a mess) while only having to maintain the stuff written in the DSL plus the DSL front-end and code generation templates. Literally generating several 100,000 LoC for all the various combinations and different platforms from a base of around 8000 LoC.

    Got the ideas a few years back from a talk by Alan Kay entitled "Programming and Scaling". Look it up.

    Comment


    • This constant war between blind linux idealist and GPU driver guys affects users, gamers and game developers the worst and no one cares. I just want my god dam 400$+ GPU to work out of the box like it does on Windows and play my games at FULL FPS / Potential of the graphics card with Audio/Video/VR working on my Linux Desktop !! screw the Redhat Canonical AMD Nvidia and Idealist Linux Kernel developers political BS. I've paid good money to buy a card that should work for what it was intended to do... And no i don't care weather the source is open or blobs I need performance I have paid for.

      Comment


      • Originally posted by bridgman View Post

        Actually Dave was the first person I called to ask for advice when I volunteered to set up the open source graphics initiative back in 2007, and you are probably running quite a bit of his code on your system today.

        Dave had already accepted an offer from Red Hat by the time we first talked.
        I know the subject is important for you bridgman but you are the last of us answering seriously to debianxfce, as his posts are globally... no comment

        Comment


        • Bridgman:

          Can you tell us what this will mean moving forward for upcoming and future AMD hardware? Now that upstream has made clear their intent to never mainline AMDGPU DC, what kind of loss in functionality cab the average user expect? Will it mean that newer and future hardware will take a much longer time to just light up on Linux?

          For example, when Zen is released I intend to assemble a Zen-powered computer and a 1440p monitor with a mid-range GPU (probably also an AMD) for live streaming some browser games over Twitch and Facebook using OBS (Intel is getting a tad expensive over here). What can I expect to not work? Will my card be able to light up the display and start KMS, with at least basic OpenGL acceleration for the DE on launch day? Will I be able to get native resolution over HDMI and DP?

          Will future releases take much longer to at least be capable of lighting up the display, activate KMS and attain OpenGL acceleration to at least drive the desktop GUI? And out of the above, how many of these minimum of must-work features can we expect to see supported on Linux of the hardware's launch day?

          I will rather not use Windows since I have reached a point where I am much more comfortable on Linux than on Windows, and not needing to buy a copy of Windows is money that is saved for other uses but by Jove, i will sink that money into a copy of Windows if I have to do so in order to use my new hardware at a baseline level of functionality.
          Last edited by Sonadow; 12-09-2016, 11:47 AM.

          Comment


          • Originally posted by Linuxhippy View Post
            I guess nobody seriously expects anybody else than AMD putting serious effort and maintenance into this codebase (development of the open-source radeonsi-driver is also almost exclusivly done by paid AMD OSS developers).
            I'm afraid that's not how it works.
            If the devs need to rework some of the common DRM code, that is used by DC, they will have to also touch DC.
            If the DC code there is overly complicated, it makes their job harder.



            I really don't understand the hate on Dave's goal: to have a maintainable codebase, which to users translates as faster and less error prone development of our beloved GPU drivers. Nothing prevents anyone from using a pre-built kernel that includes DC or building it themselves (it's open source after all...).

            Comment


            • Originally posted by Sonadow View Post
              Now that upstream has made clear their intent to never mainline AMDGPU DC.
              I don't believe upstream stated that. The HAL should not be mainlined, but not DC itself.

              Comment


              • Originally posted by Ansla View Post
                My Acer XF270HU works fine here over DP with either RX 480 or the onboard GPU of Kaveri. Except for audio or freesync, of course. If it doesn't work over HDMI it probably has to do with missing HDMI 2.0 support.
                Ofc, HDMI 1.4 can't handle [email protected], I'm using DP1.2.

                Well, some users (including myself) have reported about this problem at least with Hawaii and also Tonga, iirc.

                Interesting that it works for you with Kaveri, whose DCE is a few iterations older than Hawaii's and Tonga's. Could you tell me which exact kernel version you are using? Are you using radeon or amdgpu for Kaveri?

                Comment


                • This feel bad. For a second I thought: buy a mac

                  Comment


                  • Originally posted by Sonadow View Post
                    Bridgman:

                    Can you tell us what this will mean moving forward for upcoming and future AMD hardware? Now that upstream has made clear their intent to never mainline AMDGPU DC, what kind of loss in functionality cab the average user expect? Will it mean that newer and future hardware will take a much longer time to just light up on Linux?

                    For example, when Zen is released I intend to assemble a Zen-powered computer and a 1440p monitor with a mid-range GPU (probably also an AMD) for live streaming some browser games over Twitch and Facebook using OBS (Intel is getting a tad expensive over here). What can I expect to not work? Will my card be able to light up the display and start KMS, with at least basic OpenGL acceleration for the DE on launch day? Will I be able to get native resolution over HDMI and DP?

                    Will future releases take much longer to at least be capable of lighting up the display, activate KMS and attain OpenGL acceleration to at least drive the desktop GUI? And out of the above, how many of these minimum of must-work features can we expect to see supported on Linux of the hardware's launch day?

                    I will rather not use Windows since I have reached a point where I am much more comfortable on Linux than on Windows, and not needing to buy a copy of Windows is money that is saved for other uses but by Jove, i will sink that money into a copy of Windows if I have to do so in order to use my new hardware at a baseline level of functionality.
                    In case Bridgman does not see this, anyone else out here able to answer some of my questions? Thanks very much...

                    Comment


                    • Originally posted by Sonadow View Post
                      Can you tell us what this will mean moving forward for upcoming and future AMD hardware? Now that upstream has made clear their intent to never mainline AMDGPU DC, what kind of loss in functionality cab the average user expect? Will it mean that newer and future hardware will take a much longer time to just light up on Linux?

                      For example, when Zen is released I intend to assemble a Zen-powered computer and a 1440p monitor with a mid-range GPU (probably also an AMD) for live streaming some browser games over Twitch and Facebook using OBS (Intel is getting a tad expensive over here). What can I expect to not work? Will my card be able to light up the display and start KMS, with at least basic OpenGL acceleration for the DE on launch day? Will I be able to get native resolution over HDMI and DP?

                      Will future releases take much longer to at least be capable of lighting up the display, activate KMS and attain OpenGL acceleration to at least drive the desktop GUI? And out of the above, how many of these minimum of must-work features can we expect to see supported on Linux of the hardware's launch day?

                      I will rather not use Windows since I have reached a point where I am much more comfortable on Linux than on Windows, and not needing to buy a copy of Windows is money that is saved for other uses but by Jove, i will sink that money into a copy of Windows if I have to do so in order to use my new hardware at a baseline level of functionality.
                      The situation before was:

                      - initial code pushed for public review
                      - lots of issues raised
                      - we're working on implementing changes that address the issues raised
                      - in the meantime we are lighting up new hardware with DC anyways
                      - as we resolve initially identified issues it's likely new ones may be identified
                      - we don't know how long it will take before we can get upstream but are continuing to work on it

                      After this dramatic event, the situation is :

                      - initial code pushed for public review
                      - lots of issues raised
                      - we're working on implementing changes that address the issues raised
                      - in the meantime we are lighting up hardware with DC anyways
                      - as we resolve initially identified issues it's likely new ones may be identified
                      - we don't know how long it will take before we can get upstream but are continuing to work on it

                      (in case it's not obvious, nothing has changed)

                      A lot of the confusion here is that DC has two meanings - it's the big chunk of developer effort & code we want to re-use across platforms for all kinds of good reasons, and it is also a very specific abstraction layer inside that code. It's the second meaning that Dave and Daniel have concerns about, because it internalizes things that they feel should be part of the driver rather than part of what is effectively a blob (despite being publicly developed open source) to them. We understand that.

                      Again, this was primarily a miscommunication, so other than making for some good reading it doesn't mean much.

                      Michael really needs to change the article - seems like everyone is posting and getting all worried based on the article and not reading any of the comments before going ahead and making things even worse. I'm trying to be on vacation and can't spend all day responding to basically the same "I didn't read the other comments so this looks bad what do I do" posts over and over again.
                      Last edited by bridgman; 12-09-2016, 12:41 PM.

                      Comment

                      Working...
                      X