AMD: Volcanic Islands R1100/1200 (8***/9*** series) Speculation/ Rumour Thread

I was under the impression that only x87 exposed 80-bit precision, which I believe isn't even accessible in x86-64; not that you'd really want to use it, considering the performance.
 
Readable image....

I highly doubt AMD would ever make such a rubbish diagram.

Also, if you just look it, you see the guy did not even know how to properly connect part... how to connect the DRAM controllers to what, and why.
 
I was under the impression that only x87 exposed 80-bit precision, which I believe isn't even accessible in x86-64; not that you'd really want to use it, considering the performance.

It's not part of stock x86-64. I believe it is offered as an extension on x86-64. I haven't tried using it though.

People who know better avoid it like plague.
 
I was under the impression that only x87 exposed 80-bit precision, which I believe isn't even accessible in x86-64; not that you'd really want to use it, considering the performance.

If you require 80 bit precision then not using it because you don't like the performance isn't an option.

All I'm saying is that there are applications that require 80 bits+ that aren't benfiting from GPGPU (or AVX and SSE for that matter)
Long term numerical integrations of the Solar System is one of them.
Google "EPHEMERIS 80 bit"

Returning to the original topic, the diagram could be for AMD's response to Intel's xeon phi and/or Nvidia putting ARM cpus on their compute GPU's
i.e. a high end compute chip.
 
It's not part of stock x86-64. I believe it is offered as an extension on x86-64. I haven't tried using it though.

People who know better avoid it like plague.
It's no problem to use x87 in x64 code. It didn't got cut out of the spec and is still fully supported. The x87 stack is saved and restored on thread switches. Windows64 only forbids to use it in kernel mode and doesn't define how to pass values through the stack for function calls. But that is a decision of MS, it is not inherent to x64.
 
Returning to the original topic, the diagram could be for AMD's response to Intel's xeon phi and/or Nvidia putting ARM cpus on their compute GPU's
i.e. a high end compute chip.

My understanding of the situation is that it's just an idea someone on a forum drew up a long time ago. There are some notable technical flaws and outdated terminology that AMD wouldn't be using for a GCN diagram.
Granted, given some of the bloopers we've seen in various white papers and ISA docs, folks could be forgiven for thinking it was business as usual.

It's also possible to debate if some of the decisions in that picture are not the best choices.
 
It's no problem to use x87 in x64 code. It didn't got cut out of the spec and is still fully supported. The x87 stack is saved and restored on thread switches. Windows64 only forbids to use it in kernel mode and doesn't define how to pass values through the stack for function calls. But that is a decision of MS, it is not inherent to x64.

AVX registers will also be saved/restored on thread switches, but that doesnt mean they are part of base spec. They are an optional extension which is fully implemented.
 
AVX registers will also be saved/restored on thread switches, but that doesnt mean they are part of base spec. They are an optional extension which is fully implemented.
That's true for AVX and there are plenty of x64 CPUs without AVX. But x87 is part of the x64 base spec. As I said, it didn't got cut. Every x64 CPU is required to support it. Even intel's Xeon Phi supports x87 (while deviating from the x64 spec in some other points). :LOL:
It's use may not be encouraged anymore up to the point that some compilers refuse to generate code for it and Win64 forbids x87 in the kernel. But that is a different matter.

Edit: Looks like they loosened up on this in later incarnations. Strictly speaking, everything is optional besides integer processing. IIRC, in the beginning SSE2 support was required to claim x64 compatibility.
 
Last edited by a moderator:
That's true for AVX and there are plenty of x64 CPUs without AVX. But x87 is part of the x64 base spec. As I said, it didn't got cut. Every x64 CPU is required to support it. Even intel's Xeon Phi supports x87 (while deviating from the x64 spec in some other points). :LOL:
It's use may not be encouraged anymore up to the point that some compilers refuse to generate code for it and Win64 forbids x87 in the kernel. But that is a different matter.

Edit: Looks like they loosened up on this in later incarnations. Strictly speaking, everything is optional besides integer processing. IIRC, in the beginning SSE2 support was required to claim x64 compatibility.

x87 use is deprecated in Windows 64 for 64 bit programs but still there for running 32 bit programs. Maybe that's where the misconception of no x87 in x64 comes from.

