Trinity vs Ivy Bridge

[Andrew Lauritzen]

Yes I agree having unified driver source code would be what's really required.

Sure, but as architectures diverge far enough you don't want branches/indirection all over your highly-optimized code either, so ultimately it makes sense to produce dedicated code paths/DLLs for each set of similar architectures, even if the code base is somewhat shared.

In reality a "unified driver" is not a well-defined concept, which is why I made the note. There is no perfect level of specialization vs. code sharing.

 

[AlexV]

Well I'd guess it's a bit more than what Brazos 2.0 was (which you'd never have noticed it was something new until they told you...). Brazos 2.0 was a late addition to the roadmaps due to canceling of Krishna/Wichita, but Beema is a regular scheduled chip so I don't think it will end up _that_ similar (even though both cpu and gpu arch will probably remain mostly the same). I guess there's a possibility it might support something like gddr5m even which alone would make it a worthy successor.

Perhaps. On the other hand, there is a cost associated with an update, and AMD is not in the position of spending lavishly. Therefore, unless they have non-intrusive / ready to patch in stuff, a clock bump + some power optimisations looks reasonable to me, perhaps in the vein of what Richland (another unplanned addition) is currently doing. I'm not convinced that the new AMD will be a daring AMD (and the old one tended to be daring mostly in slides and then miss targets badly). We will see, of course.

 

[Kaarlisk]

Sure, but as architectures diverge far enough you don't want branches/indirection all over your highly-optimized code either, so ultimately it makes sense to produce dedicated code paths/DLLs for each set of similar architectures, even if the code base is somewhat shared.

In reality a "unified driver" is not a well-defined concept, which is why I made the note. There is no perfect level of specialization vs. code sharing.

Even if we are talking about bugfixes on older driver branches, often quite new Intel GPUs simply drop out of support too quickly. For example, all driver development for G35 (X3500) seemed to have stopped a bit more than 2 years after it's release. If I'm mistaken, please correct me.
It was a very pleasant surprise when it turned out that there would be bugfixed Windows 8 drivers for almost every Intel GPU. You do still get the feeling that Intel simply does not have the resources - no OpenGL for older GPUs in Windows 8, no Windows 8 support for the GPUs that used PowerVR IP (which did not prevent computer shops from prominently displaying "Windows 8 for €14.99" next to GMA 3600 laptops).

 

[Alexko]

Perhaps. On the other hand, there is a cost associated with an update, and AMD is not in the position of spending lavishly. Therefore, unless they have non-intrusive / ready to patch in stuff, a clock bump + some power optimisations looks reasonable to me, perhaps in the vein of what Richland (another unplanned addition) is currently doing. I'm not convinced that the new AMD will be a daring AMD (and the old one tended to be daring mostly in slides and then miss targets badly). We will see, of course.

GCN 1.1 seems like a good candidate for Beema. And supposedly, the CPU core itself will be improved somewhat.

But I don't know if we're talking about a 28nm or 20nm chip.

 

[Dave Baumann]

Kabini is already the same GFXIP level as Bonaire.

 

[Alexko]

Kabini is already the same GFXIP level as Bonaire.

Oh, that's pretty cool. Is that true of Kaveri as well?

 

[Andrew Lauritzen]

Even if we are talking about bugfixes on older driver branches, often quite new Intel GPUs simply drop out of support too quickly.

Yeah I dunno, stuff obviously does get bug-fixed further back than the active development, but I'm not surprised that pre-sandy-bridge stuff is/was dropped off more quickly (SB was kind of a turning point). TBH though I barely expect any support from anyone with >2 year old hardware, but admittedly I tend to be more on the bleeding edge than some.

 

[AlexV]

Oh, that's pretty cool. Is that true of Kaveri as well?

The Kabini GPU was a reasonably clear deal once the PS4 got pushed out in the open, IMO. Or do we choose to believe the "magical super-sauce IP mix of doom" story? I'd rather not. Also, considering that Kaveri is supposed to be the bringer of "a pointer is a pointer is a pointer" (sigh, wrong paradigm there...but I digress), it can't be anything less than Sea Islands (I refuse to get into the whole rename-that-is-not-a-rename-delay-that-is-not-delay-that-is-according-to-plan-really stuff), since it will need the FLAT_* addressing modes, and Southern Islands don't have it / don't expose it.

 

[Dave Baumann]

Sea Islands refers to a SoC roadmap, not a technology level. It is incorrectly used as such.

 

[3dilettante]

We all haven't fully made the transition to a post-definition world where things have no names and words have no meaning.
We struggle instead to find labels so that we can meaningfully communicate the distinction between one Thing and Another Thing.

Since Sea Islands is not a good label choice, I'm going to reformulate the point using different technical terms.

Let's call the initial GCN architecture as best known in the Southern Islands presentations "Chad".
The revision with expanded addressing and interoperability that is posited from the briefly on-line Sea Islands document is what I'll call "Tim".

I'll rewrite AlexV's post to be conformant to the new reality:

...
Also, considering that Kaveri is supposed to be the bringer of "a pointer is a pointer is a pointer" (sigh, wrong paradigm there...but I digress), it can't be anything less than Tim (I refuse to get into the whole rename-that-is-not-a-rename-delay-that-is-not-delay-that-is-according-to-plan-really stuff), since it will need the FLAT_* addressing modes, and Chad don't have it / don't expose it.

 

[Alexko]

We all haven't fully made the transition to a post-definition world where things have no names and words have no meaning.
We struggle instead to find labels so that we can meaningfully communicate the distinction between one Thing and Another Thing.

Since Sea Islands is not a good label choice, I'm going to reformulate the point using different technical terms.

Let's call the initial GCN architecture as best known in the Southern Islands presentations "Chad".
The revision with expanded addressing and interoperability that is posited from the briefly on-line Sea Islands document is what I'll call "Tim".

I'll rewrite AlexV's post to be conformant to the new reality:

GCN (1.0) and GCN 1.1 work fine for this purpose, until AMD decides to communicate official names, anyway. That's what HardWare.fr and Anandtech have been using, I believe.

 

[Blazkowicz]

I'd say "Radeon with HSA" and "Radeon without HSA", with thus the understanding that if you plug a Bonaire GPU (and maybe a Mars/Oland) into a Kabini board then you have a HSA system.

I've never understood the "islands" since there were "southern islands, no wait it's northern island, no it's southern islands again" (I don't guarantee any veracity of this account it's maybe the other way or nothing at all)
Another idea would have been "Chad" is "Radeon 7000" and "Tim" is "Radeon 8000", and that would have been easy enough to understand till recent times.

 

[Blazkowicz]

GCN (1.0) and GCN 1.1 work fine for this purpose, until AMD decides to communicate official names, anyway. That's what HardWare.fr and Anandtech have been using, I believe.

I expect AMD to communicate at least upon Xbox 720 launch.
Semi-related to the discussion, there's the recent announcement that AMD open source drivers on linux get h264 and al. decoding support (VDPAU support)
That makes some geeks happy.

I guess AMD is in the midst of very expensive and complex software and driver development (I don't know anything beside it being complex and expensive. their green opponent is strong in this and boasts very much of it, what with their teslas and "vca grid" and cuda + opengl 4.3 "mobile chip")

 

[pjbliverpool]

I'd say "Radeon with HSA" and "Radeon without HSA", with thus the understanding that if you plug a Bonaire GPU (and maybe a Mars/Oland) into a Kabini board then you have a HSA system.

I thought the first "full HSA" APU was Kaveri though. Thus implying that Kabini is lacking in that respect and since we now know Kabini features the Bonaire IP we could argue that Kaveri will use something beyond Bonaire.

Or are the HSA element lacking in Kabini compared with Kaveri separate to the GPU IP itself?

 

[Blazkowicz]

I always thought Jaguar, or Kabini was HSA ready. Kaveri is merely the flagship, with the slight problem it is late. Of course I know nothing more.

 

[itsmydamnation]

I thought the first "full HSA" APU was Kaveri though. Thus implying that Kabini is lacking in that respect and since we now know Kabini features the Bonaire IP we could argue that Kaveri will use something beyond Bonaire.

Or are the HSA element lacking in Kabini compared with Kaveri separate to the GPU IP itself?

Originally Kaveri was supposed to come out before Kabini, so Kaveri would have been the first, doesn't mean that Kabini now isn't.

 

[AlexV]

As far as I can see Kabini, at least in its first swoop, is not significantly more integrated than Trinity. Moreover, it has a relatively gimpy memory interface. I would expect AMD to be keen on making as big a splash as possible with the first HSA sporting implementation, and Kaveri seems like a much better bet for that, since it (bar great mischief) will actually have a rather respectable memory interface and, hopefully, somewhat tighter integration. I guess we'll see.

 

[RedVi]

Kabini will surely be impressive in the market segment and tdp segment it occupies though... There's no use in delaying Kabini just because Kaveri is a better first showing for HSA, I don't see the sense in that. Besides, from what we've seen so far, Kabini is more than impressive in what it brings to the ultra portable/tablet segment.

 

[rpg.314]

We all haven't fully made the transition to a post-definition world where things have no names and words have no meaning.
We struggle instead to find labels so that we can meaningfully communicate the distinction between one Thing and Another Thing.

Since Sea Islands is not a good label choice, I'm going to reformulate the point using different technical terms.

Let's call the initial GCN architecture as best known in the Southern Islands presentations "Chad".
The revision with expanded addressing and interoperability that is posited from the briefly on-line Sea Islands document is what I'll call "Tim".

I'll rewrite AlexV's post to be conformant to the new reality:

3D hits it out of the park.

 

[AlexV]

Kabini will surely be impressive in the market segment and tdp segment it occupies though... There's no use in delaying Kabini just because Kaveri is a better first showing for HSA, I don't see the sense in that. Besides, from what we've seen so far, Kabini is more than impressive in what it brings to the ultra portable/tablet segment.

What I'm saying is that Kabini doesn't have the pieces in, and that Kaveri being touted as the first HSA part is not an accident, but rather a consequence of its architectural benefits versus Kabini. Nobody said anything about delaying a product that's already shipping and in some upcoming SKUs