AMD does reverse GPGPU, announces OpenCL SDK for x86

Printable View

Show 100 post(s) from this thread on one page

08-17-2009, 12:42 AM
Mumak

I'm really enjoying this discussion :) From a general (and ancient) question "what execution unit" can handle which kind of tasks it ended up with pasting useless numbers..
I won't dive into the topic whether GPU or CPU is better for what kinds of tasks, since I think the answer is in the middle - unification. And that's what's happening now.
To me it seems that Intel realised that x86 is mature and no longer capable to handle high-performance tasks. And this is proven by the AVX introduction which seems to be the first step to unification. I think the future should look heterogenous: an x86 (backward compatible) core + massive parallel rest of exec units. Is that the way you're going Francois? Modularity and configurability (like the NHM concept, even better implemented in SNB). We can build a CPU for a particular segment by using the blocks we have, so we get the right mixture (ballance).
In the end - why should be graphics treated special and have special dedicated sepatare units.. We are here to build solutions to solve your tasks, so let's pull the VGA card off the PC :D

We can discuss here another topic when already touching the x86 set. Everyone should agree that's it's mature and being held alive with extensions (MMX - AVX) to achieve performace.
Sure the existing market of x86 apps is biggg and that's what Intel knows well (pushing x86 even into ultra-mobile, trying to catch with ARM). But there must something big come since this ISA will reach its limits soon.
The current hunt for better IPC is a real pain. It's a waste of fixed-function hardware, complex algorithms which results in high consumption. Imagine that in fact you're wasting transistors which most of the time decide how to perfectly execute code that comes in. But why so much wasting? Why has the HW always do the same task to think how to execute something even if a code path is executed x-times the same way.. And what's the answer to this? EPIC - move the decisions from HW to SW (compiler). There's no need to have such intelligent CPU and waste resources each time. Let's have a more stupid CPU which executes instructions the way they are told by compiler. Moreover it's easier to upgrade SW (compiler) than HW.. A nice idea realised by Itanium.. There were other many great concepts (EFI, etc). But at a wrong time.. Crashed by incompatibility. But now, this might be possible using multi-core heterogenous concept... The way to move to new concepts by maintaining compatibility and slowly phase-out the mature ones.
08-17-2009, 12:44 AM
Mumak

The question is: what you mean by 'success'? :rofl:

Quote:

Originally Posted by W1zzard

so which isa is more successful?
08-17-2009, 01:22 AM
Mumak

Integration, modularity and configurability. Making tasks general, providing a solution with the right mixture. Integration saves space and costs. Unification allows standard approaches to be used.
Moreover, the more integrated solutions are offered, the more areas are under own control :) This is what both Intel and AMD realised...

What was the first victim? The x87 Co-processor :) Remember the expensive beasts you had to buy to be able to run AutoCAD? There were more vendors manufacturing them with specific enhancements.. And now? :D

Quote:

Originally Posted by Smartidiot89

So going abit off-topic perhaps... How far do you think System on Chip will develop within the coming years? I'd like your personal opinion on this

It is obvious that the 3 major PC vendors Intel, AMD and Nvidia have a large interest in this and all have a solution/is working on one that will be released very soon. Looking 10 years ahead will something have changed with out tradition computers with a motherboard, CPU and the option for a stronger GPU would we want to, or have we in 10 years started the transition whereas the difference between a CPU and the GPU has become minimal if not none-existant anymore, and all PCs will consist of a single-chip on a PCB instead of the classical motherboard, CPU, GPU etc. etc.

We have seen SoC taking it's way into Phones and Smaller hand-carried products and soon Qualcomm will release their smartbooks, not performance monsters, but it's SoC in a small package which I can carry around and use as a PC together with a OS (not Windows ofc.).

So my question really is, will this pattern follow into the PC market?
08-17-2009, 01:46 AM
Hornet331

Quote:

Originally Posted by Mumak

