AMD Radeon HD 7970 On Linux

[crazycheese]

I read most of that article but didn't see the reference, and searching for "six" on the first page didn't give any matches. Was it supposed to be on the first page, or one of the later ones ?

There are a lot of references to leaks of product information going back six months or so, but that's all I could find.

Oh, sorry, didn´t I took openbenchmarking wrapper all-long. Its this one.

[bridgman]

Ahh, that part. Sorry, I did see that but kind of "filtered it out" in my head because I was looking for open source references.

That text is referring to events like AFDS and others, where we expose architectural information to give application and toolchain developers a heads-up. The information we provide at that point doesn't include anything like the level of detail required for driver development, however.

Thanks !

[RussianNeuroMancer]

May you say some details about UVD4 and PowerTune support in open source driver now? Or there is still embargo for such information?

[bridgman]

I haven't looked much at UVD in the latest GPUs but I thought they were still UVD 3. Can't really talk much about UVD at this point because I don't know what we are going to be able to release, although we are going to take another look in the new year.

I don't think we have looked at PowerTune specifically; my guess is that the first chance to do that will be a few months from now. There are some more fundamental power management improvements I would like to get out first, and they will probably be a pre-requisite for PowerTune anyways.

[liam]

Actually quite the opposite.. the plan is for the new compiler code to go into the Gallium3D driver and process GCN graphics shaders (after adding GCN instruction generation, of course) along with compute for all architectures, while pre-GCN graphics shaders will go through the existing r600g compiler/translator.



Agree 100%. The problem is that you can't ignore the DRM/UVD issues.

Thanks for responding.
I'm not sure I follow you. It SEEMS as though you are saying you will use the open sourced compiler for the old r600 while the new diver will switch to the new one. I apologize if I've misunderstood.
Lastly regarding drm I was attempting to give the impression that since hybrid mode will do most of the work through the CUs we could ignore the small bit that the uvd handles and thus not use uvd at all thus ignoring drm

Happy holidays!

Liam

[bridgman]

I'm not sure I follow you. It SEEMS as though you are saying you will use the open sourced compiler for the old r600 while the new diver will switch to the new one. I apologize if I've misunderstood.

It's confusing because we used to only talk about graphics workloads (with the assumption that compute could flow through the same path) but now we're talking about different paths for graphics and compute, at least in some cases.

Current thinking (if I remember it correctly ) is to tweak the pipe driver API to accept different IR formats (ie other than TGSI) then :

For 6xx-NI graphics the Gallium3D pipe driver will receive TGSI shader programs from Mesa then use the existing code which converts vector TGSI operations directly into VLIW GPU operations

For 6xx-NI compute the Gallium3D pipe driver will receive LLVM IR kernel programs from clover (or other compute front ends), then use "part 2" of the newly released code to generate VLIW GPU instructions from the LLVM IR (may not make great use of the VLIW at first)

For GCN graphics the Gallium3D pipe driver will receive TGSI shader programs from Mesa, use "part 1" of the newly released code to convert TGSI to LLVM IR, then use "part 2" to generate GCN GPU instructions from the LLVM IR

For GCN compute the Gallium3D pipe driver will receive LLVM IR kernel programs from clover (or other compute front ends) then use "part 2" of the newly released code to generate GCN GPU instructions from the LLVM IR

I drew a picture on a whiteboard at work of all this yesterday showing Catalyst OpenCL, clover OpenCL and Mesa with all the different code paths and scenarios. Should have taken a picture of it before erasing, sorry.

Lastly regarding drm I was attempting to give the impression that since hybrid mode will do most of the work through the CUs we could ignore the small bit that the uvd handles and thus not use uvd at all thus ignoring drm

That is definitely doable, and we'll probably do more work in that direction if it turns out we can't open UVD etc.., but the "small bit" handled by the fixed function hardware is the entropy encode/decode (CABAC, CAVLC etc..) which is still stubbornly expensive to implement on CPU or GPU. Motion estimation, motion comp and filtering are inherently parallel and a decent fit for shaders, but I don't think anyone has come up with a sufficiently parallel algorithm for entropy encode/decode yet.

[liam]

It's confusing because we used to only talk about graphics workloads (with the assumption that compute could flow through the same path) but now we're talking about different paths for graphics and compute, at least in some cases.

Current thinking (if I remember it correctly ) is to tweak the pipe driver API to accept different IR formats (ie other than TGSI) then :

For 6xx-NI graphics the Gallium3D pipe driver will receive TGSI shader programs from Mesa then use the existing code which converts vector TGSI operations directly into VLIW GPU operations

For 6xx-NI compute the Gallium3D pipe driver will receive LLVM IR kernel programs from clover (or other compute front ends), then use "part 2" of the newly released code to generate VLIW GPU instructions from the LLVM IR (may not make great use of the VLIW at first)

