Mesa 10.2 Features Are Quite Exciting

[tarceri]

it will not happen without intel support

There were some wip sandy brigde geom shaders patches posted to the Mesa dev mailing list a while back so I wouldn't be so sure about that.

[Calinou]

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

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

He already defined himself as a non-journalist, so he's unaffected by journalist policies.

[Spittie]

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

http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt?h=10.2

[chithanh]

I'm confused about Openmax. What was wrong with vaapi / vdpau to warrant a replacement?

Deathsimple and agd5f wrote here and here why VAAPI was deemed unsuitable.

VDPAU is used for decoding, OpenMAX for encoding right now.

OpenMAX is used for both encoding (on supported chips) and decoding.

Personally seeing increased OpenMAX adoption would make me happy, but thats a chicken-egg problem since not many applications support it.

I think that of the three APIs, OpenMAX is the most widely adopted one, predominantly in Android devices but also in other embedded systems like the Raspberry Pi. Then VAAPI (remember, Intel is the largest PC graphics manufacturer) and then VDPAU.

Only when it comes to software support on the desktop, it is true that VDPAU offers the greatest variety of options at this time.

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 .

You can just read the Gentoo Wiki, all firmware files are listed there.

[Ansla]

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.

You can't just install them all and let the driver handle it if the driver is built into the kernel. Then all required firmware must also be built into the kernel. And for that you have to specify each one by name.

I guess a "late init" feature could be implemented so that when built into the kernel to only initialize the framebuffer at boot and init the rest the first time drm/uvd/vce is accessed. And hopefully by that time root would be mounted and the firmware can be loaded just like in the case it was built as a module.

[droste]

You can't just install them all and let the driver handle it if the driver is built into the kernel. Then all required firmware must also be built into the kernel.

Easy: don't build it into the kernel :-P
And I'm kinda serious here, why would you build it into the kernel? Where's the advantage?

[edoantonioco]

There's none.

So that means that's all the performance than can be obtained from r600? I just need a bit more to run some games with decent fps :/ (I even have hiperz activated). But I recognize than the improvements already obtained are great.

[smitty3268]

So that means that's all the performance than can be obtained from r600? I just need a bit more to run some games with decent fps :/ (I even have hiperz activated). But I recognize than the improvements already obtained are great.

There are a few more possible improvements, like HiS, that haven't been done yet. I don't think anyone is currently working on them, though. AMD has more important tasks, like fixing PM, and getting Hawaii cards to run, and enabling GL4, than eeking out 5% more performance on cards that already run pretty well.

You're welcome to contribute, though, or find other contributors.

[zanny]

So that means that's all the performance than can be obtained from r600? I just need a bit more to run some games with decent fps :/ (I even have hiperz activated). But I recognize than the improvements already obtained are great.

There is room for deep optimizations on a lot of the gallium drivers - from the Mesa routine implementations, the win_sys backend optimization, memory allocation, bus bandwidth limiting, shader compiler optimizations, and hardware features the above (and more, I probably don't know all of them) that could still be done.

Like what has been stated, though, performance is taking a back seat right now to product support and GL compliance. Hopefully when we catch up in two years (probably just in time for OGL 5.0) then some time can be spent on performance optimizations. But then, the AMD payroll devs will probably only be optimizing radeonSI.

[Ansla]

Easy: don't build it into the kernel :-P
And I'm kinda serious here, why would you build it into the kernel? Where's the advantage?

• Having graphics initialized as early as possible so that most build problems can be diagnosed without a serial console
• Allows you to disable module support (if all other drivers are also built in)
• Seeing the flock of penguins in upper left corner of the screen until userspace takes over