AMD CPU speculation... and expert conjecture

Page 395 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
Toggle sidebar Toggle sidebar
Status
Not open for further replies.


I'm assuming that's the part you're referring to. I suppose I could have been more precise. Sometimes I forget that what makes sense in context to me doesn't necessarily follow for everyone else. What I meant was, the discrete card would be directly running the VM's graphics, while the igpu would be running the Linux OS's graphics. 4 cores would be running the VM, and 2 cores would be running the Linux OS.
 


If you have a reason it's a bad idea, please enlighten me so I don't waste my time in the future if it becomes possible. Otherwise, I acknowledge you are entitled to your opinion, however terrible it may be :) .

 
AMD is already working on a ARM/x86 Hybrid, so there may not be a need to emulate ARM software.

I brought that up because Yuka or someone else brought that up... anyway lets end this ARM thing before it grows.
 

Fixed
 
^^ don't worry, that's preorder pricing, and it's from shopblt. amd fanboys used it to inflate ivb and haswell pricing to fearmonger ($500 dual core cometh!!).
wait for official msrp announcements. i doubt they'll go higher than $150 (unless amd thinks otherwise).

edit: however, the shopblt link revealed a previously unknown information: the weight! shopblt lists the package weights at 0.64 lbs (how much is that in kilograms?).
 
ya, shop BLT does that just for publicity. They will be linked over and over and over for the next month. BD was $100 over cost, and others since around $50 over. They will get a ton of traffic for doing what they do best, ripping people off.
 


A GPU is a special case of a TCU. TCUs are particularly bad at branching, synchronization, and serial codes. That is why we don't run operative systems on GPUs. In a supercomputer, we run the OS on the CPU and the (parallel) computations on the GPU.

The idea of an version of Kaveri with more CPU cores but less GPU cores is also weird. Pay attention to the generational tendency, not only for AMD products but also for others such as Intel or Nvidia. Intel Haswell CPU is virtually the same than Ivy Bridge, but the GPU is much better. Broadwell again focus on improving the GPU by about a 40%, the CPU will receive another minor 5% update. This focus on GPUs is made to achieve balanced APUs.

More CPU cores and less GPU cores is an unbalanced design, with loss of efficiency.
 


GCN in its core is closer to what CUDA is than OGL or DX is.

http://www.amd.com/us/Documents/GCN_Architecture_whitepaper.pdf

What I meant that it could run X86 instructions is not run "x86 code" itself. I worded it incorrectly. The way GCN was made, is to be more close to a regular CPU than it was before and the way it can process its own stuff if more "CPU like". Like palladin said a good while back, GPUs are just a huge SIMD engine that CPUs already have. Now they just added the rest of the "fancy" stuff CPUs have to be more independent (as GPUs) -> GPGPU.

GCN is just a very good polish of a GPU wanting to do CPU stuff without leaving it's GPU origin.

Cheers!

EDIT: Forgot to add... Hence they are pushing MANTLE so hard as well. To be able to exploit GCN with HSA to its fullest, they'll need MANTLE to get devs closer to the "new" GPU APIs (new as in GPGPU components of each API and "close to metal").
 


Yes, I understand that GPUs are just big SIMD engines, but that still doesn't answer how a GCN GPU could run a Linux OS compiled in x86.
 


So we're back to at sometime in the future FX will evolve. That sometime being at least 2015 or later. Waiting for either more money and/or a new node to use.

The effort to make it easier to use more cores is still useful even for 4 core parts, as most software is dual-core optimized still.
 


Ah, good thing you narrowed down the discussion.

Short answer is "nope, they can't... yet".

There are some ASIC boards that can run Linux, for example, and you can slap pretty much any chip in there to run a host OS; I worked with some back in University, really fun stuff. Currently, with what I know, at most they could run a virtualized OS of a GPU with some tweaking to the host OS to cheat on how it is run. For the way "PCs" are designed as of now, it's not possible to do it like you say ("plug and play").

Point is, as GCN stands now, if AMD would want to, they'd have to make minor adjustments (fat lie, lol) to the hardware to run a host OS (standalone PC) of the GPU.

I don't want to mix things too much, but the concept is that, at least nVidia and AMD, currently have very potent chips, no matter how you want to label them. And going to the roots... You just need to model a Touring Machine to run from the chip, right? 😛

Cheers!
 

Would it not be terribly inefficient for a repurposed GCN it to run traditional x86 instructions?
 


Well if the ASIC is suited towards an ISA that Linux is supported for/if Linux is re-compiled to run on the ISA of the ASIC, then everything is good to go. Some ASICs are little more than ARM parts repurposed for a job that x86 parts don't do well (which in these days is basically everything... Just kidding.... A little.) in.

Though what you says makes sense and doesn't conflict with anything I hold to believe is true. I think GPUs could certainly be resuited to run a host ISA; you'd just have to basically take out every single piece of non-execution decoders in the whole design and replace it with x86-(or ARM) compatible decoders...

And then hope no one expects you to run NEON or AVX/SSE/MMX instructions or anything silly like that.
 


Yes.

Now, why would I want to do that instead of using the ISA a GPU would provide to me? 😛