We can discuss here another topic when already touching the x86 set. Everyone should agree that's it's mature and being held alive with extensions (MMX - AVX) to achieve performace.
Sure the existing market of x86 apps is biggg and that's what Intel knows well (pushing x86 even into ultra-mobile, trying to catch with ARM). But there must something big come since this ISA will reach its limits soon.
The current hunt for better IPC is a real pain. It's a waste of fixed-function hardware, complex algorithms which results in high consumption. Imagine that in fact you're wasting transistors which most of the time decide how to perfectly execute code that comes in. But why so much wasting? Why has the HW always do the same task to think how to execute something even if a code path is executed x-times the same way.. And what's the answer to this? EPIC - move the decisions from HW to SW (compiler). There's no need to have such intelligent CPU and waste resources each time. Let's have a more stupid CPU which executes instructions the way they are told by compiler. Moreover it's easier to upgrade SW (compiler) than HW.. A nice idea realised by Itanium.. There were other many great concepts (EFI, etc). But at a wrong time.. Crashed by incompatibility. But now, this might be possible using multi-core heterogenous concept... The way to move to new concepts by maintaining compatibility and slowly phase-out the mature ones.

I agree, if we want to see the next big jump in IPC x86 needs to go. If Epic is the right way... don't know.
08-17-2009, 04:03 AM
gosh

http://arstechnica.com/hardware/news...dk-for-x86.ars

Quote:

Why would you want to run GPU programs on a CPU?

Because you don't want customers to get one error message saying "You need to buy a OpenCL compliant GPU to run this software". If you didn't understand this buying the application which most doesn't, you will probably be angry when it doesn't work. There will be a lot of support calls for this.

I think most companies think a loooong time before adding a functionality where there is a need to have some sort of specific hardware installed. This decision is much easier to make (using the functionality) if it will work on all computers and you just need to add the driver in the installation where it will be installed if it is missing before.
08-17-2009, 06:14 AM
trinibwoy

Quote:

Originally Posted by gosh

Because you don't want customers to get one error message saying "You need to buy a OpenCL compliant GPU to run this software".

You mean the way games require DirectX and OpenGL compliant GPUs to run? There are software DirectX renderers too but you don't see anybody trying to play games on one.
08-17-2009, 07:28 AM
Chumbucket843

Quote:

Originally Posted by Hornet331

I agree, if we want to see the next big jump in IPC x86 needs to go. If Epic is the right way... don't know.

epic and vliw can suck it. x86 is fine with me for desktop although it is so bloated.
08-17-2009, 12:30 PM
Drwho?

The cool part is that it is all about competition at its best ... we will see :)
SoC will be part of it, small form factor with awesome performance level, small form factor with long battery life. It will always have space for a Super Mega high end GPU, the question is more like "when the integrated GPU turns to be good enough" ... It seems that we are a long way to this ... but moores Law is exponential, so, it is not that far ...
One thing for sure , people don't want to surrender the x86 compatibility. And Still, Windows is still concidered as "required" by many consumers. So, The PC will be in the center of the convergence, the question is about what will be the horse power providing part in the mind of many people. I think it will be the CPU, due to the fact that historically, it is the way it happens. Lrb new instruction is very exciting to me, I can create so much more with this that any OpenCL or DirectX compute, I get 100% architecture freedom access. Again, this is my opinion, you don t have to agree ...
We are living very exciting times, I see one direction, I am sure other people have other opinion and Direction ... Let the best win! :)
08-19-2009, 07:31 PM
saaya

Quote:

Originally Posted by trinibwoy

Ask yourself this. Why would you need OpenCL on a CPU if you have C/C++? These languages are designed to take advantage of highly parallel machines, they provide no benefit on a CPU over existing languages.

i thought that was the point? opencl brings c/c++ style coding to the next level by inviting gpus to the party... so now you can write code in opencl and a part can run on the cpu and another part on the gpu?

instead of writing code in c and then using cuda to run some of it on the gpu, opencls approach is to write the code in a language that can run on both well, and the code can then be shuffled around depending on workload and whether some code can be parallelized well or not?

Quote:

Originally Posted by trinibwoy

