[RFC] Using DC in amdgpu for upcoming GPU

Dave Airlie airlied at gmail.com
Thu Dec 8 23:29:44 UTC 2016

> No.

I'd also like to apologise for the formatting, gmail great for typing,
crap for editing.

So I've thought about it a bit more and Daniel mentioned something
useful I thought I should add.

Merging this code as well as maintaining a trust relationship with
Linus, also maintains a trust relationship with the Linux graphics
community and other drm contributors. There have been countless
requests from various companies and contributors to merge unsavoury
things over the years and we've denied them. They've all had the same
reasons behind why they couldn't do what we want and why we were
wrong, but lots of people have shown up who do get what we are at and
have joined the community and contributed drivers that conform to the
standards. Turning around now and saying well AMD ignored our
directions, so we'll give them a free pass even though we've denied
you all the same thing over time.

If I'd given in and merged every vendor coded driver as-is we'd never
have progressed to having atomic modesetting, there would have been
too many vendor HALs and abstractions that would have blocked forward
progression. Merging one HAL or abstraction is going to cause pain,
but setting a precedent to merge more would be just downright stupid

Here's the thing, we want AMD to join the graphics community not hang
out inside the company in silos. We need to enable FreeSync on Linux,
go ask the community how would be best to do it, don't shove it inside
the driver hidden in a special ioctl. Got some new HDMI features that
are secret, talk to other ppl in the same position and work out a plan
for moving forward. At the moment there is no engaging with the Linux
stack because you aren't really using it, as long as you hide behind
the abstraction there won't be much engagement, and neither side
benefits, so why should we merge the code if nobody benefits?

The platform problem/Windows mindset is scary and makes a lot of
decisions for you, open source doesn't have those restrictions, and I
don't accept drivers that try and push those development model
problems into our codebase.


More information about the dri-devel mailing list