[ToTTenTranz]

Originally Posted by pjbliverpool

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.

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 (!!).

[pjbliverpool]

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.

[Mobius1aic]

Originally Posted by ToTTenTranz

Intel bought Havok and has nothing to show, except for.. an ARM + Mali T604 implementation (!!).

I looked that up, and indeed it is impressive! I wonder how Havok got away with doing ARM related stuff being owned by Intel 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.

[Gubbi]

Originally Posted by ToTTenTranz

Well.. Intel did buy Havok some years ago, and we're yet to see any fruits at all from this "joint venture".

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

[-tkf-]

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.

[Dave Baumann]

Originally Posted by TheWretched

AMD stopped their monthly driver releases effectively today...

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.

[tunafish]

Originally Posted by -tkf-

Could someone explain a bit more about the AVX2 stuff?

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?

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?

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.

[TheWretched]

Originally Posted by Dave Baumann

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.

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.

[Mobius1aic]

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.

[nAo]

Originally Posted by tunafish

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.

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/)

[nAo]

Originally Posted by Mobius1aic

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.

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.

[Gubbi]

Originally Posted by nAo

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/)

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

[nAo]

Originally Posted by Gubbi

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

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.

[Gubbi]

Originally Posted by nAo

My point is that a gather instruction doesn't make some given code any more vectorizable.

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