Is Ivy Bridge HD4000 more powerful than PS360?

Haswell seems ready to shock the console world...just 12 more months and you may see guys like Asus, Valve, Acer, Apple...putting out ITX gaming boxes?? AVX2, FMA4, L4 cache, GT3 40 EU(like a dream!), transactional memory...all seems like it is built for gaming....could Haswell even go toe to toe with Wii U??? DX10 vs DX11....3 cores cpu vs 4 cores cpu...feels close man!

...granted the fillrate limitation do not come into effect first....AT fillrate tests seem low..
http://www.anandtech.com/show/5871/intel-core-i5-3470-review-hd-2500-graphics-tested/4

Wii U 4850 class gpu fillrate is 10gp/s

Ivy bridge mem bandwidth is 25.6gb/s...PS3 levels...so Haswell will improve on the numbers and efficiency, logically a Haswell ITX gaming box can run DX11 games at 720p...comfortably? Who knows what will Lucid2 brings...put a GT740M with HD5000...turn on Lucid...boom!...or hype?
 
Last edited by a moderator:
Rangers said:
Out of curiosity was the die size of the newest 360 iteration ever measured? Anand never measured it cause he didn't want to tear his heat spreader off, but I seem to remember we got a measurement from somebody...
Click to expand...

I don't remember where I got it, but xb360 total die size at current node was 213mm2.

Projected die size at 28nm of <120mm2.

So yeah, for the size, IvyBridge should be cleaning the xb360's clock!
 
gongo said:
Haswell seems ready to shock the console world...just 12 more months and you may see guys like Asus, Valve, Acer, Apple...putting out ITX gaming boxes?? AVX2, FMA4, L4 cache, GT3 40 EU(like a dream!), transactional memory...all seems like it is built for gaming....could Haswell even go toe to toe with Wii U??? DX10 vs DX11....3 cores cpu vs 4 cores cpu...feels close man!
Click to expand...

In CPU terms Haswell should walk all over WiiU.. It'll be packing very near 500 GFLOPS in the AVX2 units alone.

Regarding the GPU it's not so clear. I'd peg the HD4000 at about 50% faster than the HD3000 overall even though on paper it should be much faster than that - possibly due to memory bandwidth limitations. I'd also say the 4000 is a little faster than current gen consoles, maybe by as much as 25% which Llano being about 25% faster than that.

Haswell is pegged to be between 50% and 200% faster than Ivybridge in GPU terms which would thus put it a little less than twice as fast as the current consoles at the low end or as much as 3.75x faster. Once you add in the potential of AVX2 on the CPU itself for graphics (around another 500 GLOPS) then your talking about a system which has easily 2-4x the graphical power of PS360 with maybe 4-5x the general CPU performance.

So in comparison to WiiU, I'd say odds are that Hasell will outperform it in graphics capability and certain that it will significantly outperform it in CPU capability.

Wii U 4850 class gpu fillrate is 10gp/s
Click to expand...

I doubt it will be that quick. If it were then only the most optimistic estimations of Haswell would be competitive.
 
Ivybridge and Haswell are certainly interesting in that they offer greater than current generation console performance on a single tiny, low power chip. But I think the more interesting application for the GPU's in them is as a GPGPU/Physics co-processor working in tandem with the CPU cores and using a discrete GPU to handle the rendering.

Remember how excited many were about the PhysX PPU and the thought of a dedicated physics processor in a PC? Well we're there now. Everyone with a Sandybridge or higher CPU already has a powerful dedicated SIMD processor inside their PC sporting between 100 and 300GFLOPS that's going totally unused. Imagine what could be done if that were turned to physics and other GPGPU tasks while the discrete GPU handles the heavy graphics lifting.

Imagine what Haswell could do if fully utilised in that way with around 1.25 TFLOPS (CPU+GPU) to dedicate to none rendering workloads. That's like dedicating 4 entire Xbox 360's to power your game code, physics and AI while a separate GPU with 20x the rendering power of Xenos (680 level) handles the graphics.
 
pjbliverpool said:
Ivybridge and Haswell are certainly interesting in that they offer greater than current generation console performance on a single tiny, low power chip. But I think the more interesting application for the GPU's in them is as a GPGPU/Physics co-processor working in tandem with the CPU cores and using a discrete GPU to handle the rendering.

