Announcement

Collapse
No announcement yet.

The Slides Announcing The New "AMDGPU" Kernel Driver

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

  • Originally posted by Luke_Wolf View Post
    ... Intel decided that Kernel modesetting as opposed to User modesetting would give them really neat features. AMD said "Cool Bro, Let me in on some of that", and Linus was all "Cool Man dish it up" meanwhile the BSDs were all "But Bros... We like Userspace Modesetting" and so the BSDs decided to sit on the Userspace Modesetting, thinking that it was just going to be a temporary thing, while the rest of the world ...
    With "the rest of the world" you mean the Linux houses.

    ... moved on and decided "We like this KMS thing", until recently where the BSDs finally realized that no, in fact the world ...
    Again, with "the world" you mean the Linux houses.

    ... would not be going back to UMS anytime soon and so have finally decided to move to KMS, and it's going to take them a while to finish.

    Seriously though the fact that the BSDs got left behind is nobody fault but their own, as demonstrated by the fact that between the various BSDs there's around a dozen developers now working on this problem. If they hadn't decided "UMS FTW!" ...
    UMS was already there.
    Maybe the BSDs thought the benefit of switching from UMS to KMS doesn't outweigh the disadvantages?
    Maybe there were more reasons than only laziness?

    ... All 3 XDC Presentations said so, and the unrepresented NetBSD was mentioned as doing the same developments
    But AFAIK the reason is not to accept the UMS/KMS decision, but to accept the inevitable i.e. the open source graphics developer of today care only for Linux/KMS.

    Comment


    • Originally posted by drSeehas View Post
      With "the rest of the world" you mean the Linux houses.


      Again, with "the world" you mean the Linux houses.
      By the Rest of the world I mean all major modern open source graphics drivers (As well as Nvidia and AMD's Blobs) being developed today. WDDM seems to work kind of like this to my understanding too, I don't know about what OS X is doing in that regard.

      Originally posted by drSeehas View Post
      UMS was already there.
      Maybe the BSDs thought the benefit of switching from UMS to KMS doesn't outweigh the disadvantages?
      Maybe there were more reasons than only laziness?
      Where was I implying laziness in the UMS vs KMS decision? They were on the wrong side of the debate, they lost because they thought UMS was better, and they ignored what developers were doing and how they were moving, which meant that in the end they got left behind and are now having to catch back up.

      Originally posted by drSeehas View Post
      But AFAIK the reason is not to accept the UMS/KMS decision, but to accept the inevitable i.e. the open source graphics developer of today care only for Linux/KMS.
      because the BSDs made their bed and now they have to sleep in it. Ultimately this choice though is out of laziness albeit the good kind of laziness though as it results in a significant reduction in their workload as they then just have to keep up with interfaces as opposed to porting the whole drivers and thus have a significant diff vs upstream.

      Comment


      • Originally posted by bridgman View Post
        We can't make the open driver any more open
        Well, AMD could release the toolchain and source code to the firmware blobs. Also, as some coreboot users have learned, the driver needs a proprietary video BIOS to work.

        Comment


        • Originally posted by chithanh View Post
          Well, AMD could release the toolchain and source code to the firmware blobs. Also, as some coreboot users have learned, the driver needs a proprietary video BIOS to work.
          I think what you're asking is how difficult is it to reverse engineer/steal the IP of a proprietary video BIOS if the firmware is available in open source code? Probably a lot easier than reverse engineering a closed source firmware blob.

          Comment


          • Originally posted by MartinN View Post
            I think what you're asking is how difficult is it to reverse engineer/steal the IP of a proprietary video BIOS if the firmware is available in open source code? Probably a lot easier than reverse engineering a closed source firmware blob.
            He's talking about two different things -- unfortunately they both get referred to as "firmware blobs" which leads to all kinds of wrong conclusions. First sentence refers to hardware microcode images which do not run on the CPU and have nothing to do with the driver other than the fact the driver loads them into the HW as part of initialization. Some vendors build microcode into the HW, others store in flash on HW or build in initial code then patch it with a CAM loaded during initialization, we load the entire image into HW during initialization.

            Second sentence refers to command and data tables in the video BIOS code, where the command tables do run on the CPU via an interpreter included in the driver source. The interpreter is open source, and an open source disassembler was produced by the SUSE team as part of initial radeonhd development work.
            Test signature

            Comment


            • Originally posted by chithanh View Post
              Also, as some coreboot users have learned, the driver needs a proprietary video BIOS to work.
              The content of the data and command tables in the vbios that are used by the driver are completely documented in the open source driver. The content of those tables however is very board specific however.

              Comment


              • What does UMD stand for?

                Comment


                • Originally posted by Nille_kungen View Post
                  What does UMD stand for?
                  User Mode Driver. Basically the usermode acceleration drivers for OpenGL, OpenCL, multi-media, etc.

                  Comment


                  • Originally posted by agd5f View Post
                    User Mode Driver. Basically the usermode acceleration drivers for OpenGL, OpenCL, multi-media, etc.
                    Thank you now my mind can move on it was bugging me that i didn't connect what it's short for.

                    Comment

                    Working...
                    X