Embedded sideport ram
Interesting Ars chat with an AMD marketing type: http://arstechnica.co.uk/gadgets/201...lets-says-amd/
Embedded sideport ram
Interesting Ars chat with an AMD marketing type: http://arstechnica.co.uk/gadgets/201...lets-says-amd/
Sideport did a pretty good job for the AM3 boards actually; had the choice of boosting the IGP bandwidth OR saving system ram by running sideport only.
With HBM on a full SoC it'd be the System RAM you could do without, and once we get HBM2 shipping you'd only need a single stack....
EDIT: actually, just think of the possibilities for designs when the entire system sits on a single silicon interposer. You could probably squeeze a wireless + bluetooth card on there as well (or embed the IP in the SoC) and save so much space for the rest of the internals. You could easily have a 15W SoC laptop in a 13" slim chassis with thin optical drive and a high capacity battery, because you'd have next to no motherboard...
EDIT2: Oh, you can probably squeeze some eMMC onto the interposer too, don't you think...?
Problem with embedding the system ram is that while 8GB might be fine for you, I am typing this on a Linux box with 32GB and frankly a bit more would be nice. I think from a marketing point of view, not being able to expand a system isn't good either. Would work well for low end laptops, things like Chromebooks seem to have soldered down ram anyway.
Multiple SKUs with different RAM capacities would be a possible solution, if not a particularly elegant one. Another would be to have that smaller amount of primary RAM plus the ability to add more DDR externally, but differing RAM speeds could be complicated to manage.
However, unless something changes WRT client CPU workloads, the faster RAM may not be as useful as it is for GPU workloads. I understand there's a lot of crossover with HSA, but with OS kernel support differing memory speeds/latencies could be taken advantage of, sort of like the RAM/swap model we use now.
Some more details of the dies sizes of both Fiji and Tonga:
http://wccftech.com/amd-tonga-gpu-di...imated-560mm2/
It appears Tonga does have a 384 bit memory controller.
It makes me wonder if the R9 380X will be closer to the R9 390 in performance!
True, but you probably wouldn't want an SoC for that box. Different market segments. Carrizo is all BGA SoCs, as far as I can tell, targeted very firmly at the mobility segment, so tweaking the design to allow a stack of HBM isn't going to be a problem in that market segment. Frankly if they could slap a single 1GB stack onto Carrizo-L right now that's be a lovely little tablet chip. But sure, keep the socketed parts on DDR4 (with perhaps a single 1GB stack of L4 HBM cache... ).
I have AMD A8 processor, I need to play all the latest games. Do I need to upgrade the processor?
It looks like AMD might have been incredibly conservative with their <70mm line - according to wccftech, the package is 55mm^2 so that slide is to scale
I'm aware it's wccf so large pinch of salt and pepper required, but any idea what the "ES PC PR IP" headings mean on the table? ES could be engineering sample, not sure about the rest though.
http://wccftech.com/amd-bristol-ridg...ecture-slides/
I'd trust that article far more if their write-up actually agreed with the slides They repeatedly talk about Bristol Ridge being on the AM4 socket despite all the slides showing it on FM3. And the concept that an Excavator-based APU will be launched alongside a Zen-based CPU, with AMD continuing in a differentiated socket architecture? Well, I find that ... unlikely. I suppose it's conceivable if a) they want to use the same silicon for mobility and desktop APUs, b) all mobility APUs are transitioning to SoCs, and c) they don't want to give up die-space on enthusiast-segment CPUs to the southbridge functions. Otherwise, it makes little sense to me...
Yeah as I said I really don't have much confidence in the article at all, I only linked it as I was wondering what the table headings stood for.
Googling the slide title got this http://www.kitguru.net/components/cp...2016-document/ which says:
Engineering Sample
Production Candidate
Production Ready
I would guess that IP is "Initial Product", ie stuff turns up with it in.
As for an Excavator APU launching alongside Zen? Wonder if Zen is bigger and a quad core would push the die size too big, or perhaps it is just design risk minimizing because enthusiasts buying Zen will let AMD off the thermals a bit if the performance is good, but laptops really can't take a step backwards so waiting for Zen mk2 would seem wise. The APUs were still using VLIW4 when discrete graphics were all GCN so it wouldn't be the first time that APUs were a bit tech laggy.
watercooled (15-06-2015)
Not to mention the APUs were also still using K10.5 when the first Bulldozer FX came out, and they didn't get updated until Piledriver, which in hindsight seems almost inevitably because of the thermals issue.
OTOH, the leaked AMD roadmap here says Bristol Ridge will be Zen, which seems far more likely for a mid-2016 APU. And the kitguru leak is alledgedly newer than the wccf one. So who can say...?
If I had to guess at a reason for using Excavator, assuming that's true, I'd also say risk minimising.
AMD haven't explicitly said one way or the other; the omission of the Zen stamp on the APU blocks is curious, but it could even be a case of them not wanting to reveal everything in one go.
PCPER reviews the R9 390:
http://www.pcper.com/reviews/Graphic...390-8GB-Review
Seems more a slightly tweaked R9 290 series.So what changes were made in these new spins of GPUs? AMD was quick to comment on the term "rebrand" that will no doubt be associated by many with the Radeon R9 300-series. They insist that engineers have been working on these GPU re-spins for over year and simply calling them "rebrands" takes away from the work the teams did. These GPUs (the 390 and 390X at least) have a "ground up" redesign of the software microcontroller that handles the clocks and gating to improve GPU power efficiency. As you would expect for a GPU built on the same 28nm process technology that has been around for many years, AMD has tweaked the design somewhat to better take advantage of evolutions in TSMC's 28nm process. And, thanks to higher clocks on both the GPU and the memory, performance increases will be seen over the existing R9 200-series as well. Being able to run around 50 MHz higher on the GPU and 250 MHz (1.0 GHz effective) on the memory inside the same power envelope shows that AMD has done SOMETHING, though how much that means for consumers is up in the air.
The card is slightly faster than a R9 290X 4GB but has double the VRAM and has lower power consumption.
Remember I was talking about wanting a frame rate limiter built into graphics drivers?
http://cdn.videocardz.com/1/2015/06/...rol-Center.jpg
Sites are talking about it being good for power/heat/noise which is true OFC, but it should also be super-helpful for older games which can run at hundreds of FPS causing weirdly high GPU load, coil whine and massive screen tear.
It looks like it might be exclusive to the newly released cards which is weird as I've been doing it with 3rd party software for years. It's unlike AMD to implement arbitrary feature lock-outs.
There are currently 11 users browsing this thread. (0 members and 11 guests)