Remember how excited many were about the PhysX PPU and the thought of a dedicated physics processor in a PC? Well we're there now. Everyone with a Sandybridge or higher CPU already has a powerful dedicated SIMD processor inside their PC sporting between 100 and 300GFLOPS that's going totally unused. Imagine what could be done if that were turned to physics and other GPGPU tasks while the discrete GPU handles the heavy graphics lifting.

Imagine what Haswell could do if fully utilised in that way with around 1.25 TFLOPS (CPU+GPU) to dedicate to none rendering workloads. That's like dedicating 4 entire Xbox 360's to power your game code, physics and AI while a separate GPU with 20x the rendering power of Xenos (680 level) handles the graphics.
Click to expand...

Well.. Intel did buy Havok some years ago, and we're yet to see any fruits at all from this "joint venture".
In fact, I think that physics processing have pretty much stagnated for the past.. 4 years?
Despite lots of cool things being shown in several entertainment/electronics shows throughout the years, we're still at the same point as we were back then: nVidia has PhysX, AMD shows hardware-accelerated bullet physiscs but no one uses it in games, Intel bought Havok and has nothing to show, except for.. an ARM + Mali T604 implementation (!!).
 
The destructible environments in UE4 look to be a step above what we've seen before, but nothing that couldn't be achieved on a modern quad core to be honest, certainly not requiring a dedicated GPU to run on. With good reason really since the next generation of consoles certainly won't have that kind of power to spare away from rendering.

No unfortunately it looks like all that processing capability will go largely unused in high end PC's. It would be incredible to see what such hardware would be capable of in a console environment but that clearly isn't going to happen in the upcoming generation.
 
ToTTenTranz said:
Intel bought Havok and has nothing to show, except for.. an ARM + Mali T604 implementation (!!).
Click to expand...

I looked that up, and indeed it is impressive! I wonder how Havok got away with doing ARM related stuff being owned by Intel :p Also, are not those the ogres Havok used a while back for Intel Larrabee and physics demos?

Impressive work and nice example of how mobile is really making strides.
 
ToTTenTranz said:
Well.. Intel did buy Havok some years ago, and we're yet to see any fruits at all from this "joint venture".
Click to expand...

Except Havok is now the dominant physics engine used in games, and it runs exclusively on CPUs, of which the majority are made by Intel (consoles not withstanding). Havok physics thus creates demand for CPUs as opposed to Nvidia's focus on making PhysX run fast on their GPUs.

Only TWIMTBP titles support PhysX these days.

Cheers
 
Could someone explain a bit more about the AVX2 stuff?

The GPU is now a part of the CPU at least physical , but when i installed a Ivy this weekend it (of course) still needed drivers to show up. How does that work? Since we know that PC games have a tendency to never really use the CPU's to the fullest, most likely because they find it more worthwhile and easier optimizing for the GPU stuff. But could Intel ever hope to utilize some of the untapped CPU power for their GPU drivers? and is it even feasible?

In a console there wouldn't be a problem like that so i would guess the i7-3770k i installed would have no problem matching a PS/360.

Just for the hell of it i installed a Lego game demo, and it ran fine in 720p, impressive considering the size of Graphics card that once was needed to produce graphics like that.
 
TheWretched said:
AMD stopped their monthly driver releases effectively today...
Click to expand...
That is not really relevant to the point. While we have stopped the rigid monthly release that does not mean there will necessarily be a reduction in the number of driver releases and it bears absolutely no position on the level of resource, investment or capabilities of the primay D3D drivers.
 
-tkf- said:
Could someone explain a bit more about the AVX2 stuff?
Click to expand...

AVX2 basically brings FMA, which doubles FPU throughput, and much more importantly, Gather, which allows a lot of code that's not previously vectorizable (or is only poorly vectorizable) to be vectorized. Basically, AVX2 is the biggest advance in the x86 vector instruction set since, well, when it was first developed. It's very much a big deal.

Of course, most software won't be able to *use* that, not until majority of users have AVX2-capable cpus.


The GPU is now a part of the CPU at least physical , but when i installed a Ivy this weekend it (of course) still needed drivers to show up. How does that work?
Click to expand...
GPU drivers aren't really just drivers in the strict sense of the word. The OpenGL and DirectX APIs are quite high-level. Shaders are passed as compilable program code, so the minimum you need to have a functional GPU is an implementation of the API libraries for your GPU, and a compiler for shader code. Without that, all you have is framebuffer.


