The Slides Announcing The New "AMDGPU" Kernel Driver

[Nille_kungen]

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.

[agd5f]

What does UMD stand for?

User Mode Driver. Basically the usermode acceleration drivers for OpenGL, OpenCL, multi-media, etc.

[Nille_kungen]

What does UMD stand for?

[agd5f]

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.

[bridgman]

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.

[MartinN]

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.

[chithanh]

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.

[Luke_Wolf]

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.

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.

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.

[drSeehas]

... 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.

[Luke_Wolf]

I see it different:

Once upon a time in the old days of FOSS the developers wanted their software tu run on as much as possible OSs or in your analogy: fit in as much as possible houses. Both, the *BSD and Linux houses, were treated equally and were fully functional, working, usable and livable houses "with all kinds of expansions and neat features".

Then some day the makers for e.g. the windows (ha!) decided to only support the Linux houses.
A window consist among other things of the frame and the glass. The *BSD houses (were forced to) keep the old frames and only one glass maker (nVIDIA) still supports at least one of these old frames in the *BSD houses.

Now another glass maker (AMD) announces the development of a new glass. Wouldn't it be a good idea to develop this new glass in a way, that it will fit also in the old frames of the *BSD houses?
If the glass maker of the new glass cares about the *BSD houses it would visit these houses and look how these old frames are designed so the new glass will fit easily into these old frames.

Yes, I know, the story above is simplified.


In short you say the *BSDs should go the Linux way as DragonflyBSD plans already.

Actually It went more like:
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 moved on and decided "We like this KMS thing", until recently where the BSDs finally realized that no, in fact the world 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!" they wouldn't need to be working on catching up now.

Also it's not just me saying it, All 3 XDC Presentations said so, and the unrepresented NetBSD was mentioned as doing the same developments