Intel Wants YOUR Linux Questions, Feedback

[RussianNeuroMancer]

It is possible to add support of Hi10P video decoding on Intel GPU's to libva?

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.

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?

[snadrus]

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:
- OpenCL
- 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.)
- VaAPIs
- 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,
Andy Jackson

Google WebGL maps appears to ban your drivers as unstable. That should be looked into.

[ejmarkow]

I have the following from dmesg:

$ dmesg | grep -i drm
[drm] Initialized drm 1.1.0 20060810
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm:intel_framebuffer_init] *ERROR* unsupported pixel format
fbcon: inteldrmfb (fb0) is primary device
fb0: inteldrmfb frame buffer device
drm: registered panic notifier
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
[drm:intel_framebuffer_init] *ERROR* unsupported pixel format


My system specs:

Distribution: Arch Linux

glxinfo:
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset
OpenGL version string: 2.1 Mesa 7.11.2
OpenGL shading language version string: 1.20

xf86-video-fbdev 0.4.2-5 (xorg-drivers xorg) [installed]
xf86-video-intel 2.17.0-2 (xorg-drivers xorg) [installed]
xorg-server 1.11.3-1 (xorg) [installed]
xorg-server-common 1.11.3-1 [installed]
xorg-server-utils 7.6-2 [installed]

$ ./ver_linux
Linux Galicja 3.3.0-pre-rc-release-git-0994695-ARCHMOD #1 PREEMPT Fri Jan 13 09:58:56 CET 2012 x86_64 Genuine Intel(R) CPU 575 @ 2.00GHz GenuineIntel GNU/Linux

Gnu C 4.6.2
Gnu make 3.82
binutils 2.22.0.20111227
util-linux 2.20.1
mount support
module-init-tools 3.16
e2fsprogs 1.41.14
jfsutils 1.1.15
reiserfsprogs 3.6.21
xfsprogs 3.1.7
pcmciautils 018
PPP 2.4.5
Linux C Library 2.15
Dynamic linker (ldd) 2.15
Linux C++ Library 6.0.16
Procps 3.2.8
Net-tools 1.60
Kbd 1.15.3
Sh-utils 8.14
wireless-tools 29
Modules Loaded ipv6 ipt_MASQUERADE iptable_nat nf_nat ipt_REJECT ipt_LOG xt_limit xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter xt_HL iptable_mangle ip_tables x_tables ntfs joydev arc4 snd_hda_codec_hdmi snd_hda_codec_conexant coretemp fuse snd_hda_intel snd_hda_codec snd_usb_audio snd_hwdep hp_wmi ath5k uvcvideo ath snd_pcm videodev snd_usbmidi_lib mac80211 snd_timer sparse_keymap snd_rawmidi snd_seq_device media wmi snd evdev v4l2_compat_ioctl32 psmouse asix usbnet r8169 mii soundcore iTCO_wdt i2c_i801 cfg80211 serio_raw pcspkr iTCO_vendor_support rfkill thermal snd_page_alloc battery ac processor i915 drm_kms_helper drm i2c_algo_bit button i2c_core video intel_agp intel_gtt rtc_cmos ext4 mbcache jbd2 crc16 sr_mod sd_mod cdrom uhci_hcd ahci libahci libata ehci_hcd scsi_mod usbcore usb_common

[blaze33]

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.

So.... questions:
- 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!

[Kano]

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

[combuster]

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

All I can say is - great work ppl...

[rusty]

Will we see a proper kernel support for core i7 920 and above ?

new kernels (starting from 2.6.36 I belive) panic when overclocking core i7 9xx.
also these 2.6.36 and above kernes don't show the multiplier i.e. cat /proc/cpuinfo

I have recompiled a kernel with different setting and can provide a working kernel config for i7 920 if needed.
However, my kernel still doesn't show the multiplier, it recognizes the overclocking.

Thanks

Can you please answer this ?

[Kano]

Did you try to disable EIST in the bios?

[rusty]

eist is disabled as well as other things like c1 etc..

running at 4.3ghz - 207x21 multi.

[stqn]

A recent phoronix article showed some performance regressions on Core i something over the past year. Why did these regressions happen?
Thanks.