Intel HD 4000 Ivy Bridge Graphics On Linux

[liam]

Impressive. CPU and GPU performance is great, Linux support awesome, and this should make really good cpu for laptops. Waiting for OpenCL and video acceleration support (VDPAU preferably ;D ). Intel Linux team is doing great job.

Best x86 processor ever, need to buy it quickly . Hope AMD will respond properly.

IVB should have vaapi acceleration, just like snb, except better.
I doubt we'll see openCL on linux for awhile since they can't leverage the gallium work, and would thus have to produce it from scratch on their own (which they could easily do, but I doubt it is a priority).

[t.s.]

AMD, TAKE NOTES: your competitors are doing much better than you with the stability and performance (or in some cases, mere existence) of open source driver support on release day of their products. The Intel drivers for Ivy Bridge are, as far as I'm concerned, a "grand slam home run". The NI-derived APU open drivers I would say are a "single" base-hit. The SI discrete / Trinity APU open drivers I would say are a "strike-out" or "ground into double play". If you are looking for an open source driver release schedule that is considered acceptable to "picky" customers (I would consider myself picky), all you have to do is emulate what Intel just did with Ivy Bridge. Anything more than that is just icing on the cake.

I wish they (AMD) read this.

[bridgman]

I wish they (AMD) read this.

I did read it but AFAIK it's kind of confusing. The corresponding AMD part (Trinity) also has pre-launch support.

SI is a different animal -- we've been pretty clear that the discrete GPU generation *after* SI would be the first with launch time support.

[eugeni_dodonov]

The only things I miss are OpenGL 3.0 (which only appears to be available for Sandy Bridge right now, at least on Fedora 17 Beta)

To have OpenGL 3.0, it is necessary to build Mesa with --enable-texture-float (to enable floating-point textures, which are not enabled by default due to non-clear patent situation), and also to have a Xserver which supports GLX_ARB_create_context extension (which is only available in master for now as far as I can say).

[t.s.]

I did read it but AFAIK it's kind of confusing. The corresponding AMD part (Trinity) also has pre-launch support.

SI is a different animal -- we've been pretty clear that the discrete GPU generation *after* SI would be the first with launch time support.

Glad to hear that. Yep, pre-launch support. But does it have stability/maturity/performance over intel driver? As others said, for now, intel driver still the best for out of the box experience. For me too. Just purchase Asus A43E, all intel. Installed arch + kde and the experience is.. just wow. Can play DoTA via Wine smoothly. Kinda surprised.

I really hope AMD can make their driver quality better, soon. Very soon.

[fuzz]

I just hope AMD doesn't have to increase their prices too much in order to get better driver support. That's why I still buy AMD: I can afford them.

[Kayden]

To have OpenGL 3.0, it is necessary to build Mesa with --enable-texture-float (to enable floating-point textures, which are not enabled by default due to non-clear patent situation), and also to have a Xserver which supports GLX_ARB_create_context extension (which is only available in master for now as far as I can say).

Technically you don't even need an X server with GLX_ARB_create_context. All you really need is to build Mesa with --enable-texture-float (which may be subject to patents).

[t.s.]

I just hope AMD doesn't have to increase their prices too much in order to get better driver support. That's why I still buy AMD: I can afford them.

Can 'afford' their performance on linux too?

[allquixotic]

I did read it but AFAIK it's kind of confusing. The corresponding AMD part (Trinity) also has pre-launch support.

SI is a different animal -- we've been pretty clear that the discrete GPU generation *after* SI would be the first with launch time support.

"Support" is a very relative term, as I'm sure you're aware. I think that is the point "t.s." is trying to make as well. I'm typing this on an Ivy Bridge machine on a processor/IGP that has been for sale in U.S. consumer distribution channels for about 1 week. I'm using Ubuntu 12.04 LTS with a completely stock (albeit updated from the Ubuntu stable updates repos) driver stack and kernel.

I have:

• Decent power saving features
• Full DisplayPort, HDMI and DVI support, with up to 3 monitors (tested a DVI, a DP and an HDMI, and all 3 are working simultaneously)
• OpenGL 2.1 performance that beats out the performance of r600g on Evergreen (HD5970), a card that's more than two years old and whose raw processing power is probably an order of magnitude greater than the Ivy Bridge IGP
• Hardware video decoding, which isn't supported at all on any AMD chips (although I'm aware of your efforts along these lines for AMD)
• Smooth-as-silk 2D acceleration
• No immediately-obvious bugs or performance problems after running 6 different OpenGL 2.1 applications, not including my compositing manager and anything within my browser that may use hardware acceleration features (Flash? Chrome/Firefox themselves?)

Again, I have to emphasize, this is week 1 of the hardware launch, and I didn't compile a single line of code from git. And I have more features and at least as good performance than a 2+ year old AMD discrete ASIC has (comparing open source drivers to open source drivers, not fglrx). The 7970 in my box is a paperweight for now.

Like I said, setting a goal for your team to achieve this (what I stated above in my bulleted list) for HD8000 is what would restore my faith in AMD's open source graphics initiative. Failing that, I will probably not purchase another AMD product going forward, nor will I evangelize for AMD to the many people who come to me asking for advice on computer upgrades. Just throwing that out there, take it for what you will.

[fuzz]

Can 'afford' their performance on linux too?

Considering I use Gentoo: Of course. And I'm not talking about just graphics here. An APU is not just a graphic card.