AMD: Pirate Islands (R* 3** series) Speculation/Rumor Thread

iMacmatician said:
There are some claims that the M370X does not use the 2012 Cape Verde but actually uses some newer chip or revision, for reasons including OpenCL 2.0 support in the 8800M and M370X but not in Cape Verde.

Can anyone here confirm or deny these claims?
Click to expand...


AMD clearly says that the M375 only goes up to OpenCL 1.2:
http://www.amd.com/en-gb/products/graphics/notebook/r9-m200#


EDIT: Then again, the same page also claims that Bonaire (M280) and Tonga (M295) only support OpenCL 1.2, and AMD clearly states that OpenCL 2.0 is only compatible with GCN 1.1+ GPUs...
So perhaps the only thing is that the OpenCL 2.0 driver for those mobile GPUs was never developed...
 
Last edited by a moderator:
pharma said:
http://www.anandtech.com/show/9276/2015-15inch-retina-macbook-pros-dgpu-r9-m370x-is-cape-verde
Click to expand...
AnandTech could be wrong too, you know? If it does support OpenCL 2.0, it has to be GCN 1.1 or newer

edit:
I just did some quick googling
Last December, this was supposed to be the list of OpenCL 2.0 supporting GPUs from AMD:
AMD Radeon HD 7790, AMD Radeon HD 8770, AMD Radeon HD 8500M/8600M/8700M/8800M/8900M Series, AMD Radeon R5 M240, AMD Radeon R7 200 Series, AMD Radeon R9 290, AMD Radeon R9 290X, A-Series AMD Radeon R4 Graphics, A-Series AMD Radeon R5 Graphics, A-Series AMD Radeon R6 Graphics, A-Series AMD Radeon R7 Graphics, AMD FirePro W5100, AMD FirePro W9100, AMD FirePro S9150.

--
For that list to hold through, it would mean that..
Oland is 1.1
There's 1.1 variant of Cape Verde
Curacao is in fact 1.1 version of Pitcairn, not just Pitcairn
...which would mean that only Tahiti was left without 1.1 update
 
Last edited:
Kaotik said:
...which would mean that only Tahiti was left without 1.1 update
Click to expand...

If that's true (which I find very hard to believe), Tahiti got the largest update: Tonga.


If all those GPUs got updated, why not include official support for TrueAudio, FreeSync and VSR in them, which have been available since Bonaire?
Bonaire appeared in February 2013, and the higher-end R9 270 (Pitcairn/Curacao) was announced in November of the same year.

AMD was going to hide hardware features in the drivers for almost 2 whole years? It doesn't make any sense.


Most probably, AMD simply found a way to run OpenCL 2.0 on GCN 1.0 GPUs, perhaps by forcing some stuff to run on the CPU cores.
 
ToTTenTranz said:
If that's true (which I find very hard to believe), Tahiti got the largest update: Tonga.

If all those GPUs got updated, why not include official support for TrueAudio, FreeSync and VSR in them, which have been available since Bonaire?
Bonaire appeared in February 2013, and the higher-end R9 270 (Pitcairn/Curacao) was announced in November of the same year.

AMD was going to hide hardware features in the drivers for almost 2 whole years? It doesn't make any sense.
Click to expand...
Or perhaps this is the place where those "IP-blocks" I think Dave Baumann once called them come into play. If my memory serves me right, it's not just "GCN x.y", but there's individual "IP-levels" for smaller blocks inside the GPU, which aren't tied to updating every other block too.
Maybe adding the "GCN 1.1" capabilities for OpenCL 2.0 was trivial compared to adding completely new blocks like TrueAudio?
(Also the updated Pitcairn/Curacao would have been announced in May 2013 as Neptune aka HD 8970M, since HD 8900M series is included in OpenCL 2.0 supporting GPUs, not November 2013)

Most probably, AMD simply found a way to run OpenCL 2.0 on GCN 1.0 GPUs, perhaps by forcing some stuff to run on the CPU cores.
Click to expand...
If so, why isn't Tahiti supported?
 
ToTTenTranz said:
If that's true (which I find very hard to believe), Tahiti got the largest update: Tonga.


If all those GPUs got updated, why not include official support for TrueAudio, FreeSync and VSR in them, which have been available since Bonaire?
Bonaire appeared in February 2013, and the higher-end R9 270 (Pitcairn/Curacao) was announced in November of the same year.

AMD was going to hide hardware features in the drivers for almost 2 whole years? It doesn't make any sense.


Most probably, AMD simply found a way to run OpenCL 2.0 on GCN 1.0 GPUs, perhaps by forcing some stuff to run on the CPU cores.
Click to expand...
Keep in mind that Apple more or less writes their own drivers at times. OpenCL was their baby, after all.
 
3dilettante said:
Sure there could be some third party boards, with third-party air coolers AMD has no interest in competing against, and then there are outside water-cooling solutions and full system loops that don't get into launch reviews.
Click to expand...

I wouldn't be at all surprised to see some OEMs ditch the reference design and use their standard air coolers for both regular and OC Fiji cards as well using as potentially using a much longer PCB in order to support a standard large air cooler. Although a longer PCB would increase the cost as well but that'd likely be offset by the cheaper air cooler.

Regards,
SB
 
Khronos site has phenom mentioned alongside those notebook chips. Is that supposed to be a requirement or the system they were tested on?
 
Fiji card will be called Radeon Fury:

http://www.expreview.com/40812.html

If true, it's nice to see the time travel and acknowledging the old cards:

RaVFokR.jpg





BTW, does this mean that a card with two Fijis will be called Radeon Fury MAXX?

UEvjiDJ.jpg
 
Ryan Smith said:
So funny story. I'm validating 290X against the new 15.5 drivers and TessMark performance has almost doubled versus what I got in March...
Click to expand...

AMDs tessellation performance can vary quite substiantially with driver revision.

Hope you can see this graph directly:
http://www.pcgameshardware.de/scree...ellation_Performance_vs_R9_280_part1-pcgh.png

If not, you need to scroll down a bit here:
http://www.pcgameshardware.de/Grafikkarten-Grafikkarte-97980/Tests/AMD-Radeon-R9-285-Test-1134146/4/
 
Anyone have a theory as to why x86 code gets well over twice the performance versus x64?

That doesn't seem right to me somehow...
 
Grall said:
Anyone have a theory as to why x86 code gets well over twice the performance versus x64?

That doesn't seem right to me somehow...
Click to expand...

CarstenS said:
I think that's tessellation factors, not code.
Click to expand...

Effectively, lol. 64x, 32x 16x factor ..

Anyway, could they have just set a different factor level on the profiles of the games ? but i will not see how it will impact tessmark so.
 
You must log in or register to reply here.

Similar threads

U
AMD: Southern Islands (7*** series) Speculation/ Rumour Thread
236 237 238
Replies
5K
Views
1M
BrynS
B
Back
Top