AMD just wasted the last 2 years on useless drivers

lists.freedesktop.org/archives/dri-devel/2016-December/126516.html


Daniel has said this all very nicely, I'm going to try and be a bit more direct, because apparently I've possibly been too subtle up until now.

No HALs. We don't do HALs in the kernel. We might do midlayers sometimes we try not to do midlayers. In the DRM we don't do either unless the maintainers are asleep. They might be worth the effort for AMD, however for the Linux kernel they don't provide a benefit and make maintaining the code a lot harder. I've maintained this code base for over 10 years now and I'd like to think I've only merged something for semi-political reasons once (initial exynos was still more Linuxy than DC), and that thing took a lot of time to cleanup, I really don't feel like saying yes again.

Given the choice between maintaining Linus' trust that I won't merge 100,000 lines of abstracted HAL code and merging 100,000 lines of abstracted HAL code I'll give you one guess where my loyalties lie. The reason the toplevel maintainer (me) doesn't work for Intel or AMD or any vendors, is that I can say NO when your maintainers can't or won't say it.

I've only got one true power as a maintainer, and that is to say No. The other option is I personally sit down and rewrite all the code in an acceptable manner, and merge that instead. But I've discovered I probably don't scale to that level, so again it leaves me with just the one actual power.

AMD can't threaten not to support new GPUs in upstream kernels without merging this, that is totally something you can do, and here's the thing Linux will survive, we'll piss off a bunch of people, but the Linux kernel will just keep on rolling forward, maybe at some point someone will get pissed about lacking upstream support for your HW and go write support and submit it, maybe they won't. The kernel is bigger than any of us and has standards about what is acceptable. Read up on the whole mac80211 problems we had years ago, where every wireless vendor wrote their own 80211 layer inside their driver, there was a lot of time spent creating a central 80211 before any of those drivers were suitable for merge, well we've spent our time creating a central modesetting infrastructure, bypassing it is taking a driver in totally the wrong direction.

I've also wondered if the DC code is ready for being part of the kernel anyways, what happens if I merge this, and some external contributor rewrites 50% of it and removes a bunch of stuff that the kernel doesn't need. By any kernel standards I'll merge that sort of change over your heads if Alex doesn't, it might mean you have to rewrite a chunk of your internal validation code, or some other interactions, but those won't be reasons to block the changes from my POV. I'd like some serious introspection on your team's part on how you got into this situation and how even if I was feeling like merging this (which I'm not) how you'd actually deal with being part of the Linux kernel and not hiding in nicely framed orgchart silo behind a HAL. I honestly don't think the code is Linux worthy code, and I also really dislike having to spend my Friday morning being negative about it, but hey at least I can have a shower now.

No.

Dave.

Other urls found in this thread:

lists.freedesktop.org/archives/dri-devel/2016-December/126684.html
wiki.gentoo.org/wiki/Amdgpu
libv.livejournal.com/
github.com/VerticalResearchGroup/miaow
twitter.com/NSFWRedditImage

And Nvida just spend the last 2 years burning down people's houses. Hardware companies fucking suck.

So now what, is my card useless or will they attempt to fix this?

We need a fourth relevant competitor

Yep, and in this case it's entirely AMD's fault. They just sat in their ivory tower and came up with the great idea they could build a common driver abstraction layer for Windows, Linux, BSD and console platforms. Not once did they consult with the Linux kernel maintainers to see if it would be a good idea and have continued down the same path even when they were warned a year ago when they first submitted the DAL code.

If they want to reduce the burden in validation and conformance testing, they should have invested their time into developing some DSLs and compile-time source translation framework instead of a rigid runtime HAL.


AMD hasn't replied since Dave Arlie dropped the hammer. Wonder if people are losing their jobs over this. Their morale is probably rock bottom right now, wouldn't be surprised if some people just fucking quit after the holidays.

It's not useless, AMDGPU as it currently exists is fine and Mesa is just going to keep getting better and better, although you still don't have HD audio. Problem is going to be with Vega GPUs and later, they were relying on this new code. Shit for HDMI 2.0, 4k output, crossfire, HD audio, etc.

It is since the beginning because AMD requires blobs

The likehood of that happening is almost zero.
Too much problem:
-Being fucked by the competitors over the years
-you need a team of engineers
-Find the components if you don't make them
-Find the natural resources all over the world (tantalum, cooper, Africa, Asia etc...)
-buy a assembly chain
-All the marketing around it
-Code the dam thing from point 0 aka= 5years if not more of work.
-add a license to the software and at that point you surely have shareholders who aren't okay with you releasing the software under GPLv3
et cetera
et cetera

I think Intel Graphics is the only way to get a reasonable video capabilities in linux

Maybe if you're stuck with redhat or debian for the next year, but if you're using a rolling or source-based distro, AMDGPU plus latest Mesa is pretty damn good on AMD.

