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

  • BS86
    replied
    Originally posted by GuercH View Post

    so what do i get on Polaris if i enable this on the future?
    working HDMI/DP audio and Freesync - as soon as the later is included in the amdgpu package.

    Leave a comment:


  • GuercH
    replied
    Originally posted by Twysock View Post

    No, since Polaris was setup to work with the existing display code in amdgpu. The new 'artist formerly known as DC' code is only native for Vega and Raven.
    so what do i get on Polaris if i enable this on the future?

    Leave a comment:


  • Twysock
    replied
    Originally posted by GuercH View Post
    Not default an the Rx 400 series?
    No, since Polaris was setup to work with the existing display code in amdgpu. The new 'artist formerly known as DC' code is only native for Vega and Raven.

    Leave a comment:


  • GuercH
    replied
    Not default an the Rx 400 series?

    Leave a comment:


  • PuckPoltergeist
    replied
    Originally posted by Klassic Six View Post

    Yeah I can see that and it's good for you if you can read AND understand.
    What are you complaining about? Should Vega-users wait for the functionality until all other generations are ready for release?

    Leave a comment:


  • Klassic Six
    replied
    Originally posted by PuckPoltergeist
    Because it's not tested enough. Reading and understanding seems hard these days....
    Yeah I can see that and it's good for you if you can read AND understand.

    Leave a comment:


  • PuckPoltergeist
    replied
    Originally posted by GreatEmerald View Post
    Yes, by my point was that you can start by writing Linux code and then build up abstractions from there, rather than doing it the other way round.
    Or you get the code from the HW-team and build the different drivers on top of this. This is what AMD-devs are telling over and over again.

    Leave a comment:


  • L_A_G
    replied
    Originally posted by duby229 View Post
    Could you please stop arguing with the kernel devs please? The last thing you should be trying to do is make them feel salty. They have good reasons to feel the way they do. But I think there has to be a middle ground somewhere. And these conversations have to be civil and polite so that we have a real chance to figure out where that middle ground is. Right now your just sidetracking that AND WE -REALLY- NEED THAT TO BE ON THE MAIN TRACK INSTEAD.
    If you want to be super professional on the subject, then that's what the official mailing lists are for (you know, the ones where everyone uses their real names and not pseudonyms). Public forums (including Usenet groups), article comments sections and non-developer mailing lists have always been a peanut gallery and will probably continue to be that for the foreseeable future. If the maintainers can't stand having to put up with a peanut gallery, then they would do well to stay away from from the previously mentioned places.

    Leave a comment:


  • GreatEmerald
    replied
    Originally posted by Marc Driftmeyer View Post
    Thanks for the laugh. I see you don't include OS X in your highest code quality.
    I don't know enough about its standards. Does Apple have a public vetting process where they only accept high quality closely-integrated code the way Linux does? I assumed it was more like Windows, where everything is closed and nobody cares.

    Originally posted by smitty3268 View Post
    I'll probably get flamed for not just agreeing, but it's not really about having the highest code quality standards. It's about the fact that all the code is shared. On windows, the driver needs to include it's own functionality for a bunch of stuff, which is why those abstractions were all baked into the DC code to begin with. On linux, you're expected to use the common code if it's already out there rather than having your own flavor, in order to minimize maintenance costs. That's the case even if the shared code is technically worse than what you have - you need to improve the common code then rather than just not using it.
    Yes, by my point was that you can start by writing Linux code and then build up abstractions from there, rather than doing it the other way round.

    Leave a comment:


  • Luke_Wolf
    replied
    Originally posted by ?John? View Post
    Don't get me wrong, because I started using exclusively AMD GPUs ever since AMD resumed their open source efforts and they all work absolutely marvelous (to the point that I no longer even consider nVidia and actively discourage anyone else from using their binary crap), but how on Earth was this "display code" CLEANED UP from some 100kLOC ("93kLOC to run the displays when whole drivers don't even come close") to almost 130kLOC during at least 414 workdays (594 calendar days) of "this time trying real hard to get it absolutely right"⁈
    Not associated with the project at all, but I can speak from experience that code that is less abstract isn't going to be smaller generally, quite the opposite as appropriately applied abstraction tends to be DRYer when a project scales vs a less abstract approach.

    As an example let's say I've got an application designed in the MVC pattern, the controller could be designed in such a way that it's not abstract and when a command is invoked on it it runs through a gigantic conditional tree which quickly becomes an unmaintainable mess, or I could abstract the code and put all the commands into a container which I can then either loop through and activate based on what supports the command or use functional containers/LINQ/whatever to filter out the ones I want and use just them, and never have to touch that code again if I want to add more functionality with like 5-10 LOC vs a minimum 3*n + 3, where n is the number of commands needed to be supported.

    Another easy example, abstracting algorithms such as binary search means only having to deal with 1 copy as opposed to n copies for n types in a concrete implementation.

    The problem is not all abstractions are good abstractions, and not all languages are good at writing abstractions in. C in particular isn't too great at this, it can be done but you have to force it on the language. Hence why "muh UNIX Philosophy" is a thing to address this particular shortcoming of the language.

    Leave a comment:

Working...
X