Announcement

Collapse
No announcement yet.

AMDGPU DC Display Code Tacks On Another 28 Patches

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

  • #51
    Originally posted by duby229 View Post
    And that exactly the point. Nothing comes from the pro driver despite years old promises.
    OK, now you've completely lost me. What "years old promises" ?

    Are you talking about open sourcing the Vulkan driver (which would then not be part of pro driver anyways).

    We aren't open sourcing Vulkan just so it can be picked apart and used in radv. I did briefly raise that as a possibility when Dave told us about radv but internal consensus was to stay with the plan.
    Test signature

    Comment


    • #52
      Originally posted by bridgman View Post

      OK, now you've completely lost me. What "years old promises" ?

      Are you talking about open sourcing the Vulkan driver (which would then not be part of pro driver anyways).

      We aren't open sourcing Vulkan just so it can be picked apart and used in radv. I did briefly raise that as a possibility when Dave told us about radv but internal consensus was to stay with the plan.
      Don't you think that's what the problem is?

      Comment


      • #53
        Originally posted by juno View Post

        HDMI spec itself (wait for HDMI 2.1). Likely, newer AMD chips will support it, as the Xbox One X is said to.
        But why at all use HDMI when DP has been there for a long time?
        Huh? Its been a thing for ages already. Freesync/HDMI monitors are cheaper, so, you know that's nice when you don't have a lot of money. Its been working fine in Windows for a long time now, its just no one has yet set it up for Linux. I'm just curious whats all that different from Freesync/DP vs Freesync/HDMI that's making the latter apparently difficult enough to enable to the point no one's bothered with it yet.

        Comment


        • #54
          Originally posted by bridgman View Post

          The problem is not lack of documentation, the problem is that the complexity of modern display hardware results in too *much* documentation. There are literally thousands of pages of documentation that would have to be distilled down to some kind of mega-programming-guide, and that would be every bit as much work as writing the driver. The same is true for a number of other blocks as well.

          Remember that the goal of this initiative is to implement a framework which allows the HW and diags people to contribute directly to the upstream driver, rather than having them write validation code in one format and then have SW teams re-implement for production drivers.
          Here is a good example where incomplete documentation has probably amplified the work required to implement a feature a thousand times: https://airlied.blogspot.fi/2017/07/...mo-no-fps.html

          If that is the reality for an engineer working on implementing AMD support, i have ZERO surprise it is not advancing at a sane pace. The ten or so guesses mentioned there should simply have no need to exist, the solution should have been obvious by reading a paragraph in a pdf that documents the hardware. Having to reverse engineer the proprietary driver to find what needs to be done is on-par with implementing open source support for nvidia.
          Last edited by varikonniemi; 14 September 2017, 04:32 AM.

          Comment


          • #55
            Originally posted by salsadoom View Post
            Huh? Its been a thing for ages already. Freesync/HDMI monitors are cheaper, so, you know that's nice when you don't have a lot of money.
            They are not cheaper, the exact opposite is true. I don't know why anybody cares for HDMI when it used to be years behind technically and they are charging fees and royalties. And yes, it is a thing, a proprietary one between AMD and a few monitor manufacturers to be precise. The HDMI 2.0 spec doesn't have variable refresh rate, DisplayPort spec does have it with Adaptive Sync in 1.2a.
            Last edited by juno; 14 September 2017, 03:10 PM.

            Comment


            • #56
              Originally posted by pal666 View Post
              linux dev community have datasheets for r600 and ten years later it still didn't implement opengl support and switched to implementing radv
              Quite a lot of recent work for r600 isn't in the datasheets and had to be reverse engineered from fglrx. (atomc counters etc.)

              Comment


              • #57
                Originally posted by varikonniemi View Post
                Here is a good example where incomplete documentation has probably amplified the work required to implement a feature a thousand times: https://airlied.blogspot.fi/2017/07/...mo-no-fps.html
                that is a good example where someone uselessly wastes time for fun, writing already written code
                Originally posted by varikonniemi View Post
                The ten or so guesses mentioned there should simply have no need to exist, the solution should have been obvious by reading a paragraph in a pdf that documents the hardware. Having to reverse engineer the proprietary driver to find what needs to be done
                nothing in that blogpost(except your wishful thinking) suggests it was issue with documentation. documentation does not say how to write fastest program. you have to do it and measure. amd vulkan devs invested their time and got faster program. airlied just piggybacked on their work
                Last edited by pal666; 15 September 2017, 05:26 PM.

                Comment


                • #58
                  have to say the latest 4.12 staging kernel is looking very nice, pretty smooth experience with the unigine benchmarking, no issues with contrast, aside from flash crashing the computer some times, its working pretty well (except for the flash issues). Hope it makes it in to the official kernel source soon.

                  *Frontier Edition / Gentoo / amd-staging-4.12
                  Last edited by pcxmac; 19 September 2017, 06:35 AM.

                  Comment


                  • #59
                    One of the recent patches in amd-staging-drm-next prevents X11 from starting for me - I filed a bug report on this under https://bugs.freedesktop.org/show_bug.cgi?id=102820

                    Comment


                    • #60
                      Originally posted by pal666 View Post
                      then you should do independent open source effort, because when you only give advice from couch, windows code exists and works
                      you mean contribution and running an whole source distribution since 1998 (T2, formally ROCK Linux) and contribution to each project from the kernel, over gcc, firefox, chrome, and running various whole open source project like exact-image? https://t2sde.org https://exactcode.com/opensource/exactimage/ https://exactcode.com/opensource/saneavision/

                      Comment

                      Working...
                      X