Re: [blfs-dev] Heads-up: new intel video driver, needs testing
On Fri, Jan 03, 2020 at 12:58:22AM +0800, Xi Ruoyao via blfs-dev wrote: > On 2020-01-02 00:26 +, Ken Moffat via blfs-dev wrote: > > I have a new Core i7-1065G7 laptop. The legacy libva-intel-driver just > doesn't > work on Gen 11 graphic so I tried the new iHD driver. > > Gstreamer refuses to use iHD driver with libva (by default it only utilizes > libva-intel-driver). I tried to force Gstreamer to use iHD. It works with > "gst-play-1.0" but breaks video replay in WebKitGTK (I tried 1080p videos on > YouTube and Bilibili). So finally I had to build intel-media-sdk and gst-msdk > plugin (in gst-plugins-bad) to use the Gen 11 iGPU to accelerate video replay. > Useful to know, as with everything to do with media encoding/decoding the situation seems to be complex. > My kernels (one from Arch and one built by myself) don't try to load GuC/HuC > firmwares. /sys/kernel/debug says my iGPU doesn't need HuC, and GuC is > disabled. > OK, thanks for that. Looking a bit more deeply at what I regard as a very hard to follow set of documentation (like some others, it's probably fine if you already understand all the details) I see that HuC is only needed for Hardware Encoding, Low Power Encoding(VDEnc/Huc) on Skylake and later, but only for limited AVC and jpeg on most existing platforms. https://github.com/intel/media-driver/blob/master/docs/media_features.md#supported-video-processing-cscscaling-format ĸen -- The right of the people to keep and arm Bears, shall not be infringed. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] RFC: remove '..' in our meson commands
On Fri, Jan 03, 2020 at 01:03:28AM +0800, Xi Ruoyao via blfs-dev wrote: > On 2020-01-01 00:14 +, Ken Moffat via blfs-dev wrote: > > On Wed, Jan 01, 2020 at 03:20:33AM +0800, Xi Ruoyao via blfs-dev wrote: > > > > > > Any thoughts? > > > > While I'm still maybe sober - I've seen both. The scattering of > > files around .. is certainly painful to clear up, and the exit if > > not in a build directory is useful. > > I just done it again :(. > > > But I see Bruce prefers to be explicit. Dunno about that, in > > ./configure scripts we usually ignore options which are the defaults > > (compare various builds in AUR and gentoo). > > Well we are already relying on the implicit behaviors a lot. > For example, "--buildtype=debugoptimized" (I almost always override it > with "--buildtype=release"). Me too. ĸen -- The right of the people to keep and arm Bears, shall not be infringed. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] many docdir have no version number
Hi, I just tried a `ls /usr/share/doc | grep -v "\-[0-9]"`. It turns out many directory names w/o a version number. Most of these names are from Xorg libraries and applications, for example libX11. The remaining ones are (on my system): brotli gnome-session libnotify librsvg systemd We should spend some time to fix them. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Heads-up: new intel video driver, needs testing
On 2020-01-02 00:26 +, Ken Moffat via blfs-dev wrote: > Apologies for breaking the thread, I thought I had _copied_ > Pierre's mail to my notes, and then I edited my note on microcode > to include the TLAs for Broadwell etc so that I could understand the > intel release notes next time, and deleted the copy. But what I'd > actually done was Save the mail, so I'm now posting the original > from the archive. Sorry about that, blame it on too much > williewaught [1.] > > And thanks for finding these explanations of the TLAs. > > Pierre wrote: > > > Hi, > > > > While investigating the bug in libva-2.6.0, I realized that there was a new > > vaapi driver for intel GEN8+ graphics: iHD_drv_video.so > > > > The source is at https://github.com/intel/media-driver. > > > > If anybody with the appropriate hardware wants to try... > > Personally, I am at 4th gen intel (Haswell), so I cannot test. > > Note that it also requires the gmmlib graphics memory management library: > > https://github.com/intel/gmmlib. > > > > Note that libva-2.6.0 has a bug (https://github.com/intel/libva/issues/355) > > which prevents using the i965 driver if the iHD driver is also installed. I > > have provided a patch to fix this issue > > (https://github.com/intel/libva/issues/356), but I cannot test for lack of > > hardware! So if anybody has a recent intel CPU ( > > BDW (Broadwell) > > SKL (Skylake) > > BXT (Broxton) / APL (Apollo Lake) > > KBLx (KBL/Kaby Lake; CFL/Coffe Lake; WHL/Whiskey Lake; CML/Comet Lake; > > AML/Amber Lake) > > ICL (Ice Lake) > > JSL (Jasper Lake)/EHL (Elkhart Lake) > > TGL (Tiger Lake) > > ) > > please try it, thanks I have a new Core i7-1065G7 laptop. The legacy libva-intel-driver just doesn't work on Gen 11 graphic so I tried the new iHD driver. Gstreamer refuses to use iHD driver with libva (by default it only utilizes libva-intel-driver). I tried to force Gstreamer to use iHD. It works with "gst-play-1.0" but breaks video replay in WebKitGTK (I tried 1080p videos on YouTube and Bilibili). So finally I had to build intel-media-sdk and gst-msdk plugin (in gst-plugins-bad) to use the Gen 11 iGPU to accelerate video replay. > I _do_ have a low-end skylake (i3 6100), but I don't think I'll have > time to look at this in January, and probably not in February. But > nevertheless, some comments. > > First, GEN8+ is not the same as 8nnn CPUs (Kaby Lake etc). > Broadwell is 5nnn, Skylake are 6nnn (or 7nnn for some, but maybe > those lack integrated graphics). I think it means the 8th and later > generations of intel integrated graphics. > > Oddly, the link to the media-driver looks correct, but 404s when I > click on it from the archive. But looking at the README there are > two types of build: Full Feature and Free Kernel. I don't grok the > explanation of the differences, but I see that Arch have a build > which looks straightforward, ditto intel-gmmlib. > > Importantly, HuC firmware is needed for several of the encoders, > this is currently disabled by default in released kernels (I believe > there is an attempt to get it enabled by default in 5.5 or perhaps > 5.6). The kernel docs apparently explain how to enable it on > current kernels, but I would be very wary of doing that until it > arrives in a released kernel, because there have been so many > problems. Back in July phoronix reported it would be loaded by > default in IceLake (Gen 11). In particular, > https://wiki.archlinux.org/index.php/Intel_graphics#Enable_GuC_/_HuC_firmware_loading > says that loading GuC/HuC firmware can cause freezing, e.g. when > resuming from hibernation. But the bottom of that page says it is > out of date: Reason: GuC submission has been completely disabled in > the kernel, due to it reducing performance and causing bugs. Setting > enable_guc=3 has no effect. > > Yes, that is GuC not HuC, but it doesn't give me a lot of > confidence. Once a release kernel enables HuC on 5nnn and 6nnn CPUs > with integrated graphics, things ought to be fine. But meanwhile, I > would class it as "here might be dragons". > > Hmm, found the phoronix article I was thinking of, > https://www.phoronix.com/scan.php?page=news_item&px=Intel-GuC-HuC-Auto-Enable-Again > With a link to the patch. On this AMD machine I've got kernel 5.4.5 > source, the patch has NOT been applied there: > > > diff --git a/drivers/gpu/drm/i915/i915_params.h > > > b/drivers/gpu/drm/i915/i915_params.h > > > index d29ade3b7de6..5736c55694fe 100644 > > > --- a/drivers/gpu/drm/i915/i915_params.h > > > +++ b/drivers/gpu/drm/i915/i915_params.h > > > @@ -54,7 +54,7 @@ struct drm_printer; > > > param(int, disable_power_well, -1) \ > > > param(int, enable_ips, 1) \ > > > param(int, invert_brightness, 0) \ > > > - param(int, enable_guc, 0) \ > > > + param(int, enable_guc, -1) \ > > > param(int, guc_log_level, -1) \ > > > param(char *, guc_firmware_path, NULL) \ > > > pa
Re: [blfs-dev] RFC: remove '..' in our meson commands
On 2020-01-01 00:14 +, Ken Moffat via blfs-dev wrote: > On Wed, Jan 01, 2020 at 03:20:33AM +0800, Xi Ruoyao via blfs-dev wrote: > > Hi: > > > > Now most of our meson commands contains a '..' but a few does not. Maybe we > > should remove all '..' in meson commands. Reasons: > > > > (1) '..' is unnecessary in meson command, with "mkdir build; cd build". > > (2) Sometimes we forgot to "mkdir build; cd build" and type the meson > > command > > in the source code directory, mistakenly. With a '..' meson will believe > > '..' > > is the building directory and produce build.ninja and many other files in > > '..'. > > It's hard to clean them because BLFS source code directory (/usr/src or > > $HOME/src) contains lots of tarballs. However, without '..' if we forgot to > > type "mkdir build; cd build" meson would complain and exit, instead of > > producing > > the files. > > > > Any thoughts? > > While I'm still maybe sober - I've seen both. The scattering of > files around .. is certainly painful to clear up, and the exit if > not in a build directory is useful. I just done it again :(. > But I see Bruce prefers to be explicit. Dunno about that, in > ./configure scripts we usually ignore options which are the defaults > (compare various builds in AUR and gentoo). Well we are already relying on the implicit behaviors a lot. For example, "--buildtype=debugoptimized" (I almost always override it with "--buildtype=release"). -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
