Southern Islands AMDGPU Support Almost Ready To Roll

[Amarildo]

please show any evidence that blob stuff matters to some people in 2018

As long as the OpenCL implementation is as good as the one on Catalyst, I won't shed a tear when AMD's closed-source drivers die

[Amarildo]

Then rest of you system is not compatible with latest mesa. I haven no problems with Debian testing Xfce and custom kernel 4.7.0-g1042343-dirty where I have enabled support for all GCN gpus.

So install those from here:

http://cdimage.debian.org/cdimage/stretch_di_alpha7/amd64/iso-cd/

https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa/+packages

https://cgit.freedesktop.org/~agd5f/linux/log/drivers/gpu/drm/amd?h=amd-staging-4.7

I don't know what you mean by that. I can install the latest anything git/svn on Arch (mesa, llvm, libdrm, linux) and they work fine. It's this amdgpu brand that doesn't work for me.

I was thinking of installing sid today, but I guess Ubuntu will come before. So first Arch, then Ubuntu with AMDGPU-PRO, and then Debian Sid.

[bridgman]

Because when using an analogy for something else, it's like saying: "A consumer reported a problem on an old version of a car we don't support anymore (this is a car manufacturer or a mechanic shop), the reported problem is that oil is leaking from "Pipe A". But since we don't have that car here, we can't say how to fix it". This doesn't make much sense because car manufacturers and mechanics would at least have a very accurate guess, something like "that car model has a very weak o-ring at pipe A, at least I could tell the person to look replace it".

Car analogies generally don't work with software development (or GPUs in general for that matter)... a better example would be "the reported problem is a buzzing noise around 30 MPH" where even having access to the factory service manuals and tools isn't going to help much unless you have seen a similar problem before on a similar model of car.

The devs have been pushing out "does this help ?" patches for years, but after a while you run out of ideas for fixing problems you can't see or reproduce.

[dungeon]

when i do such experiment bugzilla is empty.

Then you really don't have nose for it, 2018. is just 16 months away

[pal666]

This doesn't make much sense because car manufacturers and mechanics

are paid by you, while community developers are not

[pal666]

Then you really don't have nose for it, 2018. is just 16 months away

and old blob is not going to turn into pumkin on january 1st

[pal666]

As long as the OpenCL implementation is as good as the one on Catalyst, I won't shed a tear when AMD's closed-source drivers die

catalyst's opencl implementation will be opensourced

[starshipeleven]

Is that how it works? If a developer doesn't use it, he/she is not able to fix it?

Yes, the dev has to code blind and ask someone with the hardware to test it.

Because when using an analogy for something else, it's like saying: "A consumer reported a problem on an old version of a car we don't support anymore (this is a car manufacturer or a mechanic shop), the reported problem is that oil is leaking from "Pipe A". But since we don't have that car here, we can't say how to fix it". This doesn't make much sense because car manufacturers and mechanics would at least have a very accurate guess, something like "that car model has a very weak o-ring at pipe A, at least I could tell the person to look replace it".

This is what actually happens in real life too. You go to mech, he gets answer "we have no fucking clue" (assuming he isn't fed up of getting the same answer and tries at all), he tries to jury-rig something by looking at the hardware manuals that are usually out and easy to get.
This happens also on supported models usually, "we have no clue" is a standard answer.
That said, what if the issue wasn't just a shitty pipe that even a chimp can detect and fix with whatever other pipe that looks similar.

What if the issue was something more esoteric like a valve with wrong orientation that with time leads to malfunction or whatever?
You think the manufacturer knows? That they even fucking care?

No they don't and your mechanic can't do shit as any attempt to fix would require a LONG and EXPENSIVE diagnostic disassembly of the whole fucking engine, so they usually just tell you it's more economical to buy a new car or a new engine or whatever that isn't fixing the issue at hand.

Shouldn't that be applied to software developers too? They don't use the card, but they have access to source code and should be able to identify what the problem is and push possible patches for the user to try.

This happens, but if you have the card you speed up the process A LOT (also because not all bug reports also have people that can test it again) and do some weird-ass tests you can't really do remotely over a forum.

In general, this is also the reason some projects like dd-wrt (third-party firmware for routers) have a "donate a router if you want dd-wrt support for it" policy.

[starshipeleven]

The devs have been pushing out "does this help ?" patches for years, but after a while you run out of ideas for fixing problems you can't see or reproduce.

Would be useful if AMD could provide some kind of KVM (in the sense of keyboard, video mouse) test servers with the cards, so that some dev can go and try to reproduce there his issue.

I know it is a crude idea, but that's always been a shortcoming of open development that would be cool to address somehow. You AMD guys likely have access to all cards (i hope), but don't usually need it as you focus on the latest ones (for obvious reasons).
Other open developers might want to have some access to other cards but they can't just dump 500$ to buy all cards in AMD lineup back to 3000 line if all they do is fixing a few bugs in their spare time.

[bridgman]

Would be useful if AMD could provide some kind of KVM (in the sense of keyboard, video mouse) test servers with the cards, so that some dev can go and try to reproduce there his issue.

In most cases we have the cards somewhere in AMD, and remote access between developer systems is already very common... (most of the systems I work with are in Austin)... the problem is that in a lot of cases the problems won't repo on our card even if it does repo on a similar card somewhere else.

It also used to be very common for cards to show up in user systems which we have never heard of. I think we have enough hooks into the Windows teams now that we don't get surprised much any more though, but certainly we don't have every card model out there... not even close.