It's easier to just cut your requirements.


You'll always be a slave to the jews, with desires like that. Always wanting latest video codec and games. You're on the treadmill forever.

Intel is not only incompetent, they're iniquitous.

I hope this isn't all work down the drain for AMD. Nvidia needs a serious competitor to keep them in check or they keep reverting to their true (((nature))).


Their Windows drivers had the same problem for a couple years too.

Can you translate this into English OP?

They use Wifi as an example, because the guys who wrote the Linux wifi drivers all made up their own implementations for shared things and it got too complex.
They're basically telling AMD to not reinvent the wheel, and if the current versions of the things they're reimplementing aren't good enough they should fix them instead of writing their own.

...

This seems suspiciously incompetent. How did this situation arise?

Usually this corresponds to upper or mid level management involvement.

In the followup the fag basically says that AMD gives no shit about Linux and cannot spare money to develop proper software.

I thought this was about the blob, and not the open driver?

People in burning houses held together with woodscrews shouldn't throw stones :^)

Good thing I'm not a lincuck user

I have a feeling it involves poo, but does not involve the loo

Samsung
LG
Sony
Panasonic
Hell even the foundries

People in hell want ice water

Why would you crack MD5 and not MD6?

What song?

Isn't this Tatsuro Yamashita? I swear that it sounds like him

don't see any seeders

I used to think I got abducted but after years of theraphy found out that I was getting sexually abused by my mother. The greys were just me covering up a traumatic events

Weird fetish stuff? You do realize what thread youre on, right?

And how do you think i assume how its like?

Wait we talking pussies or vaginas?

why the fuck not faggot?

There has been a response,

lists.freedesktop.org/archives/dri-devel/2016-December/126684.html


REKT

Do you live in a hospital?

meh
The amd team is still faulty.
Bullshit you just have to fucking go in the mailing list and ask questions.

This is THE thing and the only thing that matters and it's called COMMUNICATING if amd would have been more in touch with the linux kernel team this shit wouldn't have happened.

Also if they had developed userland drivers like the hurd supports this shit wouldn't have mattered at all.

I sure do. R200 has gone backwards since AMD took over and shit firmware blobs all over it. AtomBIOS was a mistake. 10 years ago they promised OpenCL and we're still fucking waiting for 1.2 while Intel's integrated trash has fucking Vulkan. Hell, they still haven't shipped a driver that can do OpenGL 4 on radeons that support it.

AMD are a bunch of fucking liars like the rest of the graphics world.

The opensource driver (its "free" by gpl standards) depends on several large non-free firmware blobs depending on the card.

wiki.gentoo.org/wiki/Amdgpu

So basically a free wrapper. wew

the GPU industry is completely cucked at this point.

Intel is going the blob route for their integrated graphics now, and in the future.

The best thing that could possibly happen is someone steals the Larrabee idea and reimplements it using RISC-V. Let's just softpipe everything on a 4096-core CPU.

At least we have the nouveau driver

But if you wonder why their isn't more free/libre drivers read this:
libv.livejournal.com/

This is what happens when you try to make a free/libre driver for ARM cpus (pic related)

I don't know why AMD are spending a cent on Linux tbh, particularly when they're not wanted.

Graphics is now for cucks, real men use text only.

So how much of what GPUs do is controlled by the driver and how much is controlled by the firmware? When Nvidia or AMD release a driver update are they just releasing improved firmware and keeping the driver the same?

Yeah, Year of the Linux Desktop will never happen at this rate.

Sounds good to me. I don't care if no modern games run on it. Give me a good KSP libre clone and I'll be happy for years. I just want my freedom at this point.

how hard would it be to make your own drivers?

Do you have documentation for the hardware? If so, not terribly. If you don't, then you have to get documentation first, usually by reverse engineering the hardware so you can find out what instructions do what, what memory addresses are used for what, etc.

I want to use an FPGA to create my own GPU maybe have it open source so others can improve it.

An old classic Mac, or Amiga, even Atari ST had working desktop. The "deskto" word was twisted and corupted beyond meaning, so now it implies HD 3D games and latest trendy shit. The price to pay for that is selling your soul (freedom) to hardware jews. But in reality, nobody really needs it, it's manufactured need. That's what they do to sell you shit and constantly make you upgrade.

So does this mean AMDGPU is kill?

Some guys have already done something similar based on an older AMD GPU, available at github.com/VerticalResearchGroup/miaow

They'd probably be better to ask about this than a bunch of idiots on an image board.

no, it means AMD needs to do more work if they want to integrate their code into the linux kernel so that their code follows the same practices the maintainers do.

You can still download AMDGPU drivers they just won't be integrated into the kernel.

Linux maintainers don't want to allow AMD to be special snowflakes because it causes a ton of maintenance problems down the road. AMD doesn't have the manpower to re-write 100,000 lines of code to follow linux best practices.

that's all this is