Cheers
 
x87 use is deprecated in Windows 64 for 64 bit programs but still there for running 32 bit programs. Maybe that's where the misconception of no x87 in x64 comes from.

Cheers
As I said above, it can also be used in 64bit programs. The only real restriction exists for the Windows kernel mode (but this apparently also applies to the 32bit versions of the newer Windows versions). And you are right, this is a decision of Microsoft, nothing inherent to x64.

Anyway, we got quite a bit OT with this. But as there is no real information on VI...
 
Edit: Looks like they loosened up on this in later incarnations. Strictly speaking, everything is optional besides integer processing. IIRC, in the beginning SSE2 support was required to claim x64 compatibility.

Wait, even SSE2 is not required anymore?

Does Xeon phi have 15 integer scalar registers or not?
 
Wait, even SSE2 is not required anymore?

Does Xeon phi have 15 integer scalar registers or not?
Sure yes it's "mostly" x64 it's got all the scalar regs. Still it doesn't really qualify as x64 - no SSE, no cmov, ... Definitely won't work with your generic x86_64 compiler target.
 
http://www.xbitlabs.com/news/graphi..._Quarter_First_Specs_of_New_Chips_Emerge.html

AMD is projected to release code-named Curacao and Hainan graphics processing units that will belong to GCN 2.0 family of products in Q3 2013, reports Chiphell web-site. The new architecture will have a number of enhancements, but the source only mentions that it will come with improved front-end (4 asynchronous computing engines [ACEs], 3 geometry engines) as well as increased amount of stream processors. Both Curacao and Hainan belong to Sea Islands family of GPUs, hence they do not feature advance heterogeneous compute capabilities.

The two chips are expected to be made using 28nm process technology, which is logical, keeping in mind that AMD’s manufacturing partner Taiwan Semiconductor Manufacturing Co. will only start risk production using 20nm fabrication process in Q4 2013.

The Curacao XT graphics processor is expected to feature 2304 stream processors (36 compute units), 144 texture units, 48 render back ends and 384-bit memory controller. The Hainan is projected to have 1792 stream processors (28 compute units), 112 texture units, 32 render back ends and 256-bit memory controller. Both chips will share the same front-end (just-like current-gen Radeon HD 7900 and 7800 do) with 4 asynchronous computing engines [ACEs], 3 geometry engines, command processor, global data share and so on.



The web-site mentions various products based on the new chips, including Radeon HD 8970, Radeon HD 8950, Radeon HD 8870 and Radeon HD 8850 along with clock-speeds and configurations. However, considering that the products are months away, everything can change.

The information about improved family of GPUs makes a lot of sense since AMD clearly needs to offer a new lineup of products this fall. Moreover, historically AMD released new products in Q3 to ensure availability by holiday season. However, AMD is also known for adoption of all-new process technologies among the first, which means that a release of new products month ahead of new tech launch does not fit into such tactics. On the other hand, AMD might have wanted to reduce its risks with the new family of GPUs, which is why it decided to stick to 28nm. Finally, expected performance improvement of Curacao XT versus currently-available Tahiti XT does not seem to be significant enough for a brand-new generation.
 
http://www.inpai.com.cn/doc/hard/196437.htm

They also mention an October launch. But they add informations, that the new cards won't be HD 8000. And AMD wants to repeat the 2004 sucess of Radeon 9550 (which was a cheap RV360 card which dominated NVs NV3x offers back in these days).
Particularly the last information make the informations look like to come from a company source.
 
What was so special about 9550...?
If HD9970 is between 780 and Titan..and sells for US$550, that is a turn off....? HD9970 is 3xBonaire....quite the power on paper, but disappointingly it will not beat nor compete with Titan...how come? :(

If so, AMD could also have named it HD8970...it just sounds more proper...but i think AMD wants to drop the 'HD' moniker once they moved to the next node.
 
What was so special about 9550...?
If HD9970 is between 780 and Titan..and sells for US$550, that is a turn off....? HD9970 is 3xBonaire....quite the power on paper, but disappointingly it will not beat nor compete with Titan...how come? :(
If it's faster than the 780, and sells for $550, how is that a turn off? The 780 sells for $650, and Titan sells for $1000.
 
Back
Top