50% slower than AMD! Intel FAIL again with the HD4000 graphic hardware.

[crazycheese]

most of your point are only true on: WINDOWS;;;

whatever it doesn’t matter in 2-3 months amd will bring a new quatchannel desktop socket and a octachannel server socket.

the bulldozer successor will perform well on the new sockets with new chip-sets.

Nope, all my points are OS-agnostic.
The scheduler which I meant in 4th point is CPU scheduler (o-o-o execution etc). Not OS scheduler, that should be actually be mostly ignored (I think). The OS scheduler is not good at assigning tasks to cores, cause it lacks internal details. It is good for tasks prioritization and resposibility etc.

[crazycheese]

AMD's Fusion GPUs are good enough that you don't need a dedicated GPU unless you are a hardcore gamer. Intel's Sandy Bridge may be 10-30% faster than AMD's Llano clock for clock, but Llano's GPU is ~100-200% faster than SB's which makes for a much better all-around performer (that can run modern games in 'medium' settings).

That's one part of the equation. The other is drivers, where Intel faces significant problems. One year later and Sandy Bridge still fails to vsync properly and still suffers from graphics corruption (esp. in Gnome Shell). The new Atoms are equipped with a DX10/GL3 PowerVR GPU - but guess what. Intel delayed them due to 'driver issues' and finally announced they will only support DX9 (no OpenGL!) and 32-bit Windows. No Linux, no 64-bit, just 32-bit Windows.

And that's why you don't buy Intel GPUs: their drivers suck. At least with AMD you know you'll get decent support on Linux (with open-source drivers - fglrx sucks) and great support on Windows. No such guarantees with Intel.

i3-2105, things that I observed:
- 2 cores performed faster that 4cored phenom, eats less than half of energy
- it synced properly. if you give me special details, i can test on weekend where it does not sync. Had Linux mint 12 installed (I think it was gnome shell 3, unsure) and urt/openarena testings
- fpsed 60 on 1600/900 maxed details on urt, at all time, on all maps. 9800 gt was equally fast. If you ask, id say hd3000 is very powerful igp.
- I wouldnt take powervr/g500 chips as intel chips, very probably they outsourced and powervr refuses to release specs.
- video acceleration
- intel supports newest cpus first, amd oldest first.
driver pretty stable, no crashes or bugs after 16 hr run.

I refuse to comment on fglrx "guarantee"...


about no 64bit driver for Atom - Atom is 32bit cpu..

[kobblestown]

Nope, all my points are OS-agnostic.
The scheduler which I meant in 4th point is CPU scheduler (o-o-o execution etc). Not OS scheduler, that should be actually be mostly ignored (I think). The OS scheduler is not good at assigning tasks to cores, cause it lacks internal details. It is good for tasks prioritization and resposibility etc.

