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

  • #91
    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.

    Comment


    • #92
      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.

      Comment


      • #93
        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?

        Comment


        • #94
          Not default an the Rx 400 series?

          Comment


          • #95
            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.

            Comment


            • #96
              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?

              Comment


              • #97
                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.

                Comment


                • #98
                  Originally posted by GuercH View Post
                  so what do i get on Polaris if i enable this on the future?
                  Most importantly from my point of view: Working HDMI 2.0 support (and thus the ability to drive displays via HDMI at 3840x2160 60Hz) and HDMI audio output.

                  Comment


                  • #99
                    I haven't understood what said about Polaris, I think I'll buy a RX 480 in the next days and I would like to try the Freesync. Is it working with the open source driver? Only on DP or also on HDMI? I have to buy also a monitor and one, the Dell S2418H, doesn't have a DP port.

                    EDIT: to be sure, I choose a monitor with a DP port and a RX 570 (MSI Armor 4GB). At the end, the Dell was not an option, I missed that it's glossy!
                    Last edited by donbastiano; 06 October 2017, 02:13 PM.

                    Comment


                    • Polaris gets all sorts of bits fixed with each improvement to the DC code and the libdrm progress. Vega and Raven Ridge are first priority because they are the most recently released products [soon-to-be in Raven's part], which are both Vega based solutions. Basic Polaris support is already working as is evident by us Polaris RX 480 users typing in this forum via our displays. Basic support. Large Page support and more is coming and has been extended well beyond Vega [GFX 9] for mainline kernel support. All internal architectural changes and extended capabilities currently useless but part of the Polaris hardware are slowly being added.

                      UItimately, for some of us an actual OpenCL stack in mainline kernel that works so Blender, Darktable, GIMP and other commercial projects relying on properly functioning OpenCL w/o AMDGPU Pro driver, in any Linux Distribution is a feature still being worked on.

                      Having an OpenCL 2.x capable RX 480 being knee capped at OpenCL 1.1 is not ``fully functional'' in any sense of the definition. Having a broken 1.2 implementation with all sorts of bugs in AMDGPU Pro via ROCm is also not a fully functional solution. If AMD bet on Compute they sure as hell better be ready. So far, they aren't.

                      Just today: HEVC gets base encoding on UVD 6.3 within AMD DRM on Patchwork.freedesktop.org.

                      https://patchwork.freedesktop.org/patch/180209/

                      Read the patch from the link. Clearly, a lot was missing.
                      Add UVD encode write/read/size/base registers definition for uvd6.3 HEVC ecoding
                      Last edited by Marc Driftmeyer; 02 October 2017, 11:10 AM.

                      Comment

                      Working...
                      X