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

[crazycheese]

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.

John, guys, I understand your approach, but it is not my approach. If you have certain approach, then you apply whole different method and same method can be seen as least efficient and most efficient depending on view only.
That said, you develop legacy, tail, hardware and slowly approach the "head of the fish". But your company sells the "head of the fish", and that head is supported only via proprietary.
So hence your approach prioritizes following strategy:
1) you depend on proprietary, you cannot remove it - your selling of "head"s will stop - and hence support of whole drivers stops
2) your proprietary will stay more advanced than opensource, forever; see 1.
3) you will throw huge HR into segment that does not touch opensource at all, and is largely uninteresting for non-enterprise high volume consumers/retailers
4) you will never accomplish to utilize complex architectures seen on top models efficiently in opensource; because you simply lack human resources - which are gained only and only from selling of those cards
5) this means you are not interested in selling your cards to be used by opensource solutions

This goes completely different with intel. Intel prioritizes development on "head of the fish", and only then, if ever, tail. This gives exact the situation their legacy hardware is non-usable under linux, but they have fast pace open development with top-notch current hardware. I want to buy newest hardware and use it with opensource - this is why intels approach is better for me.

Even if I would buy "high performance by factor 200%" AMD APU, it will reach its "200%" performance only via proprietary driver, and even then it is widely known you prioritize directx way more than opengl.
So under linux, your "200% APU" becomes "50%" APU. Plus currently less efficient PM and performance per core ratio. This is why only intel stays within choice.

Of course, if id go high gpu performance way, it will be different - only because intel does not do high-performance gpu hardware. Then, we will have a clash between two evils of red and green.
Your directx love, shorter core packages (glibc,kernel,xorg) and hardware generations support window pretty much signs the decision yet again not in your favorite.

John, you are wonderful, patient, consecutive man; but its all about company approach, not charisma.


Lets talk about my recent purchases. Recent year I have purchased used 260gtx instead of hd57xx; brand new 560ti instead of 6970 for friend of mine; i3 instead of 41xx/A6. Total costs I think around 1000€. For linux hardware.
You see, linux people do go shopping and they shop for hardware which supports their OS.
It is common practice that companies detect market development and adapt early - not following after it is already too late or looking at outdated statistics or trying to influence buyers decision by forcing them to do what mass-market of such people does (because each of them is influenced with exact same approach recursively). You buy, because everybody buys, because such as yourself buys - so you have no choice but to follow. This is very very dirty society, it stinks with monopolies, I dont invest money there; I have my own head.

[crazycheese]

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.

Wow, wow, I have rather same yet different experience.
My experience was that fglrx crashed already when switching tty1's and opensource did 1-5 fps.
In a year, opensource went up to 40-50 fps (out of 300 possible); talking about raw performance here, not percieved or "enough for you anyway".

But, you know, investing 3-4 days in research, hunting specific GPU, overpaying for rare card of outdated generation - because opensource driver was developed from tail and could not support newer, cheaper, more efficient hardware - that was already a warning sign...

I wouldn't say intel graphic solution is miserable crap. Newest stack, complete usage of underlying hardware, performance on level of 8800-9800gt with proprietary drivers. Opensource that I've been waiting from AMD come from different company ... yeah...

[bridgman]

John, guys, I understand your approach, but it is not my approach. If you have certain approach, then you apply whole different method and same method can be seen as least efficient and most efficient depending on view only.

I actually think what's going on is a mixup between "what we did to catch up" and "what we are doing now". I agree completely that this is not necessarily obvious since Alex did a lot of work helping the transition to KMS and that *did* involve working on older hardware, but if you think of KMS as the exception rather than the rule this will all make a lot more sense.

That said, you develop legacy, tail, hardware and slowly approach the "head of the fish". But your company sells the "head of the fish", and that head is supported only via proprietary.

That only applied while we are catching up. We came fairly close to catching up in time for SI and would have if the delta between NI/SI had been comparable to the delta between previous generations, and expect to be substantially caught up by the next generation. Most of our focus now is on new hardware, although as we learn things we often go back and apply fixes to older hardware at the same time.

So hence your approach prioritizes following strategy:
1) you depend on proprietary, you cannot remove it - your selling of "head"s will stop - and hence support of whole drivers stops
2) your proprietary will stay more advanced than opensource, forever; see 1.
3) you will throw huge HR into segment that does not touch opensource at all, and is largely uninteresting for non-enterprise high volume consumers/retailers
4) you will never accomplish to utilize complex architectures seen on top models efficiently in opensource; because you simply lack human resources - which are gained only and only from selling of those cards
5) this means you are not interested in selling your cards to be used by opensource solutions