OpenCL doesn't give you any advantage over C++ no matter the number of threads. It's not magic, just a framework to help you formulate a solution. It provides an advantage on a CPU when you're testing/prototyping something you plan to run on a GPU or when you want to run the serial part of an application on a CPU with the data parallel part running on a GPU. CPU only applications won't see any benefit in OpenCL over regular programming languages. Don't get me wrong, it's great and it's needed. I'm just clarifying that most OpenCL applications will most certainly not be targeted at CPUs as there are already way more powerful and flexible options for doing so.

yes, exactly... thats what i meant :)

whats the diference between writing code in c and moving some to the gpu via cuda, and writing it in opencl, which is mostly based on c++ afaik (?) and then having it run on either the cpu or gpu?

the main diference is that opencl runs on any gpu right?
or is there any advantage of opencl compared to writing code in c and using cuda?

Quote:

Originally Posted by Drwho?

The massive number of Java Desktop is gone, no more need of those ... almost every computer runs x86 from AMD, intel or VIA.

what do you mean? as far as i know most coding nowadays is done in c/c++ java and PHP?

Quote:

Originally Posted by Drwho?

Last word ... Drivers seems to be a problem, there are a lot of empirical about this ... an healthy PC uses less driver in the long run.
Before people make fun of the intel drivers, some should clean up on the front of their doors ... ;-)

so whats the solution? have everybody write in machine code? 0_o

Quote:

Originally Posted by Drwho?

http://media.arstechnica.com/news.me...stacrash-1.jpg

whats that supposed to show though? that a bad driver causes problems? and? whats your point? again, whats the alternative? write everything in machine code?

thats a classic engineer pov, coders, write better/faster code!
while coders reply, engineers, make faster/simpler to code for processors!

Quote:

Originally Posted by Talonman

I believe you...

I posted once that I thought OpenCL would probably be slower than CUDA and got my head bit off! ;)

The thread was locked in the end.

they are basically the same approach from my understanding... cuda translates from c to machine language, opencl is based on c and... translates to machine language...

i suspect that its easier to manage how code is executed where and when in opencl than coding in c and using cuda, but im not sure... :confused:
anybody?

does opencl manage what code gets executed where and when, on cpu or gpu? can you implement a hook in the code and say run this on the gpu or cpu, or does opencl recognize what can be done on the gpu or cpu faster by itself? how about coding in cuda/c compared to that?

Quote:

Originally Posted by Drwho?

The soft drivers for sound cards were never as good as a Creative lab 48 bits cards, but they catch up the all required feature set. they are now a huge majority shipping.

yes, cause they are good enough and much cheaper... you dont need perfect, you dont need to be able to do everything... if you can do the most important thing good enough and are cheaper/more efficient than everybody else, you will succeed... *pearl jam* its evolution baby :D

Quote:

Originally Posted by Drwho?

I use mostly compilers for the soft architecture ... but most of the code that need performance on PCs IS using ASM.

* Most of the video codec do. Check x264 code or vTune DivX or windows Media ...
* Most of the 3D Rendering like 3DSMax uses intrinsics, almost a 1:1 translation to ASM.
* Most of audio programs have the MP3 parts using MMX.
* Most of the Drivers, including NV and ATI are using ASM to managed cache pollution properly when sending through PCIexpress ... MOVNT and so on ...

The list is very long, you just don t see it because we don t explain much details ...

as soon as Performance can give you a competitive advantage over your software competitor, people use ASM.

I help a lot of those guys.

Francois

wait, first you said drivers are a problem cause its such a thick software layer and asm is better, but then you say those very same drivers you complained about are actually written in asm... :P :D

and idk, does using mmx and sse and over x86 extension instructions count as writing in asm? :eh:
08-23-2009, 01:34 AM
trinibwoy

ooops, meant to send to PM :)
08-26-2009, 09:39 AM
Drwho?

Quote:

Originally Posted by saaya

wait, first you said drivers are a problem cause its such a thick software layer and asm is better, but then you say those very same drivers you complained about are actually written in asm... :P :D

and idk, does using mmx and sse and over x86 extension instructions count as writing in asm? :eh:

yeap, and that explain the need for drivers written by people with the highest market share and the smallest responsability in the BSOD ...
http://media.arstechnica.com/news.me...stacrash-1.jpg

