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

  • Originally posted by dungeon View Post

    And that is whole story, linux devs traditionally wanna something very easy or as easiest as possibile maintanable but this one is nothing easy...
    The complexity in display come from it being a real time constant memory fetch subsystem. While your CUs, video encode decode just suffer frame drop or lower FPS, you will get a nasty flickering or flashing blank screen if display's real time latency and bandwidth requirement isn't met.

    Display account for most of the power consumption when your system is idling. While you are reading this post your GPU is 99.9% idle. However display still need to fetch 60 frames a second even if your screen hasn't update in past 10 seconds before you scroll down.

    Leave a lot of clock margins, keep all caches, hw blocks and internal high bandwidth buses powered up at all time then you won't run into any problem. If modes above 300Mpix ([email protected]) and power consumption isn't a concern there is no reason to have more than 10k or 20k lines of simple code to light up a display. You will still get a display if you bypass most of the HW added to display pipeline to enhance the quality of final output image.

    Anyways I am sure we can workout something that works for maintainer in terms of maintainablity and our internal requirements, including delivering feature rich and performance/power optimized driver on linux. We will continue discuss the RFC in public and if you are interested in some of the discussion you can start from https://lists.freedesktop.org/archiv...er/126698.html as this thread is about to get technical.

    Comment


    • Originally posted by pal666 View Post
      you utterly failed to understand what he said. he said that hal is already written by other team and they don't have people to rewrite it. if some imaginary community contributor jumps in and rewrites it, everybody would be happy. so who is that opensource champion?

      > Just an added note on that: I do think that there's some driver teams
      > who've managed to pull a shared codebase between validation and upstream
      > linux (iirc some of the intel wireless drivers work like that). But it
      > requires careful aligning of everything, and with something fast-moving
      > like drm it might become real painful and not really worth it. So not
      > outright rejecting DC (and the code sharing you want to achieve with it)
      > as an idea here.
      I think we have to make it work. We don't have the resources to have separate validation and Linux core teams. It's not just the coding. Much of our validation and compliance testing on Linux leverages this as well. From our perspective, I think the pain is probably worth it at this point. Display is starting to eclipse other blocks as far as complexity. Not even just the complexity of lighting up complex topologies. The really tough stuff is that display is basically a real-time service and the hw is designed with very little margin for error with respect to timing and bandwidth. That's where much of the value comes from sharing resources with validation teams. For us, that makes the potential pain of dealing with fast moving drm worth it. This is not to say that we won't adopt more use of drm infrastructure, we are working on it within the bounds of our resource constraints. Alex
      So, I'm not quite sure what you're arguing about (especially with the "opensource champion" remark).

      Comment


      • Originally posted by pal666 View Post
        you utterly failed to understand what he said. he said that hal is already written by other team and they don't have people to rewrite it. if some imaginary community contributor jumps in and rewrites it, everybody would be happy. so who is that opensource champion?
        That would only work if the open source champion was also willing to rewrite support for every new chip that came out and to port fixes from the DAL/DC code we publish to the rewritten form. Otherwise nobody would be happy.

        Comment


        • Originally posted by bridgman View Post
          That would only work if the open source champion was also willing to rewrite support for every new chip that came out and to port fixes from the DAL/DC code we publish to the rewritten form. Otherwise nobody would be happy.
          well, you still have to do it without imaginary help, so if someone will do part of your work for you, it is strictly beneficial

          Comment


          • Michael, I think you 'forgot' 'yet' in articles heading.

            Comment


            • Originally posted by liam View Post
              So, I'm not quite sure what you're arguing about (especially with the "opensource champion" remark).
              i am not surprised
              remark was regarding dave's question in mail mentioned in article

              Comment


              • Originally posted by pal666 View Post
                well, you still have to do it without imaginary help, so if someone will do part of your work for you, it is strictly beneficial
                Not really. If your hypothetical open source champion works closely with our driver teams for all the other platforms that will share the code to come up with a solution that fits the Linux kernel *and* can be made work for the other platforms then it is strictly beneficial. That's what we have to do.

                If they just start ripping parts out of the Linux copy and ignoring all the other platforms that just makes even more work for everyone because the code will no longer be shareable across platforms and so support for every new chip we introduce will have to go through the same transmogrification process - additional work which would not be required if the changes had been worked out cross-platform in the first place.
                Last edited by bridgman; 12-11-2016, 12:41 PM.

                Comment


                • Originally posted by veritas View Post
                  Michael, I think you 'forgot' 'yet' in articles heading.
                  The headline should be "AMD sends RFC to help with DC/DAL planning, gets strongly worded answer to question they didn't ask".

                  The article is based on the assumption that we will never change the DC interface, while Harry's RFC already talked about continuing to clean up and reduce abstractions in DC prior to upstreaming.
                  Last edited by bridgman; 12-11-2016, 12:50 PM.

                  Comment


                  • Originally posted by bridgman View Post
                    Not really. If your hypothetical open source champion works closely with our driver teams for all the other platforms that share the code to come up with a solution that fits the Linux kernel *and* works for all the other platforms then it is strictly beneficial. That's what we have to do.
                    so you have to do it anyway, the only difference is whether upstream kernel will have driver for vega in this decade on in next

                    Comment


                    • Originally posted by bridgman View Post

                      Not sure what you mean by "keeps wasting time" - believe you are talking about one email, perhaps 45-60 seconds total, in a year ? Is that what you mean ?

                      Perhaps "keeps wasting time" is an exaggeration and not the right thing to say, sorry. I simply meant that from reading his email I get the feeling he got offended, that's simply it.

                      What I was going after is that perhaps he should have keep his feelings aside and just work with the other engineers to do whatever it's needed to do to get the support upstream, that is, remove the abstraction layer that is being questioned.


                      Originally posted by bridgman View Post
                      Don't understand your question. All the issues Dave mentioned in that post have been addressed, including reducing code size to ~66K which is only a bit larger than the display portion of current upstream drivers. The topic being discussed now is something different, not mentioned in the email you referenced.
                      It's good that the code was reduced, but has the HAL been removed?

                      Originally posted by bridgman View Post
                      You do understand that Alex is not part of the DAL team, right ?

                      You keep saying "keeps wasting time" but AFAIK we are talking about one email taking less than a minute to write. Is there a long history of dramatic emails I have somehow managed to miss or are you perhaps injecting the drama yourself ?
                      I didn't know that.

                      As I said, "keeps wasting time" was an exaggeration, but at the same time I feel he was expressing some level of frustration, maybe this could have been avoided somehow and do the right thing from the start?

                      I agree with this comment here:

                      https://www.reddit.com/r/linux/comme...iners/db0e0hx/

                      And no, I'm not trying to start any drama, the drama has already started with these discussions as you can see on reddit, hacker news and this forum.
                      Last edited by ihatemichael; 12-11-2016, 12:57 PM.

                      Comment

                      Working...
                      X