I don't understand #1 - are you just saying that work on the proprietary driver uses resources which could help the open source driver ? If so then I agree, but again please note that those resources would not be enough to let the open source driver meet the market needs which the proprietary driver satisfies.

Re: #2, yes but the only way to prevent it would be to get rid of the proprietary driver so that there would be nothing to compare with.

re: #3, yes but then we would need to walk away from a very important market which *nobody* supports with open drivers.

re: #4, maybe (although one could argue that it's optimization work rather than underlying architecture that makes the difference) but funding the implementation of complex architectures / optimizations requires sales from the entire PC market, not just the Linux portion -- being able to share code and investment across the entire market is the main reason that proprietary drivers even exist.

re: #5, I don't agree with your conclusion. If you said something more like "we are not willing to walk away from the workstation market even if doing so would allow us to offer an attractive open source solution more quickly" then there might be some truth to that. However, you need to remember that it was *never* our plan to write the drivers exclusively ourselves. If you get a chance please re-read the comments we made back in 2007.

This goes completely different with intel. Intel prioritizes development on "head of the fish", and only then, if ever, tail. This gives exact the situation their legacy hardware is non-usable under linux, but they have fast pace open development with top-notch current hardware. I want to buy newest hardware and use it with opensource - this is why intels approach is better for me.

Not different at all -- that's what we are doing as well and have been for a while, although note that the developers funded by embedded are working on the areas considered most important for the embedded market, which typically includes "recent" chips as well as "newest".

[Kano]

Dont you think that oss drivers are bit pointless when they do not provide h264 / vc1 accelleration? It does not matter much if via vdpau or vaapi, but it should be there.

[bridgman]

Dont you think that oss drivers are bit pointless when they do not provide h264 / vc1 accelleration? It does not matter much if via vdpau or vaapi, but it should be there.

No, although it would be a nice addition.

[bug77]

Dont you think that oss drivers are bit pointless when they do not provide h264 / vc1 accelleration? It does not matter much if via vdpau or vaapi, but it should be there.

I can understand nvidia's stance: oss drivers are just like a bootstrap until you can install proper drivers. But ATI's approach is not so clear cut. They support people willing to bang their heads against the walls writing drivers that will never catch up with Catalyst anyway. To what end, I don't know...

[bridgman]

Some of our customers wanted open source drivers; others want the performance and features that can only come from proprietary drivers, so we are doing both.

The only surprise was that the open source drivers turned out to be more attractive to embedded customers than we first expected, partly for ease of porting to other OSes/CPUs and partly because of the ability to support *extremely* long product lifetimes.

[Qaridarium]

Do you remember the GREEN monster is Nvidia trying to Monopole the Graphic card market.

[BlackStar]

- 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

Thanks, but the bug is already reported and confirmed in the Intel Q&A thread. It's in the bugtracker since the initial driver release in 2011 and it's still here a year later.

It typically manifests as constant tearing in the top ~100 pixels of the desktop and affects all compositors (tested with Mutter, Kwin and Compiz 0.8 and 0.9). The only workaround is to force full screen redraws (there's an option in Compiz 0.9 and an environment variable in Mutter), suffering the corresponding increase in CPU/GPU load.

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

URT = Unreal Tournament or Urban Terror?

- I wouldnt take powervr/g500 chips as intel chips, very probably they outsourced and powervr refuses to release specs.

It doesn't matter where the GPU comes from - Intel uses the chip in its CPU, so it's their responsibility to support it. They failed utterly with Poulsbo and they have also failed with the new Cedar Trail.

The sad fact is that people will buy the new Atoms and will flood the forums with posts "Linux doesn't work, it sucks", just like they did with Poulsbo.

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

No, you didn't understand. I am talking about the new 64-bit Cedar Trail Atoms that will not have 64-bit drivers. The web is buzzing with the news, e.g. vr-zone: "Intel has decided not to develop any 64-bit drivers, nor will there be any DirectX 10.1 drivers".

Besides, you are mistaken. Atoms have supported amd64 since 2008 (the "Diamondville" variant).

[Qaridarium]

The only surprise was that the open source drivers turned out to be more attractive to embedded customers than we first expected, partly for ease of porting to other OSes/CPUs and partly because of the ability to support *extremely* long product lifetimes.

I like this part *Happy* YES!

for general you can translate "Open-Source" with: "*extremely* long product lifetime"