Errr, what?! It's precisely the OS scheduler's task to say which thread runs on which core (I don't think that BD's modules are exposed as such). The CPU scheduler (if there's such a thing) cannot move a thread to a different module. It cannot even move a thread to a different core within the same module. Or at least it shouldn't. Again, that's the OS scheduler's task.

The problem with BD performance on Windows is precisely the fact the OS scheduler doesn't distinguish between cores in the same module and cores on different modules and how this difference affects performance. Hence, it cannot make the proper scheduling decision. And there's nothing the CPU can do about this, as shown by the dismal performance of BD under Windows. Presumably, the Linux scheduler is a bit better in this respect but I guess it will improve with time too.

[crazycheese]

Errr, what?! It's precisely the OS scheduler's task to say which thread runs on which core (I don't think that BD's modules are exposed as such). The CPU scheduler (if there's such a thing) cannot move a thread to a different module. It cannot even move a thread to a different core within the same module. Or at least it shouldn't. Again, that's the OS scheduler's task.

If CPU scheduler, scheduling agent, resource watch/manager sees that cores are loaded inefficiently, it should override as long as out of order does not influence the result. OS scheduler does not know about technical details and its latency is way to high to manage that.
It is same situation as VLIW inefficiency. Im suspect sb does this.

[bridgman]

amd (supports) oldest first

That's not a policy or anything, just a technical constraint. Each GPU generation builds on the one before, so we had to start with the oldest unsupported parts and work forward until we caught up with the release of new hardware.

It took ~4 years, but then again there were 6 generations of hardware to support, more if you include the KMS rewrite for 4 earlier generations.

[kobblestown]

If CPU scheduler, scheduling agent, resource watch/manager sees that cores are loaded inefficiently, it should override as long as out of order does not influence the result. OS scheduler does not know about technical details and its latency is way to high to manage that.
It is same situation as VLIW inefficiency. Im suspect sb does this.

Dude, it just doesn't work like that! You've got confused by Hyperthreading, most probably. With HT each core can handle multiple threads simultaneously. But in fact, it cannot. It can only handle a single thread at any given cycle (I guess that goes for each pipeline unit individually). It only switches from thread to thread when, for instance, one of the threads is waiting for data to arrive or in a round robin fashion when more threads are ready for execution. But it cannot move a thread to a different core. It doesn't matter if you think it's a good idea or not. There's no processor that I know of, that is equipped with such hardware. That's what the OS is for.

[Tgui]

i3-2105, things that I observed:
- 2 cores performed faster that 4cored phenom, eats less than half of energy
- it synced properly. if you give me special details, i can test on weekend where it does not sync. Had Linux mint 12 installed (I think it was gnome shell 3, unsure) and urt/openarena testings
- fpsed 60 on 1600/900 maxed details on urt, at all time, on all maps. 9800 gt was equally fast. If you ask, id say hd3000 is very powerful igp.
- I wouldnt take powervr/g500 chips as intel chips, very probably they outsourced and powervr refuses to release specs.
- video acceleration
- intel supports newest cpus first, amd oldest first.
driver pretty stable, no crashes or bugs after 16 hr run.

I refuse to comment on fglrx "guarantee"...


about no 64bit driver for Atom - Atom is 32bit cpu..

I had an Intel 4500MHD in my old HTPC, and now an HD2000 in my current core i5 HTPC. Both work fine, can play basic 3D games and are fast enough to render HD video at 1080P. These machines were/are up for months at a time as well.

I've had a number of ATi cards and had nothing but pain with their open and closed source drivers. It got to the point I just went out and bought an NVIDIA card for my workstation.

I like Intel's GPUs. For me they pretty much just work in a machine with limited graphics needs.

Though obviously trolling, even if "INTEL FAIL" inside graphics are 50% slower than "AMD!", they're still 50% faster than what needs dictate.

[Qaridarium]

Q, I am waiting for the AMD announcement today

hey I’m waiting to i can not force amd to do it faster.

[Qaridarium]

Q does have a point in this thread. A CPU with a good integrated GPU is *much* better than dealing with Optimus crap.

AMD's Fusion GPUs are good enough that you don't need a dedicated GPU unless you are a hardcore gamer. Intel's Sandy Bridge may be 10-30% faster than AMD's Llano clock for clock, but Llano's GPU is ~100-200% faster than SB's which makes for a much better all-around performer (that can run modern games in 'medium' settings).

That's one part of the equation. The other is drivers, where Intel faces significant problems. One year later and Sandy Bridge still fails to vsync properly and still suffers from graphics corruption (esp. in Gnome Shell). The new Atoms are equipped with a DX10/GL3 PowerVR GPU - but guess what. Intel delayed them due to 'driver issues' and finally announced they will only support DX9 (no OpenGL!) and 32-bit Windows. No Linux, no 64-bit, just 32-bit Windows.

And that's why you don't buy Intel GPUs: their drivers suck. At least with AMD you know you'll get decent support on Linux (with open-source drivers - fglrx sucks) and great support on Windows. No such guarantees with Intel.

hey you are right ! *Happy* thank you for helping me.

[crazycheese]

Dude, it just doesn't work like that! You've got confused by Hyperthreading, most probably. With HT each core can handle multiple threads simultaneously. But in fact, it cannot. It can only handle a single thread at any given cycle (I guess that goes for each pipeline unit individually). It only switches from thread to thread when, for instance, one of the threads is waiting for data to arrive or in a round robin fashion when more threads are ready for execution. But it cannot move a thread to a different core. It doesn't matter if you think it's a good idea or not. There's no processor that I know of, that is equipped with such hardware. That's what the OS is for.

No man, I have done courses in operating systems development and I fairly know what Im talking about. I have not been following development of x86 hardware guts since Pentium/am5x86 though, that is why I'm operating in generic terms.
I don't mean HT, HT seen in core2 hardware is, as you described correctly, attempt to show double amount of cores to external interfaces for the reason to saturate IO and then make internals do the job. This approach is win most of the times, if hardware is capable to manage itself precisely; and loose when cores are forced to work on completely different tasks using high IO & low instruction load OR when they do lots of JMPs - all this results in cache trashing; under HT - cache trashing plus core has only 1/2 of usable cache, which may actually slow down execution compared to execution without HT(1/2 of cores). I think phoronix has this already covered (how intel/amd scale).

The part I mean is this:

Branch prediction and memory execution and ordering - cpu internal scheduling logic. I didn't mean "scheduler" as it is classically understood belonging withing OS kernel logic. It is by far lower level, but it does group instructions to memory space and throws them on single cores/modules layer-wise till cores are at 90%.

Optimally it should monitor the load at lowest level and quickly issue reordering. This will allow specific cores to be loaded till they are at 90% of capacity; and only then reorder tasks to other cores - sleeping meanwhile.
This would mean those unneeded cores can sleep - less energy consumption. Same logic is used within GPU; zero load, or how AMD marketing calls it. I have already told they should really use the GFX experience in CPU segment.
On Bulldozer, that would mean modules will be loaded precisely, decreasing load spread. Call it "intelligent instruction grouping" if you want.