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

[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.

[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.

[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.

[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.

[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]

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..

[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.

[Panix]

I stopped reading Q's posts long ago. Some months back, he was making some semi-good posts. Now he's just trolling all over the place.

Good idea.

One gets the impression that AMD is struggling just from reading comments on various forums of related discussions and the most recent feedback on bulldozer.

But, even the Quanta report should be reason for concern.

http://www.theverge.com/2012/1/5/268...e-chip-lawsuit
http://www.bloomberg.com/news/2012-0...computers.html

My impression was that AMD OSS drivers was still a mess in Linux compared to using Intel. At least, for using more recent AMD laptops. I notice more reports of problems in the AMD OSS section here than Intel's.

Apple also uses Intel for their machines.

[ungoliant]

I suggest to Phoronix that they make a new phoronix Platinum Edition, a little more expensive than Phoronix Premium, but with no Qaridarium posts at all.
I bet they would get more income.

Of course, they would need to remove the ignore feature, which i'm about to start using now.

[Kano]

So you really call AMD win drivers great? Maybe for DX games, but not for OpenGL. Rage was released 4th oct 11, but there are still only "preview" drivers to run that game. Those drivers with additional char behind usually contain code of the driver that will be out +1 month later. They do absolutely not manage to fix the OpenGL part, no they introduce new bugs, at least for hd 5670 and 11-12. Intel is not perfect too, hopefully there will be a working X stack combination soon. xvba in fglrx is definitely not that advanced, missing h264 l5.1 support. intel already exposes h264 encoding profiles via vaapi, but i am waiting for the killer app for linux yet to use it.