Radeon HD 7000 Series Will Bring New 3D Driver

[bridgman]

I was under the impression that GCN was MIMD rather than SIMD. Is that not accurate?

Depends on who you ask, I guess. Current chips have multiple SIMDs each capable of executing a different program on a different set of data elements (although in most cases they run multiple instances of a small number of programs), so if that's all you require to call something MIMD then I guess both current and future architectures are MIMD.

GPUs are often classed as "multithreaded SIMD" rather than MIMD because of nuances in connectivity and data sharing. Each new generation of GPUs improves data sharing capabilities and efficiencies so I guess at some point they will start getting called MIMD by enough researchers to "make it official". Not sure where that point is though...

Does this new driver stack will be developed "internally" by AMD or in a "open" manner (I mean a git repo during the development).

As agd5f said, the bits specific to new hardware will be developed internally until we arrange and receive approval to release them, which I wouldn't expect to happen until after launch, then the rest of the work will happen in the open.

The new stack should be architecturally similar to the current stack, and in the areas where it's different (multiple ring support, memory management, compiler so far) we're planning to push those bits out early, once they move from ideas to at least semi-working code. Multiple ring support was pushed out a month or two ago, while the memory mgmt and compiler code are getting fairly close.

We discussed the memory management and compiler plans a bit at XDC, so the core ideas are already "out there". Current thinking is that we should be able to share some shader compiler work between graphics on GCN and clover on existing hardware plus GCN.

If I remember, r600g was mainly created by Red Hat guys?

600g is a bit of a special case in the sense that there was no new hardware info involved, but rather implementing a new driver using programming information which was already released and being used in the "classic" r600 driver, so it was not subject to the usual embargo issues related to new hardware info before launch.

[DanT]

Gallim drivers development - code sharing

Hallo,
I just woul like to ask about gallium drivers development efficiency. The gallium is known to bring many advantages in much more efficient coding, compared to "classic" mesa drivers (avoiding code duplicity and so on, as usually claimed).

From the article it sounds to me, however, that the new driver, in fact, duplicates some amount of code from r600g. Could someone explain which parts of driver are "duplicated" from r600g (and why)?

Thank you very much for the explanation. Best regards
Dan T.

[airlied]

Hallo,
I just woul like to ask about gallium drivers development efficiency. The gallium is known to bring many advantages in much more efficient coding, compared to "classic" mesa drivers (avoiding code duplicity and so on, as usually claimed).

From the article it sounds to me, however, that the new driver, in fact, duplicates some amount of code from r600g. Could someone explain which parts of driver are "duplicated" from r600g (and why)?

Thank you very much for the explanation. Best regards
Dan T.

I think you've misunderstood what gallium is, it isn't magic, it can't take a driver written for one set of hardware and make it work on a completely different hardware platform. Now all gallium drivers essentially share the same interface structure and framework and as such the fastest way to write one is to duplicate an existing one, remove stuff that doesn't apply and fill in the blanks.

gallium architecture avoids some duplicated code between drivers, not ever last possible single line of it.

Dave.

[89c51]

I think you've misunderstood what gallium is, it isn't magic, it can't take a driver written for one set of hardware and make it work on a completely different hardware platform. Now all gallium drivers essentially share the same interface structure and framework and as such the fastest way to write one is to duplicate an existing one, remove stuff that doesn't apply and fill in the blanks.

gallium architecture avoids some duplicated code between drivers, not ever last possible single line of it.

Dave.

that only stands for the lower parts of the stack right??

i mean the state trackers are (or supposed to be) HW independent.

[airlied]

that only stands for the lower parts of the stack right??

i mean the state trackers are (or supposed to be) HW independent.

They are in theory, in practice you still have to design them around an abstraction of hardware interfaces. You also have to test and prove each state tracker on each pipe driver, just because it builds doesn't in any way means its useful or runs.

Dave.

[blackshard]

...isn't that exactly what I said?

(well, minus the VLIW5 part)

Well actually you were right, there will be some VLIW5 parts too (Brazos 2.0).

[bridgman]

... and as such the fastest way to write one is to duplicate an existing one, remove stuff that doesn't apply and fill in the blanks.

The underlined part covers another important point -- the GCN architecture is different from current hardware but not *totally* different. For the parts of the hardware that don't change (or don't change much) it's a lot easier to start with working code for the previous generation than to write everything from scratch.

[Smask]

Well actually you were right, there will be some VLIW5 parts too (Brazos 2.0).

You mean the (not) new mobility parts?

[blackshard]

You mean the (not) new mobility parts?

I meant those installed in the low power APUs:

http://www.brightsideofnews.com/news/2011/11/30/radeon-hd-7000-revealed-amd-to-mix-gcn-with-vliw4--vliw5-architectures.aspx

As far as I understand, radeon 7200 and 7300 are just a rebranding.

[bridgman]

Multiple ring support was pushed out a month or two ago, while the memory mgmt and compiler code are getting fairly close...

... and compiler code is now out (minus the GCN-specific bits, of course)