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

  • pal666
    replied
    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

    Leave a comment:


  • bridgman
    replied
    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.

    Leave a comment:


  • liam
    replied
    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).

    Leave a comment:


  • DALtony
    replied
    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.

    Leave a comment:


  • DALtony
    replied
    Originally posted by dungeon View Post

    for better picture of the whole story someone should just make a list of all features for Windows which are maded on top of DAL and to realise that thing tend to be huge
    just a few come to mind... far from complete list I don't feel like logging in over the weekend to remind how big the list is. Did not include stuff we already support upstream

    Functionality
    • FreeSync in full screen mode
    • FreeSync window mode
    • [email protected], [email protected], [email protected] with DP1.4 HBR3
    • HDMI 2.0: [email protected]
    • HDMI deep color up to 12bpcc
    • VR headsets
    • HDCP: Play protected content
    • DP and HDMI audio. support up to 8 channel audio and HD formats
    • Bad HDMI/DP cable detection
    • Virtual support resolution - via downscaling
    • HDR (high dynamic range)
    • Timing Sync / Frame sync across multiple GPU

    Performance Optimization
    • FreeSync refresh rate ramping: reduce panel flicker due to luminance change (which scale with refresh rate) and allow free sync to work on sub-optimal panel
    • FreeSync below the range: go as low as half of min refresh rate supported by monitor.
    • Direct Flip: switching between different frame buffer formats without requiring full mode set.
    • Enhanced scaling quality: amdgpu only support HW default 2 taps auto-scale. DAL computes and programs the scaler maximizing image quality
    • Enhanced color: more precise gamma curve, color gamut correction.
    • A few more fps, lots of work goes into optimize display memory request patterns to not get in the way of rendering

    Power Optimization
    • burst display read from memory keep DRAM self-refresh as much as possible. = hours of idle battery life
    • Frame buffer compression: reduce memory bandwidth. ~half hour battery
    • multip-plane overlay / android surface flinger: allow direct scan out of decode video and skip composition to desktop. = hours of batter life when watching video
    • allow dynamic memory clock switch in multi-display use case. ~40 watts of saving on Hawaii
    • power gating / clock gating: power off idle HW blocks

    Leave a comment:


  • pal666
    replied
    Originally posted by bridgman View Post
    You do understand that Alex is not part of the DAL team, right ?
    he can't understand that, he is disoriented idiot

    Leave a comment:


  • bridgman
    replied
    Originally posted by Sonadow View Post
    Obviously the general populace will not have access to the hardware until launch day, so my definition of lighting up is that of
    1) Works on the latest shipping version of the kernel (not git!) on launch day or shortly after launch with KMS
    2) can output at up to 1440p over HDMI
    3) Can hook onto the modesetting DDX driver
    4) can talk with latest libdrm and Mesa to hardware accelerate a typical DE (like Gnome or Plasma)

    #1, #2 and #3 are about getting a usable display. #4 is about actually using the hardware, and not falling back to software and llvmpipe to get the desktop drawn onscreen. I consider these four aspects to be the bare minimum of expectations with regards to any driver; if all 4 requirements are met, i deem the hardware as being successfully lit up.

    Anything else like HDMI audio, FreeSync, etc etc are bonuses and icing on the cake that I can afford to wait longer for or live without for an extended period of time.
    You bumped the wrong post before

    If you absolutely need latest shipping version of the kernel (which may be identical to git at times) then you'll probably need to wait for upstreaming. The AMDGPU-PRO focus is on enterprise/LTS distros and workstation/CAD markets, so while we will be closing the gap between bleeding edge and AMDGPU-PRO support over time the mere fact that it runs on a ~2 month release cycle means you won't get #1 that way.

    Same with #4 - picking up an AMDGPU-PRO kernel driver only will give you a good chance of working with the libdrm and mesa which shipped in that distro, but no guarantees about being able to make a franken-stack with that kernel driver plus newer libdrm/mesa. The dependency hierarchy doesn't work that way... kernel + drivers usually should be newer than userspace, not older.

    The real solution for what you want (if you insist on #1 and #4) is pulling from upstream. For #2 and #3 only we could satisfy that with a subset of DAL/DC functionality as we do for currently shipping parts, but every year the display logic gets more complex and power management becomes a bigger part of display logic expectations so the subset stopped being "simple" a while ago. Practically speaking you want an upstream driver with DAL/DC included, and that's where our focus is rather than than the subset functionality we ship upstream today.
    Last edited by bridgman; 12-10-2016, 08:19 PM.

    Leave a comment:


  • bridgman
    replied
    Originally posted by Sonadow View Post
    That implies the use of AMDGPU-PRO, doesn't it? What if I do not want to use AMDGPU-PRO, but instead stay on with a vanilla kernel + libDRM + Mesa stack? What will i expect to lose?
    Originally posted by Sonadow View Post
    Bringing it up again because it dropped too far back and I believe this is the main question that most people want to know.
    Sorry, thought I already answered it but turns out someone asked the same question (almost word-for-word) on Reddit...

    1. Turns out "lighting up" means different things to different people. I think of it as initial (in-house) bringup of a new GPU fresh from the fab, months before it goes to market, on an internal code branch. You may be thinking of it as meaning something else.

    2. If you want to use DAL/DC with the all-open stack today, try installing only the kernel driver package from AMDGPU-PRO onto a distro that it supports. We plan to regularly QA that combination over time although not sure we are 100% testing it today.

    3. Going forward we are thinking about formalizing #2, allowing us to release a ready-to-go all-open driver stack. The main reason for doing this would be to take advantage of the Kernel Compatibility Layer (KCL) code in the -PRO kernel driver (which is not allowed upstream) but in the short term it would also be a handy way to get DAL/DC while we are finishing the rework required for upstreaming.

    Leave a comment:


  • bridgman
    replied
    Originally posted by ihatemichael
    If he's so effective as you say he is, then why he keeps wasting time talking about stupid politics like "But attacking us or our corporate culture is not cool."
    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 ?

    Originally posted by ihatemichael
    Why they didn't listen to Dave when he pointed out they've been wasting their time building this in the first place?

    https://lists.freedesktop.org/archiv...ry/100566.html
    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.

    Originally posted by ihatemichael
    I follow development of open source projects (including drivers development) and this isn't anything new to me. What I'm saying is, instead of fixing his code why he keeps wasting time with drama?
    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 ?

    Leave a comment:


  • dungeon
    replied
    Does even RHEL care about Desktop with opensource drivers ? I guess, most most most most most likely not ... install propertiary drivers there and move on And for those average rollers with opensource drivers, it is impossible to make straightforward distro with stock and recently also even signed kernels

    Which one kernel is that where opensource drivers work fine for all intel, nouveau and radeon drivers You won't found it, it is never single one the best... as princess is always in another castle and further with userspace drivers too

    And with that you have mass of people who roll kernels for no other reason than because of those shitty incosistent GPU drivers

    Further as when you don't have that, there won't be a trusty distro ever ever ever ever ever possible with just oss drivers and there won't be Linux on Desktop
    Last edited by dungeon; 12-10-2016, 07:20 PM.

    Leave a comment:

Working...
X