For GCN graphics the Gallium3D pipe driver will receive TGSI shader programs from Mesa, use "part 1" of the newly released code to convert TGSI to LLVM IR, then use "part 2" to generate GCN GPU instructions from the LLVM IR

For GCN compute the Gallium3D pipe driver will receive LLVM IR kernel programs from clover (or other compute front ends) then use "part 2" of the newly released code to generate GCN GPU instructions from the LLVM IR

Obviously you would know better than the guys at Anandtech, but I got a different impression as to the amount of difference in the compute bitstream from VLIW->non-VLIW SIMD. They seemed to say that the compiler was the ALL IMPORTANT COMPONENT in order to get decent utilization (meaning it was neccessary to keep vast amounts of the program branches in memory and be REALLY good at best guesses for dependencies). Though they didn't say this part I assume that since the compiler was so important for <=NI it becomes less so with >=SI, and should even need to be rewritten for the new architecture.
What you seem to be saying is that <=NI will make good use of the IR->VLIW, which makes sense (also, graphics stays the same).
For >=SI EVERYTHING goes through the new code (which I didn't know, but I also didn't know there were 2 code drops). Again, what surprises me is that the same compiler code used to generate VLIW is also being used to generate the new SIMD code.
Again, if what Anandtech says is accurate it seems like the old compiler was so hideously complex thay you'd want to jettison it as soon as possible instead of making it able to output to yet another kind of architecture (so presumable it now addresses VLIW4/5/SIMD).

I drew a picture on a whiteboard at work of all this yesterday showing Catalyst OpenCL, clover OpenCL and Mesa with all the different code paths and scenarios. Should have taken a picture of it before erasing, sorry.

Well, it's is the holidays after all, so just this once

That is definitely doable, and we'll probably do more work in that direction if it turns out we can't open UVD etc.., but the "small bit" handled by the fixed function hardware is the entropy encode/decode (CABAC, CAVLC etc..) which is still stubbornly expensive to implement on CPU or GPU. Motion estimation, motion comp and filtering are inherently parallel and a decent fit for shaders, but I don't think anyone has come up with a sufficiently parallel algorithm for entropy encode/decode yet.

Yikes! I didn't realise that was being run by the UVD but cavlc shouldn't be that big of a deal to hand off to the cpu so even if nothing comes of uvd (though we still hope, obviously) it's still good to know that there is some light emerging from the tunnel.

Best/Liam

[smitty3268]

Again, what surprises me is that the same compiler code used to generate VLIW is also being used to generate the new SIMD code.

That's not really the case. The "GLSL compiler" is what generates that TGSI output that is currently used by the gallium drivers and will be converted into llvm ir in the new one. However, this is only about 1/3rd of the "complete" compiler.

It doesn't know anything about the underlying architecture of the code, it's just a front-end to the GLSL language. Much like a GCC frontend for C or C++ would be shared across multiple architectures, and there is a separate backend portion that takes care of all the hardware details.

The new LLVM IR code drop from AMD is that part, and it will completely replace the hardware dependent portion of the compiler in Mesa.


Compilers tend to have 3 parts - the frontend reads the source code and stores an intermediate reprentation of it (IR), and only depends on the language being parsed.

The back end is responsible for converting that IR into something the hardware can understand (typically binary instructions, but you can also have backends that output other languages, such as the emscripten project).

The middle is where optimizations take place, and is typically split between the front and back end. Generic optimizations for the language go in the shared front-end, while hardware specific optimizations go in the backend.

In mesa, the GLSL compiler is the front end. TGSI and LLVM IR are both forms of IR used internally (so is the GLSL IR). The old 600g driver contains one backend, and the new code based on LLVM contains a new backend to be used for new hardware.

[zoomblab]

The open-source driver support is not yet available. No patches have magically landed this morning and they haven't released any support work in advance of the hardware's availability.

This is one of the biggest problems in Linux for both developers and users IMHO. There has to be an easy and safe way for end-users to install/update drivers without having to depend on distributions and wait for months in order for code to be merged into the latest kernel.

[wizard69]

AMD recently had a developers conference that covered the technology. I believe Phoronix covered it. However I'm not sure if any of that was for open source development. The architecture is such a massive change that I suspect it could be a year or more before we see optimized code for GCN.

@Bridgman and others looking for the 6 month cycle reference...I believe it's here:

http://www.anandtech.com/show/5261/a...-7970-review/2

"As a result both NVIDIA and AMD have begun revealing their architectures to developers roughly six months before the first products launch. This is very similar to how CPU launches are handled, where the basic principles of an architecture are publically disclosed months in advance".

(the second page of the Anandtech review)
---

I'm not sure why so much attention is paid to Anandtechs site. Sometimes I think the site is owned by Intel.