Based AMD

Lets be honest here, ATI wasted 2 decades on useless drivers before AMD continued the tradition.

The 9800xt was my first and last ATI / AMD simply due to driver errors causing artifacts in games.

I really wish AMD was competent as it would lead to competition and be better for the customers but it just isn't the case. Maybe a 3rd party will enter the CPU / GPU market and get things moving again.

To be fair, at nVidia they aren't even dreaming to do what AMD tried to do, instead they wrote a proprietary module which has no chance to come anywhere near being incorporated into linux.

why

See , , and

Pretty much everything is controlled by the blobs
Only 2d acceleration is enabled
You don't have power saving
You don't have luminosity control
You don't have 3D acceleration
You can't even have the correct resolution.
AMD is poozed to the core and Nvidia too.

If it weren't for the nouveau team and some great people like the guy in the link that posted graphics would be shit to the core.
But we would have also a lot less trouble if the drivers were in userland (hurd 0.9 in a few day)

Thanks user, I appreciate the time it took to write the post.

So that's what Terry Davis was talking about when he said graphics functions shouldn't be hidden by the GPU. What he does is starting to make more and more sense to me.

So basicly down to the same situation as NVIDIA is right now.
Blobs or HALs, linux kernel devs have unhealthy obsession with clean kernels (despite forking all the support for massive companies like RedHat).
I understand nobody wants to create another Windows but expecting hardware companies to open source their schematics to make a driver (trade secrets in GFX business) is kinda ridiculous.
It makes sense with tiny hardware vendors perhaps but these are GIANT companies with thousands of patents.

How about no?

Well good luck getting no market share.

I'd take less bloat and potential for vulnerabilities over more market share any day. How do I benefit from more people using the same OS as me while at the same time the OS gets bloated and vulnerability ridden when every company starts dumping massive amounts of code into the kernel so that their products can reuse the Windows drivers as well?

Well good luck staying irrelevant to the average consumer.

Pretty much every hardware company is like that. Intel and Nvidia are using blobs too, they aren't listening to the Linux community, the Linux community has to take what they can get. Their Linux support departments are given a tiny fraction of the resources that Windows support gets.

The Linux devs are living in a fantasy world if they think hardware vendors are going to start bending over backwards for them. Unless they provide some clear incentive, like increasing Linux market share on the desktop, it's not going to happen. Businesses are not buying Linux servers with crossfired R9 Furys and playing Doom on them. There is no benefit from a business perspective to invest in better support.

They however aren't expecting the Linux devs to let them add a fuck ton of code to the kernel to support their blobs that will result in more bloat and potential vulnerabilities.

REKT REKT
REKT REKT
REKT REKT
REKT REKT
REKT REKT
REKT
REKT REKT
REKT REKT
REKT REKT
REKT REKT
REKT REKT

I WANT MY MOAR CORES AMD ZEN PROCESSOR UNTIL RISC-V. I WANT MY AMD GRAPHICS TO RUN VULKAN. MOAR CORES AND VULKAN = BETTER NUMERICAL COMPUTING.

AMD really needs linux badly.
For compute loads. The fact that they think they're going to convince anyone with this stupidly contrived "lmao we're so generous to the linux desktop, we don't have to do this, maintain our shit code faggots" is hilarious.
AMD needs Linux right now more than Linux needs AMD. Meanwhile, NVIDIA software breaks on every kernel change, but it does work. That's the poison of having to maintain your own shit.
If AMD wants it in the kernel and doesn't want to maintain it, they have to play ball.
People told them this would happen, but they didn't listen. They apparently think that Linux maintainers embrace and welcome code that makes a maintainers life more difficult.

Because this isn't about the linux desktop. This is about compute workstation/servers.

No, they're not playing doom on them, but they do want to buy them for compute. You're retarded.

No it is for mobile as that is where the bulk of AMD chipsets are running with Linux.

That too, but it doesn't change the fact that they also have to do this for compute, in the context of their discrete graphics cards.
It's not about "le desktop linux" at all
Anyone who says that AMD is doing this out of the kindness of their hearts and maintainers should swallow the pill because "it's so good for desktop! AMD is so kind! they are doing this out of the kindness of their hearts for desktop!" are fucking retarded.
And so are the developers who thought they could satisfy kernel maintainers with this slop.

When do they do that? Aren't most of the kernels that phones use not mainlined and the manufacturer just compiles shit like that for the phone?

Wait a minute, doesn't that violate the GPL since manufacturers won't give out the kernel code for their phone?

This kills the FOSS.

When they merged Google's ext4 encryption patch for example. Linux on desktops and servers has no need for that.
They just add their driver modules, I don't think they add any features.
They load their proprietary code through modules and blobs, they are still required to give you the kernel source though, but it's perfectly fine with the GPL if they require you to send them a letter requesting it first.

Yeah, that's not a good example at all.

We don't need you, zombie