obviously, somebody with large market share in blue has people writting ASM without glitch ... lol .... :rofl: :rofl: :rofl: That explain why you need more Intel hardware and drivers.
MMX and SSEx are asm instruction, from what I can tell, we use NASM or TASM , or MASM to assemble them ...

PS: WHERE IS THE GPGPU version of n! ... impossible to make isn't it ?
08-26-2009, 09:58 AM
Manicdan

wheres AMD on that chart?
08-26-2009, 10:27 AM
blindbox

Quote:

Originally Posted by Drwho?

PS: WHERE IS THE GPGPU version of n! ... impossible to make isn't it ?

You have more luck in asking this at nvidia's CUDA forums or the stanford boys. Not everyone here is a programmer.

Since you posted the same stuff at the John Carmack and PhysX thread, how is this even related to physics? I'm not sure if you need a physics engine to produce such accurate numbers or such big numbers to emulate physics.
08-26-2009, 11:10 AM
flippin_waffles

Quote:

Originally Posted by Drwho?

yeap, and that explain the need for drivers written by people with the highest market share and the smallest responsability in the BSOD ...
http://media.arstechnica.com/news.me...stacrash-1.jpg

obviously, somebody with large market share in blue has people writting ASM without glitch ... lol .... :rofl: :rofl: :rofl: That explain why you need more Intel hardware and drivers.
MMX and SSEx are asm instruction, from what I can tell, we use NASM or TASM , or MASM to assemble them ...

PS: WHERE IS THE GPGPU version of n! ... impossible to make isn't it ?

So, if you're hardware can't support the features of that OS, you can coherse with MS to change the requirements and simply refuse to produce a compliant chip, hurting consumers in the pocket, while lining Intel's pockets simultaneously. Then a couple years later show a pie chart to pat yourselves on the back, gloating, while having the luxury of changing the rules 3/4 of the way through the game? Oh the joy's of being a monopoly huh. Just imagine when AMD has the same marketshare, then picture what would happen to your pathetic little IGP if it went up against AMD's fully compliant hardware... ;)
08-28-2009, 10:14 PM
Drwho?

Quote:

Originally Posted by flippin_waffles

So, if you're hardware can't support the features of that OS, you can coherse with MS to change the requirements and simply refuse to produce a compliant chip, hurting consumers in the pocket, while lining Intel's pockets simultaneously. Then a couple years later show a pie chart to pat yourselves on the back, gloating, while having the luxury of changing the rules 3/4 of the way through the game? Oh the joy's of being a monopoly huh. Just imagine when AMD has the same marketshare, then picture what would happen to your pathetic little IGP if it went up against AMD's fully compliant hardware... ;)

Can we stay on technology ... the conspiration theories are getting kind of an old story ... even the EU made a report about the "fairness" of their point of view ... (THIS IS my very personal opinion here)
if you want to discuss about conspiration theories, well, www.x-files.com , the truth is out there .... I am a technologist, and I usually see people going to those arguements when they see that technology speaking, it is not easy to beat x86 ...

AMD has a fair chance, they have much bigger market share than Intel on discret GFX ... They acquired ATI, nobody forced them ... so , let s see ...

Xtremesystems.org here, not "911lawyer.com" here! :yepp::rofl::yepp:
08-29-2009, 05:30 AM
Chumbucket843

Quote:

Originally Posted by Drwho?

I am a technologist, and I usually see people going to those arguments when they see that technology speaking, it is not easy to beat x86 ...

power7 will destroy x86 in fp.
08-29-2009, 06:11 AM
Hornet331

Quote:

Originally Posted by Chumbucket843

power7 will destroy x86 in fp.

so did itanium already... :p:

and every gpu destroys every cpu available now and in the near futur flops wise...
08-29-2009, 06:39 AM
lockee

Quote:

Originally Posted by flippin_waffles

So, if you're hardware can't support the features of that OS, you can coherse with MS to change the requirements and simply refuse to produce a compliant chip, hurting consumers in the pocket, while lining Intel's pockets simultaneously. Then a couple years later show a pie chart to pat yourselves on the back, gloating, while having the luxury of changing the rules 3/4 of the way through the game? Oh the joy's of being a monopoly huh. Just imagine when AMD has the same marketshare, then picture what would happen to your pathetic little IGP if it went up against AMD's fully compliant hardware... ;)