Since we know that PC games have a tendency to never really use the CPU's to the fullest, most likely because they find it more worthwhile and easier optimizing for the GPU stuff. But could Intel ever hope to utilize some of the untapped CPU power for their GPU drivers? and is it even feasible?
Click to expand...
It's feasible. Many believe that the long-term goal of Intel is to reunify the GPU and CPU parts of their chips -- that is, extend the AVX2 instruction set until it's good enough to run shader code, and then move all the work there. That's very long-term, but until they get there, the CPUs are going to get better at graphics-like loads every iteration, and since GPU job control is implemented as part of that DirectX/OpenGL driver stack, nothing stops them from pushing a part of the work to the CPU whenever it seems a good fit.

Traditional systems can't really do this because the PCI-e road between the GPU and CPU is really too narrow and long for it, but when they are on the same chip, this is not an issue.
 
Dave Baumann said:
That is not really relevant to the point. While we have stopped the rigid monthly release that does not mean there will necessarily be a reduction in the number of driver releases and it bears absolutely no position on the level of resource, investment or capabilities of the primay D3D drivers.
Click to expand...

Don't get me wrong. I don't think this is bad at all... I'd much more prefer if you (?) finally released a changelog for Linux again... that's a lot worse than a monthly release, if you can't tell if it works on your system or not beforehand.
 
What level of practicality and feasibility are we at today to getting rid of unified shaders in general and going with ultra wide vector processing on wide x86 cores coupled to texture units and ROPs? I'm not talking a Larrabee approach with narrow x86, but fully designed around being a modern, wide CPU as well (like current i-series). It seems like a bit of a holy grail.
 
tunafish said:
AVX2 basically brings FMA, which doubles FPU throughput, and much more importantly, Gather, which allows a lot of code that's not previously vectorizable (or is only poorly vectorizable) to be vectorized. Basically, AVX2 is the biggest advance in the x86 vector instruction set since, well, when it was first developed. It's very much a big deal.
Click to expand...
The gather instruction is nice and everything but it doesn't magically make more code vectorizable. Remember that you can just convert a gather into a bunch of loads (and if your compiler is smart in some cases it can reduce the number of loads..) so if some code is vectorizable with gather is also vectorizable without gather (for instance see the ispc compiler: http://ispc.github.com/)
 
Mobius1aic said:
What level of practicality and feasibility are we at today to getting rid of unified shaders in general and going with ultra wide vector processing on wide x86 cores coupled to texture units and ROPs? I'm not talking a Larrabee approach with narrow x86, but fully designed around being a modern, wide CPU as well (like current i-series). It seems like a bit of a holy grail.
Click to expand...
Because you are still missing a ton of fixed function silicon (not just for compute, but also for scheduling, on-chip buffers, etc..) and without it you are likely to build a power inefficient and/or slow machine.
 
nAo said:
The gather instruction is nice and everything but it doesn't magically make more code vectorizable. Remember that you can just convert a gather into a bunch of loads (and if your compiler is smart in some cases it can reduce the number of loads..) so if some code is vectorizable with gather is also vectorizable without gather (for instance see the ispc compiler: http://ispc.github.com/)
Click to expand...

If they just implement gather as a sequence of loads, then there won't be much to gain from vectorizing code.

I don't think they would have bothered adding gather if there isn't a fast implementation to back it up. Something like 8 (or more) parallel loads going to the (inclusive) L2 at once, something akin to the defunct Alpha Tarantula.

Cheers
 
Gubbi said:
If they just implement gather as a sequence of loads, then there won't be much to gain from vectorizing code.

I don't think they would have bothered adding gather if there isn't a fast implementation to back it up. Something like 8 (or more) parallel loads going to the (inclusive) L2 at once, something akin to the defunct Alpha Tarantula.

Cheers
Click to expand...
That's not my point. I said nothing about the gather instruction implementation.
My point is that a gather instruction doesn't make some given code any more vectorizable.
 
nAo said:
My point is that a gather instruction doesn't make some given code any more vectorizable.
Click to expand...

True.

But a large performance delta will make developers strive to write vectorizable code. If the gather implementation doesn't buy you any performance, there is no incentive to invest the extra effort.

Cheers
 
You must log in or register to reply here.
Back
Top