AMD RV770 refresh -> RV790

[rjc]

Chiphell is saying, a new cost down 4890:
1) Frequencies the same
2) Board is 8 layer PCB
3) Power unit is horrible to look at, core ST 3 phase, [something can't quite make out - Swiss Sa, memory, east-west]
Should reduce costs $10-20 over current 10 layer board.

Further in thread:
Earliest RV770 board design back from the dead, XTX continue with 10 layer board, XT 8 layer is sufficent. Something cant quite make out about a GDDR3 version with large memory.

 

[ahu]

No they certainly aren't mutually exclusive, OpenCL just makes CUDA obsolete.

OpenCL might make C for CUDA obsolete (and probably should in the long run). Different thing.

CUDA is not an architecture. It is merely an API and programming model. The exact same thing that OpenCL is: an API and a programming model.

Huh? CUDA is nVidia's hardware archtecture for GPGPU. The CUDA driver can be regarded as API, yes. But the OpenCL functionality is clearly on top of that driver (unlike DirectX compute), at least according to official nVidia documents.

(sorry for the OT)

 

[fellix]

Chiphell is saying, a new cost down 4890:
1) Frequencies the same
2) Board is 8 layer PCB
3) Power unit is horrible to look at, core ST 3 phase, [something can't quite make out - Swiss Sa, memory, east-west]
Should reduce costs $10-20 over current 10 layer board.

The cost cuts will probably affect the choice of VRM controller for something cheaper than Volterra, e.g. no software volt mods.

 

[Tchock]

Renesas for the memory, ST for the Core.

 

[aaronspink]

Huh? CUDA is nVidia's hardware archtecture for GPGPU. The CUDA driver can be regarded as API, yes. But the OpenCL functionality is clearly on top of that driver (unlike DirectX compute), at least according to official nVidia documents.

Nvidia's hardware architecture for GPGPU is whatever they have designed for DX X.X.

Trying to use the CUDA name for that is just marketing. They are trying to make it seem like CUDA will be around and that OpenCL is dependent on CUDA when the truth is that OpenCL is the SAME as CUDA as far as where is slots on the hardware/software stack. OpenCL obsoletes CUDA. Why use glide when you can use OpenGL and D3D and support all vendors.

3dfx could of re-marketed Glide as an "Architecture" but is would have about as much truth as Nvidia marketing CUDA as an architecture. CUDA, OpenCL, OpenGL, D3D, DX CS, etc are all APIs, API specifications, and programming models. They aren't hardware architecture.

 

[Arty]

Contrary to the >300W 4890X2 not possible reports, Theo says that the 4890X2 is coming.

He adds: "You can expect 8+6-pin Radeon HD4890X2 2GB and 8+8-pin overclocked Radeon HD4890X2 2GB and 4GB parts."

 

[AnarchX]

Which partner would take the risk to build a not PCIe compliant card?

 

[Silent_Buddha]

Which partner would take the risk to build a not PCIe compliant card?

I can only imagine ATI is considering it because some partner is requesting the ability to do it.

Regards,
SB

 

[Kaotik]

Contrary to the >300W 4890X2 not possible reports, Theo says that the 4890X2 is coming.

He adds: "You can expect 8+6-pin Radeon HD4890X2 2GB and 8+8-pin overclocked Radeon HD4890X2 2GB and 4GB parts."

Theo can say whatever he wants, those 8+8 cards would never get PCI SIG approval (due going past the specifications) on top of them, and thus could never be marketed as PCI Express products

 

[Jawed]

Which partner would take the risk to build a not PCIe compliant card?

ATI and NVidia cards are already non-compliant:

http://forum.beyond3d.com/showpost.php?p=1266451&postcount=295

and earlier posts.

Jawed

 

[Kaotik]

ATI and NVidia cards are already non-compliant:

http://forum.beyond3d.com/showpost.php?p=1266451&postcount=295

and earlier posts.

Jawed

This, as far as I know, is only under Furmark, which acts like "power virus" according to some, stressing every part of GPU at 100% all the time, which is something no normal application does, and apparently thus "not counted"

 

[Jawed]

3DMark2001 also seemed to induce very high power consumption (murkier story, to be fair) - maybe that doesn't count cos it's DX-something-so-ancient-no-one-wants-to-think-about.

Jawed

 

[Scali]

And then there's the Larrabee factor. Why program OpenCL when...

Well, OpenCL abstracts parallelism in a different way than conventional x86 programming (even with extensions like OpenMP and SSE intrinsics and all).

So I can imagine that people will still use OpenCL on Larrabee, because its type of abstraction of the hardware suits their problem domain better than conventional programming languages.

 

[digitalwanderer]

3DMark2001 also seemed to induce very high power consumption (murkier story, to be fair) - maybe that doesn't count cos it's DX-something-so-ancient-no-one-wants-to-think-about.

Jawed

Ooooh! I didn't run 3dm2k1 on it yet, thanks Jawed!

 

[Jawed]

Well, OpenCL abstracts parallelism in a different way than conventional x86 programming (even with extensions like OpenMP and SSE intrinsics and all).

So I can imagine that people will still use OpenCL on Larrabee, because its type of abstraction of the hardware suits their problem domain better than conventional programming languages.

Agreed, I was just posing a wider perspective. Intel has its own tools too and something like Ct seems pretty intriguing.

OpenCL integrates task parallelism which also makes for a nice match for the fluid programmability of Larrabee's scalar cores.

This also raises an interesting question I've been meaning to ask: compilation of code is a fairly compute-intensive problem. Will something like OpenCL be a good platform to create a high-performance highly-optimising compiler (including vectorisation and unrolling analysis, doing statistical modelling of execution profile?).

Jawed

 

[Scali]

OpenCL integrates task parallelism which also makes for a nice match for the fluid programmability of Larrabee's scalar cores.

Actually, I think the compiler will abstract the SIMD units to appear like 16 parallel scalar cores, rather than using the legacy x86 scalar stuff.

 

[rpg.314]

Agreed, I was just posing a wider perspective. Intel has its own tools too and something like Ct seems pretty intriguing.

OpenCL integrates task parallelism which also makes for a nice match for the fluid programmability of Larrabee's scalar cores.

This also raises an interesting question I've been meaning to ask: compilation of code is a fairly compute-intensive problem. Will something like OpenCL be a good platform to create a high-performance highly-optimising compiler (including vectorisation and unrolling analysis, doing statistical modelling of execution profile?).

Jawed

I doubt if the compilation is simd freindly at all. Parallel compiles you can already do with make -j8 on your Core i7

I think the bottleneck for optimization is that that it is an NP complete problem in many cases. So compilers reduce the work they do to reduce compile times more than anything else.

 

[aaronspink]

This, as far as I know, is only under Furmark, which acts like "power virus" according to some, stressing every part of GPU at 100% all the time, which is something no normal application does, and apparently thus "not counted"

It doesn't matter if it is a "power virus" if it takes the card or chip out of spec. Relate this back to CPUs, where power virus like workloads instead of pushing the power out of spec, end up throttling to the power envelope.

Also in general, depending not having power viruses run on your hardware is poor engineering.

And, furmark really isn't a power virus as it is actually producing something.

 

[Kaotik]

It doesn't matter if it is a "power virus" if it takes the card or chip out of spec. Relate this back to CPUs, where power virus like workloads instead of pushing the power out of spec, end up throttling to the power envelope.

Also in general, depending not having power viruses run on your hardware is poor engineering.

And, furmark really isn't a power virus as it is actually producing something.

Yes, but intentionally designed to stress the GPUs every part at 100%, while same "products" (ie, same gfx etc) could be achieved with normal workloads too.

 

[crystall]

This also raises an interesting question I've been meaning to ask: compilation of code is a fairly compute-intensive problem. Will something like OpenCL be a good platform to create a high-performance highly-optimising compiler (including vectorisation and unrolling analysis, doing statistical modelling of execution profile?).

No, optimizing compilation is probably the less vectorizable problem I can think of. A compiler is basically a huge blob of serial code, pointer-chasing algorythms and unpredictable branches. As a bonus most modern compilers have been in development for quite a long time so their code bases are huge, complex and hard to deal with (and contain extremely old code for the parts which have been mostly stable in the last few years). To put the situation in perspective a few months ago somebody posted a comment on GCC's main development list which sounded more or less like:

"I will not live long enough to see GCC going multi-threaded"