Announcement

Collapse
No announcement yet.

More AMDGPU DC Patches Posted As It Looks Unlikely It Will Land For Linux 4.13

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

  • M-Bab
    replied
    Sorry but the drm-next does NOT contain any DC code. You can always check this in the code tree if the directory drivers/gpu/drm/amd/display/dc exists.
    The latest kernels WITH DC are always the amd-staging-* ones.

    Leave a comment:


  • M-Bab
    replied
    Sorry but the drm-next does NOT contain any DC code. You can always check this in the code tree if the directory drivers/gpu/drm/amd/display/dc exists.
    The latest kernels WITH DC are always the amd-staging-* ones.

    Their limitation is that they are not supplied with kernel fixes and security patches. To overcome this I started a little github project where I merge the kernel patches into amd-staging: https://github.com/M-Bab/linux-kernel-amdgpu (4.9 and 4.11 are available). For lazy/trusting people I also provide my debian packaged build results as ready to use (x86-64) binaries: https://github.com/M-Bab/linux-kernel-amdgpu-binaries

    Leave a comment:


  • M-Bab
    replied
    The drm-next-4.13 does NOT contain DC related stuff (you can always check in the tree code if the directory drivers/gpu/drm/amd/display/dc exists.
    Latest kernel WITH DC code are always the amd-staging-* ones.

    Their limitation is that they never get the usual official kernel fixes and security fixes - to overcome this I started a little project on github where I regularly merge these: https://github.com/M-Bab/linux-kernel-amdgpu (4.9 and 4.11 available). For the lazy/trusting people I also provide my build results as ready to use x86-64 binaries: https://github.com/M-Bab/linux-kernel-amdgpu-binaries

    Leave a comment:


  • oleid
    replied
    Is there somewhere an Linux 4.11++ branch including DC and ROCm? Didn't find anything.

    Leave a comment:


  • dungeon
    replied
    Originally posted by Spazturtle View Post
    I must be missing something because I don't understand why people expect AMD to drop DC and make an open-source HDCP implementation. Are there any open source HDCP implementations? I would be very surprised if there where.
    I dunno, it must be because DAL is renamed to DC but AMD is still AMD and not AC... maybe we should kill some elephant in that name or something

    Last edited by dungeon; 09 June 2017, 10:48 PM.

    Leave a comment:


  • Spazturtle
    replied
    I must be missing something because I don't understand why people expect AMD to drop DC and make an open-source HDCP implementation. Are there any open source HDCP implementations? I would be very surprised if there where.

    Leave a comment:


  • Geopirate
    replied
    Originally posted by GruenSein View Post

    Couldn't agree more. That DC is the new display code providing all hardware features (FreeSync and such...) has been clear for at least a year. The implementation is even there. The only reason for it being so late is that its programming practises don't appeal to the DRM-maintainers. I am not here to judge that so think about this what you will but AMD has a working open source implementation. I think, there's even a 4.9-branch with DC enabled. Reimplementing it once more in a non-DC driver would be a terrible waste.

    So, how about this: Instead of posting once a month that we still don't know how much longer the DC refactoring will take, let's simply talk about it when we actually know something. This frequent anti-hype about DC seems really unnecessary to me and it just gets everyone worked up about the one GPU company that's arguably making the largest progress by far when it comes to FOSS.

    Edit: Whoever buys a Vega card when it is released and wants to run it under Linux (There will be very few, I suspect) still has the option of using the closed source amdgpu-pro driver to get all features right away. I am not even sure why this is such a sore spot for many. With Nvidia based cards, this is the only option and they receive continuous praise for their super-optimized drivers. So, it's not like Vega cards will be useless before DC lands.
    I think at this point people just enjoy getting themselves worked up. There are several posts here complaining about AMD that used well worn points that have been explained dozens of times at this point. People who have been even marginally paying attention to the Vega situation heard one of the multiple direct reports from Raja that they are having driver issues in general as in the Windows and/or Enterprise drivers as well. I'm sure people on this forum have delusions that if they are behind in general they should abandon their Windows efforts and put all the work into merging DC/DAL.

    Leave a comment:


  • bridgman
    replied
    Originally posted by GruenSein View Post
    I am not here to judge that so think about this what you will but AMD has a working open source implementation. I think, there's even a 4.9-branch with DC enabled. Reimplementing it once more in a non-DC driver would be a terrible waste.
    Also a 4.11 branch with DC enabled, plus source code from the hybrid kernel driver's mainline which includes Kernel Compatibility Layer support.

    The KCL logic encapsulates the changes required for backporting to different kernel versions, which is what you need in order to be able to "install a driver" rather than "build the kernel" or backport.

    Originally posted by GruenSein View Post
    Edit: Whoever buys a Vega card when it is released and wants to run it under Linux (There will be very few, I suspect) still has the option of using the closed source amdgpu-pro driver to get all features right away. I am not even sure why this is such a sore spot for many. With Nvidia based cards, this is the only option and they receive continuous praise for their super-optimized drivers. So, it's not like Vega cards will be useless before DC lands.
    They would not be restricted to the closed-source (hybrid) amdgpu-pro driver either.

    You can run the out-of-tree kernel code with the open source stack as well, either by pulling source code own from one of agd5f's trees or by installing the kernel (and libdrm, I think) packages from amdgpu-pro onto an otherwise open source system.
    Last edited by bridgman; 09 June 2017, 09:43 PM.

    Leave a comment:


  • dungeon
    replied
    So, it seems FreeSync2 monitors are already available

    Samsung just announced the world’s first FreeSync 2-enabled PC monitors, the 27- and 32-inch CHG70 and the utterly massive 49-inch CHG90 ultrawide display—which is essentially a multi-monitor setup without multiple monitors...

    http://www.pcworld.com/article/32001...r-monitor.html

    Should at least AMDGPU-PRO support these?

    Big curved shit plus FreeSync2 there probably Vega should drive this fine... at least it should explain why Vega must go thorough DC




    Logical question is - why "every pixel perfect" is a feature, when even pixels nor screens are not perfect anymore?

    Also why i need GL (and all E/GL cruft needed in between) to drive me shitty composition as i need to run some modern Vulkan2 FreeSync2 app here?
    Last edited by dungeon; 09 June 2017, 09:00 PM.

    Leave a comment:


  • pouar
    replied
    I hope they got rid of the os abstraction layers, as that will never get accepted upstream

    Leave a comment:

Working...
X