Announcement

Collapse
No announcement yet.

AMDGPU DC Pull Request Submitted For Linux 4.15: Finally The New Display Stack

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

  • LeJimster
    replied
    Well, I hope this finally makes it upstream. We been waiting a loooong time and I feel this work has held up some of the newer technologies being available to Linux users. As a Vega user this is welcome news. I had a small headache trying to set up a fresh install the other day.

    Leave a comment:


  • illwieckz
    replied
    Originally posted by JPFSanders View Post
    It will be a great moment for AMD devs once this is in, it represents a huge lot of work.

    The most exciting part is that it is the basis for even better things to come, as this should facilitate things like OpenCL moving forward.
    Originally posted by CrystalGamma View Post

    … but OpenCL has nothing to do with display management, pageflipping, modesetting or anything that goes over the display connector …
    It has a lot to do, but the reason is not modesetting or things like that.

    Tu sum it up very quickly : to get ROCm OpenCL stack, you need to own a Vega GPU, to get a display you need to not own a Vega GPU, so people are buying nVidia instead.

    Well, it's said very fastly, but the point is: every bit mainlined in the whole free software stack benefit to others. Most people needs to display their OpenCL application (Blender, Darktable…).

    Also, most people not only focus on one tech, for example I chose AMD not only because the software stack is almost completely free, but because one single setup can provides me DX9 support for some good games I don't want to miss, OpenGL&Vulkan support for some other good games I don't want to miss, OpenCL support for some application I need, and of course, I'm able to display everything of that.

    If the software stack for a given GPU does not fullfill the Display need, another GPU doing both Display and OpenCL can be chosen by people needing both Display and OpenCL. Do you remember when Michael said some month ago he chosen an nVidia GPU for the sole reason its software stack provided HDMI audio support, despite this software stack being absolutely closed? Because it provided him two features he needed at the same time on the same setup: Display and Audio.

    So, the same way, any improvement in the Display topic helps people with OpenCL needs when these people needs to have both OpenCL and Display support on the same GPU, which is very common.

    If OpenCL hardware does not have Display support, the alternative is CUDA hardware. Display support can fix that.

    Leave a comment:


  • CrystalGamma
    replied
    Originally posted by JPFSanders View Post

    However it will free resources and facilitate other tasks. In general it will make everybody's life easier, at some point we would be able to stop switching from booting one partition or another to use OpenCL.
    I'm not sure if the people working on this will be working on the rest of the open-source driver, but point taken about dual-booting

    Leave a comment:


  • Kver
    replied
    Looks like it's just been accepted.

    "Overall verdict from me is that DC is big project, and like any big project it's never done. So at least for me the goal isn't to make things perfect, becaue if that's the hoop to jump through we wouldn't have any gpu drivers at all. More important is whether merging a new driver base will benefit the overall subsystem, and here this primarily means whether the DC team understands how upstream works and is designed, and whether the code is largely aligned with upstream (especially the atomic modeset) architecture. Looking back over the last two years I think that's the case now, so

    Acked-by: Daniel Vetter

    for merging this pull."

    It's kind of funny though, he does mention that Linus will probably "have a spaz". Looks like you might have some more news soon, Michael. :P
    Last edited by Kver; 27 September 2017, 07:17 AM.

    Leave a comment:


  • R41N3R
    replied
    It is great to see this finally happen :-) We all waited eagerly and it is good to see that it is enabled automatically for Polaris as well. Thanks AMD, now I want to invest in a custom Vega, hope they will be available soon.

    Leave a comment:


  • JPFSanders
    replied
    Originally posted by L_A_G View Post

    Care to explain what those "falsehoods" are? Because I get the feeling you're trying to defend this maintainer using allegations because of a lack of actual arguments.



    He's complaining about what they look like, not what quality the actual code inside is. Being heavily based on AMD's internal Windows code there's obviously going to be style differences between that and what the kernel uses.
    Version 1.x is just version 1.x nothing stops AMD or anybody else from that matter to improve things once they're accepted in the Kernel.

    The key thing about mainlining is that if anything needs to be debugged or improved many more eyes will be willing to help now, and while there is no replacement for the AMD developers (it is a too complex project) many small contributions will be made by onlookers, and some of these onlookers may become contributors.

    This is how it works normally, first it works, then it is improved, check the state of Mesa one/two/three years back.

    In the industry it is called "momentum".

    Leave a comment:


  • JPFSanders
    replied
    Originally posted by CrystalGamma View Post

    … but OpenCL has nothing to do with display management, pageflipping, modesetting or anything that goes over the display connector …
    However it will free resources and facilitate other tasks. In general it will make everybody's life easier, at some point we would be able to stop switching from booting one partition or another to use OpenCL.

    Good times are ahead :-)

    Well done AMD developers, this will strengthen the AMD+Linux ecosystem a lot.

    Leave a comment:


  • L_A_G
    replied
    Originally posted by schwarzman View Post
    Please cut that crap! Your statement contains malicious allegations and and falsehoods.
    Care to explain what those "falsehoods" are? Because I get the feeling you're trying to defend this maintainer using allegations because of a lack of actual arguments.

    My favorite bit:
    He's complaining about what they look like, not what quality the actual code inside is. Being heavily based on AMD's internal Windows code there's obviously going to be style differences between that and what the kernel uses.

    Leave a comment:


  • Nille
    replied
    Originally posted by CrystalGamma View Post

    … but OpenCL has nothing to do with display management, pageflipping, modesetting or anything that goes over the display connector …
    But the resources that are currently bind by the dc code can now work on other areas.

    Leave a comment:


  • schwarzman
    replied
    Originally posted by L_A_G View Post
    I wonder what David is going to come up this time to stop DAL/DC from being merged? Not enough time to properly review the code? Too much redundant code because they're not cleaning away all the old AMD display code? Still too much abstraction going on? Code quality not up to standards?
    Please cut that crap! Your statement contains malicious allegations and and falsehoods.

    To everyone else: Daniel Vetter just ACK'd the series: https://lists.freedesktop.org/archiv...er/153482.html

    More important is whether merging a new driver base will benefit the overall subsystem, and here this primarily means whether the DC team understands how upstream works and is designed, and whether the code is largely aligned with upstream (especially the atomic modeset) architecture.

    Looking back over the last two years I think that's the case now, so

    Acked-by: Daniel Vetter <daniel.vetter at ffwll.ch>

    for merging this pull.
    My favorite bit:
    And yes some of the files are utterly horrible to read and not anything close to kernel coding style standards. But that's the point, they're essentially gospel from hw engineers that happens to be parseable by gcc.

    Leave a comment:

Working...
X