:clap:
08-29-2009, 09:09 AM
Drwho?

Quote:

Originally Posted by Chumbucket843

power7 will destroy x86 in fp.

For a million dollars machine ... :rofl: with 2 high end Xeons, you smoke it for 1/10 of the prices :)
08-29-2009, 09:57 AM
flippin_waffles

Quote:

Originally Posted by Drwho?

For a million dollars machine ... :rofl: with 2 high end Xeons, you smoke it for 1/10 of the prices :)

???Are you actually using a price/performance argument to defend an Intel product??? wow that's priceless
08-29-2009, 10:06 AM
Chumbucket843

Quote:

Originally Posted by flippin_waffles

???Are you actually using a price/performance argument to defend an Intel product??? wow that's priceless

he has a good point when you build multi million dollar machines you will save more by having more efficient chips rather than performance per dollar but when you have a smaller server or desktop x86 is best.
08-29-2009, 02:42 PM
Chad Boga

Quote:

Originally Posted by flippin_waffles

???Are you actually using a price/performance argument to defend an Intel product??? wow that's priceless

When the price/performance difference is an order of magnitude different, then that is going to matter to a lot of people.

However much smaller price/performance advantages don't necessarily overcome brand premium, something Intel deservedly has earnt over the years.
08-29-2009, 04:22 PM
flippin_waffles

Quote:

Originally Posted by Chad Boga

When the price/performance difference is an order of magnitude different, then that is going to matter to a lot of people.

However much smaller price/performance advantages don't necessarily overcome brand premium, something Intel deservedly has earnt over the years.

I see; so price/performance only matters when it works in Intel's favor, as far as your concerned. Got it.

And if by earned you mean illegally using it's monopoly status to get to the point where it has said brand premium, then i'll agree. I'm sure there will come a time though when nobody remembers how Intel got to where it is, or there will be enough people like yourself that don't care. That'll be a sad day.
08-29-2009, 04:41 PM
Chad Boga

Quote:

Originally Posted by flippin_waffles

I see; so price/performance only matters when it works in Intel's favor, as far as your concerned. Got it.

Try reading what I wrote again, you might be able to reach the correct conclusion this time.

Quote:

And if by earned you mean illegally using it's monopoly status to get to the point where it has said brand premium, then i'll agree.

It never ceases to amaze me how Intel's rivals never fail to execute properly, never have botched products, are never behind on performance, it is always Intel's supposed monopoly status that holds back these other more deserving companies. :ROTF:
08-29-2009, 06:30 PM
[XC] riptide

Quote:

Originally Posted by Drwho?

:D :ROTF: :rofl: :up:

Who. Newsflash. This has been done on CUDA for a while now.

http://total-oc.ru/picture/img/d4e3e...rgamv0.3.0.PNG

Quote:

CPU: Intel Core 2 Duo E7200 @ 400x7 = 2.8 GHz,
MEM: Dual Channel DDR2 800 MHz (4-4-4-12)

GPU: GeForce 9600 GT(64SP,512Mb) @ 1900 MHz Shader Clock, 2000 MHz Memory Clock

600000! CPU time = 1129983 ms, GPU time = 141736 ms, Acceleration = x8.0
500000! CPU time = 771931 ms, GPU time = 96640 ms, Acceleration = x8.0
400000! CPU time = 479362 ms, GPU time = 59777 ms, Acceleration = x8.1
350000! CPU time = 360969 ms, GPU time = 44940 ms, Acceleration = x8.1
300000! CPU time = 257448 ms, GPU time = 31722 ms, Acceleration = x8.2
250000! CPU time = 177145 ms, GPU time = 21399 ms, Acceleration = x8.3

http://forums.overclockers.ru/viewto...0339&start=120

But I'll concede that >1,000,000! from my limited knowledge of algorithms and my good knowledge of maths that the GPU would soon hit a memory problem. A Tesla card would help.. :D

Show 100 post(s) from this thread on one page