AMD Radeon RX 480 On Linux

[puleglot]

the reference design of the 480 is very good. it has relatively big output on the left end side duo to small display connectors(no big DVI) and it does even have a air input hole in the top right of the card what makes it a good crossfire card in small cases. in fact it is highend design.

I don't think so. The reference RX 480 cooler is very cheap. It's just a monolithic peace of aluminium with copper core (like the stock intel CPU cooler) + blower fan.

[Kano]

@puleglot

The limit can be only 8 bit output, but input should work (in theory). This is no HDR output, but at least you could see something. If you look at Hi10P (H.264) videos most ppl decode that to 8 bit output too - nobody cared so far - vdpau does not work for that too. You could try vainfo too if you like. vdpau has got HEVC_MAIN_10 decoder defined, so why not use it?

[pszilard]

I believe the OpenCL compiler path today is as follows....

Thanks for the clarification! That sounds more complex and even less "finalized" as I thought.

So the AMDGPU-PRO stack will always go through the HSAIL phase while the rock stack does (will) support both? How does the intermediate step impact code generation/optimizations? In particular (admittedly I'm not very familiar with the clang internals) I wonder how do these two paths affect the late optimizer stages and its ability to generate lean code and avoid irreversible transformations in intermediate phases (which AFAIUK were/are partly the reason for the previous OpenCL compilers' awful register management, and something that NVIDIA's compiler suffered to from badly in the past)?

Gory details, I know, but he answers are much appreciated.

BTW, is there a roadmap for the two stack, in particular the ROC + Lightning _stable_ release?

[efikkan]

but if you want to use opensource drivers you buy a 1060 ?

Most rational people want something that actually works well. When people have to run a firmware blob anyway, a kernel blob is not that big of a deal.
GTX 1060 will be available in 1-2 weeks, so stay tuned.

[bridgman]

So the AMDGPU-PRO stack will always go through the HSAIL phase while the rock stack does (will) support both?

Sorry, when I talked about OpenCL moving to ROCm and Lightning I meant "OpenCL in the AMDGPU-PRO stack".

How does the intermediate step impact code generation/optimizations? In particular (admittedly I'm not very familiar with the clang internals) I wonder how do these two paths affect the late optimizer stages and its ability to generate lean code and avoid irreversible transformations in intermediate phases (which AFAIUK were/are partly the reason for the previous OpenCL compilers' awful register management, and something that NVIDIA's compiler suffered to from badly in the past)?

That's pretty much the big hairy question of the compiler world AFAICS. Winning with toolchains seems to be simple in principle - identify the perfect IR from both code and dev tool perspective, implement toolchains around that IR, profit - but in practice there seem to be conflicting pressures on the IR from the code (complex & non-flat is better) and dev tool (simple and flat is better) perspective and the representations on both sides of the IR keep changing over time.

Having two levels of IR (one source-oriented and one target-oriented) is one solution but even that gets less than ideal when either source or target are changing rapidly. It's probably fair to say that source changes less (some variant of C++) and target changes more (OMG) these days. The other complication is the usual huge gap between processor speeds and memory latencies, which is managed pretty well in single-thread environments (caches tend to be big enough for working sets these days) but which becomes more complex in highly parallel implementations where you need to fit (#threads x working set of registers & heavily used variables) into RF+cache or performance plummets.

BTW, is there a roadmap for the two stack, in particular the ROC + Lightning _stable_ release?

Roadmap for ROC+Lightning is pretty simple:

- get it running and enabled as an option (done),
- live with it and finish solutions for the downsides of direct-to-ISA like portability of compiled code, and HSAIL dependencies in tools (in process)
- change HCC default to Lightning path when first two tasks are completed

Each of the first two steps is pretty time consuming although the third is quick and easy

OpenCL basically tracks the Lightning roadmap, so using HSAIL today (probably adding an option for Lightning path early if not there already) and changing default to Lightning when it is felt to be ready.

[bridgman]

Most rational people want something that actually works well. When people have to run a firmware blob anyway, a kernel blob is not that big of a deal.

Sure, except of course nobody is actually "running a firmware blob" they are loading hardware microcode into the GPU at power-up.

[Kano]

Well "running" is a vague description, somewhere it "runs". But I see no diff to a closed source firmware which was stored in the hardware itself. It has just something to do with the Debian or FSF definition of non-free. But current hardware needs that, so take it or use legacy hardware...

[cde1]

the reference design of the 480 is very good. it has relatively big output on the left end side duo to small display connectors(no big DVI) and it does even have a air input hole in the top right of the card what makes it a good crossfire card in small cases. in fact it is highend design.

Is it? I removed to cover to try and find the origin of my problem. It turns out the fan has a plastic base that is screwed in three places to the card. However this base itself is only attached in two points to the motor's PCB. In my card the third "arm" of the plastic base was broken (which is easy as it is not attached to the PCB), and so the whole fan was only really attached to the card by two screws, leading to one side protruding and rattling against the cover extremely loudly and almost not spinning.

So I fixed it with some cyanoacrylate, now the third arm is at the same level as the two others and the card is working fine. Still a disappointment; I'm not a fan of their design also unsure how this defect could not been seen in QA, considering the violent noise the card made.

[fuzz]

Most rational people want something that actually works well. When people have to run a firmware blob anyway, a kernel blob is not that big of a deal.
GTX 1060 will be available in 1-2 weeks, so stay tuned.

The open source drivers run without kernel version problems or dkms compilation issues and work out of the box. No hassle. No mess. This works the best. It's the holy grail of "it just works!"

Developers just need to stop using nonstandard opengl.

[artivision]

Most rational people want something that actually works well. When people have to run a firmware blob anyway, a kernel blob is not that big of a deal.
GTX 1060 will be available in 1-2 weeks, so stay tuned.

We never said that Nvidia must give to as an open graphics driver like RadeonSI, so their comments vs Linus middle finger for patents and the best closed graphics driver are irrelevant. We wanted an open kernel driver like AMD_GPU to cover open power management, slots and other problems. Imagine if you bought an Intel CPU and you could only run it at 1Ghz, then Intel tells you that they will give you documents to code the overclocking your self.

I just want you to understand when a comment is that stupid and it really annoys people.