It is possible to add support of Hi10P video decoding on Intel GPU's to libva?
Originally Posted by eugeni_dodonov
Yes, I understand, this is sad. But unfortunately, the resources required to maintain and develop such old components are pretty high. So we cannot dedicate as much efforts towards those drivers as they'd need unfortunately.
This is the same situation which older GPUs are coming through right now, with DRI1 removal from Mesa. If you need to work with such old hardware, you can use one of the older releases, where things were tested and verified. With latest versions, not much verifications and stabilization for such components take place, so yes, sometimes they simple are not expected to work at all.
May you keep SB and IV hardware as long as possible? I think SB and IB customers doesn't want to hear something like that about their hardware in 2020.
Originally Posted by eugeni_dodonov
That's sad, but that's one of the disadvantages of the open-source model. Stuff gets supported and developed as long as someone is interested in that.
Simply it's mean Intel doesn't intrested in support of customers (both of home and corp. market) of Intel hardware, right?
It's been requested before, but so many of the other feature requests could be satisfied by moving to a Gallium architecture. You'd get:
- an easier start for switching between discrete & integrated graphics cards
- DirectX compatibility
- Bug fixes from other Gallium devs (yes, competitors. Help goes both ways there.)
- more casual contributors because of a more nimble architecture
- Even better community acceptance (though you're at the top of the list already)
Please consider it. Thanks,
Google WebGL maps appears to ban your drivers as unstable. That should be looked into.
No easy way to get the latest stable release of the graphics package under Ubuntu :
I clearly understand that providing a git repository along with several release tarballs looks just fine for some (most?) of the phoronix audience. However, ease of use matters as much as hw support, stability and performance to the end-user. As you're telling us : Compiling and/or upgrading graphics drivers in Linux is a complex and error-prone task.
So what about getting "precompiled packages from one of the many Linux distributions"?
Here's the situation for Ubuntu (can't talk for other distros as I do not currently use them):
latest (unstable) upstream driver components:
We rely on xorg-edgers ppa. This is well maintained with almost daily updates. As far as it's recommended to upstream developers it ain't a good solution for end users: clearly not so stable with frequent regressions and also not so easy to have daily updates.
latest (stable) release:
Only working thing for an end user: updating the kernel with the Ubuntu kernel ppa binaries. That's only one of the six item of Intel 2011Q4 graphics package.
As for the rest, well, there is no up-to-date "official" ppa. Ubuntu X update should be it but clearly doesn't ship any intel stable release. So we're left with compiling the sources defeating the very purpose of having stable release for ordinary users. (or am i missing something?)
Clearly, closed source drivers have to release binary blobs (cf. amd/nvidia) and that's more or less easy for everyone to upgrade. On the other hand, I'm not sure we should stop at "hey, it's open-source, so here's the source" situation. I'm not here to say it's up to Intel or Canonical or the community to endorse the responsabilty. Just to expose the the facts: clearly, I've an Ubuntu 11.10 with every proposed and backported updates and without hacking my system I still get a 3.0 kernel, 2.15 xserver-xorg-video-intel, 1.10.4 xserver, etc. Those are respectively 6, 5 and 5 months old, I'm sure we could do better. Latest stable releases are 3.2, 2.17 and 1.11.3.
As the owner of 2 sandy bridge computers, I wasn't so happy during the first half of 2011. Frequent stable updates may not be so important for older hardware but for sandy bridge that would have saved me a lot of time and trouble.
- What kind of cooperation do you have with Ubuntu (and other distros as well) if any at all?
- Are there any plans to improve the situation relative to the availability of stable releases precompiled packages (ordinary user point of view)?
Unrelated to the above:
- Are you able to reuse much work of the windows driver team ? It looks like a real challenge to ever have an on-par linux driver whith a 500 ppl team for one MS OS vs. a 30 ppl-team for many Linux-distros and I would be afraid to see it as a never-ending race. And is it just a matter of manpower or does the open-source strategy complicate this ?
And for the sake of arguing: it's nice to see how Ivy Bridge is well supported but hey ! No one still bought it and I'd like to use google-earth without hard freezing my computer!!!
I really hope you'll be be able to go trough every comments and make something useful out of this in the end
As for those who where talking about "stop complaining and vote with your wallet", I'll answer this is the ever same bullshit justifying any vendor-lock-in strategies for the sole reason that most ppl will just buy and use what they're told to. Not to mention that the many won't have any interest in knowing how things work, how they're done (out of curiosity, time, knowledge, etc. but doesn't matter); unfortunately this still greatly impacts what you get in the end. For God's sake, we have political institutions to express the people best interest in a powerful way, if I stop buying laptops because no one sells them without windows, i'm just screwed, no one ever listened to me (BTW very happy that Dell gave me a refund for windows7 ).
The same goes for hardware vendors, looks like selling hw with binary-only undocumented drivers is like selling you something while saying you: you'll never know how to use it unless you use this version of that software under my terms mainly because I own the knowledge of how to use it (ya know, i built this piece of hw), but don't want to share it with you even if i'm selling it to you). That should just be forbidden. Plain and simple. I don't care if i don't know how it internally works, what industry secrets you want to keep, just make sure you do it in a way to expose each and every possible use in an accessible and documented way. You can't just kill innovation because of poorly thought work, technical, legal standard procedures...
And even if I would never read and implement technical specs, they should just be available for those who want to do it because that's how it works.
Glad to know Intel wants to hear what they customers have to say Many thanks Mr. Dodonov!
I do not fully get your gallium -> vaapi part, wasnt it vdpau that was developed for radeon via gallium? I do not consider that implementation so usefull, it is more generic, but does certainly not use the hardware video accelleration parts like intel already does. You just need to use a "tested" graphics stack to take full advantage of it. In case it does not crash/hang the app it is maybe the 2nd best solution. The tearing issue needs to be resolved and stability could be certainly improved, but hopefully until wheezy freeze this is fixed. Until then my main box will still have got a passive nv card - not because of video acc - any i7 could decode everything by software only as well, but because of tearing, thats what i absolutely dislike. The same problem had ati as well when they removed hardware overlay support, until that time i even used a 9700 to watch movies, but after that it was impossible. Its good to have two systems to use the right one for movies
Funny enough I haven't had problems with my intel graphics driver since SNA was introduced for the first time. All this stuff about rc6 and semaphores seems to avoid me - while others had problems I've explicitly enabled semaphores after the first patch was submitted (even poked around the source code to override disabling semaphores if my chipset is recognized) and all worked out well for me. To tell you the truth I have been bored for a couple of releases of xf86-video-intel and kernel (even rc1's are working flawlessly - and that's an outrage ).