Mesa 10.2 Features Are Quite Exciting

[Gusar]

As far as I know SandyBridge GPU supports OpenGL up to 3.1 only..

Sandy Bridge can very much do OpenGL 3.3, but someone needs to write support for geometry shaders. Someone not Intel, they've moved on to newer hardware already. Your link shows what's supported by the Windows driver, not what the hardware is capable of.

[rikkinho]

hm

Sandy Bridge can very much do OpenGL 3.3, but someone needs to write support for geometry shaders. Someone not Intel, they've moved on to newer hardware already. Your link shows what's supported by the Windows driver, not what the hardware is capable of.

it will not happen without intel support

[dungeon]

Isn't that vce firmware naming which trying to load in 3.15 kernel also confusing to anyone else ? When i first saw it, i am thinking... why this bloody bonaire wants to load on kabini .

It is named BONAIRE_vce.bin , but seems like trying to load for all Temash, Kabini, Kaveri, Bonaire and Hawaii hardware . I think that deserves better naming like UNIVERSAL_vc2.bin or something like that .

[uid313]

Obligatory reference

Since Michael is a poor "journalist" who never cites his sources.

http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt

[gufide]

As far as I know SandyBridge GPU supports OpenGL up to 3.1 only..

The only thing missing for 3.3 compilance is the geometry shader, and reading the mailing list it was possible to implements, but a little harder than the others

source: http://lists.freedesktop.org/archive...er/046150.html

[Ericg]

Isn't that vce firmware naming which trying to load in 3.15 kernel also confusing to anyone else ? When i first saw it, i am thinking... why this bloody bonaire wants to load on kabini .

It is named BONAIRE_vce.bin , but seems like trying to load for all Temash, Kabini, Kaveri, Bonaire and Hawaii hardware . I think that deserves better naming like UNIVERSAL_vc2.bin or something like that .

All naming schemes are done based upon the first chip they supported, and continue up until a break happens. Hence the reason why "RadeonSI" --> "Radeon Southern Islands" will be used for all cards until they break the architecture enough to have to start from scratch.

[DanL]

Since Michael is a poor "journalist" who never cites his sources.
http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt

Fsck off with your "not a professional journalist" meme.
The document you link to has already seen commits past the 10.2 branch, so it's not accurate just to link to it when talking about Mesa 10.2....

[dungeon]

All naming schemes are done based upon the first chip they supported, and continue up until a break happens. Hence the reason why "RadeonSI" --> "Radeon Southern Islands" will be used for all cards until they break the architecture enough to have to start from scratch.

In r200 i know i need one firmware and that is it, but today radeon driver load much more firmwares... As of kernel 3.15 there are 8 available for one Kabini hardware, 6 of those blobs is named as Kabini and 2 named Bonaire for Kabini and others .

What i thinking is exponentialy in 2025. we will need to load 64 firmwares per chip , so one must establish clear naming today .

[dungeon]

If i count that right, BONAIRE/HAWAII needs even more that is 10 or 11 fw blobs . Why they not bundle that in one?

[droste]

If i count that right, BONAIRE/HAWAII needs even more that is 10 or 11 fw blobs . Why they not bundle that in one?

Space requirements? If they only need to replace one part/less parts for a new generation you save a lot of space. Additionally if you don't need a specific feature (for example UVD) you can leave that blob out.
Also I'm not even sure why you care. I'm pretty sure you're doing what pretty much everyone else is doing and just install all to your system and let the driver handle which one are needed.