I think I confused you a little more that I thought with what I said, but taking out emulation of the matter, GCN should have no issues running any SIMD instruction like the CPU would. As simple as that; now, GPUs are *not* CPUs, so it would require a little more effort to actually run an OS (hence, send it instructions directly) from it. Specially since I really don't know if we can compile C or C++ code to VLIW4/5 or GCN or CUDA and run stuff directly.

I would leave that for someone else to answer 😛



NEON? What's that?

But all the others would actually make sense to run them in a GPU, no?

Anyway, not Linux per se, but you can run the basic kernel structure of any ASIC. You just need to re-write some bits of code (scheduler and the CPU driver). The rest is provided by the ASIC board AFAIK (board drivers/code).

The OS we used to test on was called M32.

Cheers!
 
Well... AMD designed GCN in such a way that you can actually run Scalar instructions on them, they just weren't exposed directly to the OS. GCN actually has support for load / store, logical compares and stuff like ADD/SUB/MUL/DIV. In theory, assuming they were some sort of direct BIOS / HW access to the GPU, you could compile an OS to run on it. It would be very slow as GPU's aren't particularly good at running Scalar but it would have an insane amount of Vector capability.

Honestly it would be a learning experience only as there is no practical application for this on a dGPU. This set of features was designed into GCN as forward compatibility / preparation for HSA and treating the iGPU has a Vector coprocessor instead of a frame buffer. Currently to run stuff on an external Vector coprocessor (GPGPU / OpenCL / CUDA) we have to package it up and send it off then wait for it to return, it's rather inefficient and has an annoying amount of overhead. If the external vector coprocessor shares the same memory space and comparable instruction format you could instead just code in the vector work directly in the instruction stream and not be bothered with the higher level API's.
 


ARM NEON : https://developer.qualcomm.com/blog/what-neon-again

Basically ARM's proprietary SIMD ISA extension :)

And oh that's very interesting, I didn't know that!

 


Let`s avoid ARM at all cost... we don`t want another ARM/x86 war at this rate.
 
Well AMD have played the long game well this time, GT3 remains an enigma and ellusive as ever there is nothing on GT3 yet other that dodgy videos that are as suspect as Michael Jackson at a kiddies party. What AMD will know is they have had intel have to clock in excess of 1.3ghz on the iGPU to achieve performance, those clock rates are virtually double HD4000 and if you look at the exponential growth needed on this it is completely unsustainable.
1XU44n
 
Nvidia engineers already booted a linux kernel in a GPU, but by reasons explained before this is weird. They did it only to demonstrate that its cards are true GPGPUs. Nvidia will be adding a CPU (Denver project) to the next gen graphics cards.

The difference between a CPU and a GPU was explained before...

elemein No. GPUs are not "just big SIMD engines". CUDA GPUs are SIMT engines. SIMT != SIMD.

http://www.nvidia.com/object/justthefacts.html

Regarding parallelism, a CUDA GPU is somewhat between a vector processor and a SMT CPU.

palladin9479 No, the HSA specification doesn't say that the GPU will be used as a vector co-processor.

Yuka NEON extensions were mentioned before in this thread. I used them to compute the GFLOP of Seattle when I gave the list of GFLOP comparing Seatle to Opteron and FX CPUs. This was many many many pages ago...

con635 The James Prior's interview was funny. This is the same James Prior whom I was discussing during days in twitter when I leaked the Kaveri diagram just before publishing the BSN* article. I got the diagram from a talk given by one of his chiefs, still he claimed he was not familiar neither with the talk nor with the slide I was mentioning to him. Finally he was unable to answer my question about ALUs with a simple YES or NO. Funny to see he again saying "I've never seen that slide before, I don't know where that came from"... so typical!

The leaked roadmap is not official. Someone leaked it from a non-public presentation given by AMD. This is what "leaked" means. I can see in the bottom part of the slide the word "CONFIDENTIAL". Therefore I am not sure why people insist on saying that it is not an official roadmap. Official roadmaps don't have the word "CONFIDENTIAL" printed in them.

Funny also that the writes: "AMD will continue to supply AM3+ and AMD FX processors for the foreseeable future, as per AMD's official roadmap update at APU'13". The leaked roadmap says exactly the same, therefore he is negating something that the leaked roadmap doesn't say.

noob and company I notice how you are again silent to people here mentioning and discussing ARM.
 


GCN cores can run up to SSE4 x86 instructions. They are obviously less effective at single thread tasks, however, instructions that can go widely parallel run well on the GPUs.

Additionally...

Bulk is dead past 28nm. PERIOD.

FinFET on bulk will be more expensive than planar FD-SOI, and the NY Fab is the SOI Fab. GF has literally dumped billions into the NY Fab, and will not abandon FD-SOI @ 20nm. The issue is, when STE went down, and AMD had seen an immature process node from GF, it decided to play it safe. Honestly, I think it was a bad decision, but it wasn't mine to make. We will see how the cards play out.
 


You could significantly affect the results via priority, especially when the number of threads is greater or equal to the number of CPU cores. In this case, the higher the priority, the less of a chance of another background application bumping one of your application threads, which, if they are using every CPU core, WILL affect the final result.

I suspect that's why my system fared so well; I have a very customized Win7 install with almost no background tasks running.

...see how fun it is making "unbiased" benchmarks yet?
 
Status
Not open for further replies.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom