Originally posted by gorgamin
View Post
Announcement
Collapse
No announcement yet.
It Looks Like AMDGPU DC (DAL) Will Not Be Accepted In The Linux Kernel
Collapse
X
-
Originally posted by ihatemichaelWhy they didn't listen to Dave when he pointed out they've been wasting their time building this in the first place?
Comment
-
Originally posted by pal666 View Postthey have their kernel fork, which is the only thing which matters for subj
And that is whole story, linux devs traditionally wanna something very easy or as easiest as possibile maintanable but this one is nothing easy... for better picture of the whole story someone should just make a list of all features for Windows which are maded on top of DAL and to realise that thing tend to be huge
- Likes 1
Comment
-
As always if no one wanna these features, we can keep going with our tradition of generic buggy drivers It would be simple generic as always, we could consider them fine on average, but with features missing
And then when average Joe comes in and ask "why that does not work, it works on Windows for ages", devs should just answer "do not ask me why"Last edited by dungeon; 10 December 2016, 06:16 PM.
- Likes 1
Comment
-
Does even RHEL care about Desktop with opensource drivers ? I guess, most most most most most likely not ... install propertiary drivers there and move on And for those average rollers with opensource drivers, it is impossible to make straightforward distro with stock and recently also even signed kernels
Which one kernel is that where opensource drivers work fine for all intel, nouveau and radeon drivers You won't found it, it is never single one the best... as princess is always in another castle and further with userspace drivers too
And with that you have mass of people who roll kernels for no other reason than because of those shitty incosistent GPU drivers
Further as when you don't have that, there won't be a trusty distro ever ever ever ever ever possible with just oss drivers and there won't be Linux on DesktopLast edited by dungeon; 10 December 2016, 07:20 PM.
Comment
-
Originally posted by ihatemichaelIf he's so effective as you say he is, then why he keeps wasting time talking about stupid politics like "But attacking us or our corporate culture is not cool."
Originally posted by ihatemichaelWhy they didn't listen to Dave when he pointed out they've been wasting their time building this in the first place?
https://lists.freedesktop.org/archiv...ry/100566.html
Originally posted by ihatemichaelI follow development of open source projects (including drivers development) and this isn't anything new to me. What I'm saying is, instead of fixing his code why he keeps wasting time with drama?
You keep saying "keeps wasting time" but AFAIK we are talking about one email taking less than a minute to write. Is there a long history of dramatic emails I have somehow managed to miss or are you perhaps injecting the drama yourself ?Test signature
- Likes 1
Comment
-
Originally posted by Sonadow View PostThat implies the use of AMDGPU-PRO, doesn't it? What if I do not want to use AMDGPU-PRO, but instead stay on with a vanilla kernel + libDRM + Mesa stack? What will i expect to lose?Originally posted by Sonadow View PostBringing it up again because it dropped too far back and I believe this is the main question that most people want to know.
1. Turns out "lighting up" means different things to different people. I think of it as initial (in-house) bringup of a new GPU fresh from the fab, months before it goes to market, on an internal code branch. You may be thinking of it as meaning something else.
2. If you want to use DAL/DC with the all-open stack today, try installing only the kernel driver package from AMDGPU-PRO onto a distro that it supports. We plan to regularly QA that combination over time although not sure we are 100% testing it today.
3. Going forward we are thinking about formalizing #2, allowing us to release a ready-to-go all-open driver stack. The main reason for doing this would be to take advantage of the Kernel Compatibility Layer (KCL) code in the -PRO kernel driver (which is not allowed upstream) but in the short term it would also be a handy way to get DAL/DC while we are finishing the rework required for upstreaming.Test signature
- Likes 2
Comment
-
Originally posted by Sonadow View PostObviously the general populace will not have access to the hardware until launch day, so my definition of lighting up is that of
1) Works on the latest shipping version of the kernel (not git!) on launch day or shortly after launch with KMS
2) can output at up to 1440p over HDMI
3) Can hook onto the modesetting DDX driver
4) can talk with latest libdrm and Mesa to hardware accelerate a typical DE (like Gnome or Plasma)
#1, #2 and #3 are about getting a usable display. #4 is about actually using the hardware, and not falling back to software and llvmpipe to get the desktop drawn onscreen. I consider these four aspects to be the bare minimum of expectations with regards to any driver; if all 4 requirements are met, i deem the hardware as being successfully lit up.
Anything else like HDMI audio, FreeSync, etc etc are bonuses and icing on the cake that I can afford to wait longer for or live without for an extended period of time.
If you absolutely need latest shipping version of the kernel (which may be identical to git at times) then you'll probably need to wait for upstreaming. The AMDGPU-PRO focus is on enterprise/LTS distros and workstation/CAD markets, so while we will be closing the gap between bleeding edge and AMDGPU-PRO support over time the mere fact that it runs on a ~2 month release cycle means you won't get #1 that way.
Same with #4 - picking up an AMDGPU-PRO kernel driver only will give you a good chance of working with the libdrm and mesa which shipped in that distro, but no guarantees about being able to make a franken-stack with that kernel driver plus newer libdrm/mesa. The dependency hierarchy doesn't work that way... kernel + drivers usually should be newer than userspace, not older.
The real solution for what you want (if you insist on #1 and #4) is pulling from upstream. For #2 and #3 only we could satisfy that with a subset of DAL/DC functionality as we do for currently shipping parts, but every year the display logic gets more complex and power management becomes a bigger part of display logic expectations so the subset stopped being "simple" a while ago. Practically speaking you want an upstream driver with DAL/DC included, and that's where our focus is rather than than the subset functionality we ship upstream today.Last edited by bridgman; 10 December 2016, 08:19 PM.Test signature
- Likes 1
Comment
Comment