Originally posted by agd5f
View Post
Announcement
Collapse
No announcement yet.
The Slides Announcing The New "AMDGPU" Kernel Driver
Collapse
X
-
-
Originally posted by chithanh View PostAlso, as some coreboot users have learned, the driver needs a proprietary video BIOS to work.
Leave a comment:
-
Originally posted by MartinN View PostI 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.
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.
Leave a comment:
-
Originally posted by chithanh View PostWell, 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.
Leave a comment:
-
Originally posted by drSeehas View PostWith "the rest of the world" you mean the Linux houses.
Again, with "the world" you mean the Linux houses.
Originally posted by drSeehas View PostUMS 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?
Originally posted by drSeehas View PostBut 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.
Leave a comment:
-
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 ...
... 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!" ...
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
Leave a comment:
-
Originally posted by drSeehas View PostI 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.
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
Leave a comment:
Leave a comment: