Tag Archives: Intel

Intel Valleyview & Cherry Trail Hardware Likely To See Fastboot Flipped On


With the upcoming Linux 5.1 cycle we’ll likely see Intel “Fastboot” enabled by default at least for Skylake hardware and newer, but Cherry Trail and Valleyview might also get this special treatment.

Fastboot in the Intel Linux perspective is about avoiding unnecessary mode-sets at boot time in order to provide a cleaner boot experience, or as some put it so elegantly, “avoid an ugly modeset during boot.” Fastboot has been a long time coming after several failed attempts over the years to enable it by default. But with the current mature state of the Intel DRM/KMS driver and recent generations playing well with Fastboot, it’s reasonable to enable it by default.

Hans de Goede of Red Hat has been pursuing the Intel Fastboot by default as part of his broad effort on improving Fedora’s boot experience. With Skylake and newer squared away, he’s been exploring what other generations of Intel hardware may be safe to flip this feature on by default rather than requiring the i915.fastboot=1 boot parameter.

In his latest testing, he thinks Cherry Trail and Valleyview/Bay-Trail Atom hardware is a safe bet:

I’ve extensively tested fastboot=1 support on over 50 different Bay- and Cherry-Trail devices. Testing DSI and eDP panels as well as HDMI output (and even DP over Type-C on one device).

All 50 devices work fine with fastboot=1. On 2 devices their DSI panel turns black as soon as the i915 driver loads when fastboot=0, so having fastboot enabled is required for these 2 to work properly (for lack of a better fix).

So if this patch gets picked up, these generations of Intel SoC hardware will also see Fastboot by default.

Intel To Eventually Explore Offering A Graphics Control Panel For Linux Systems


Intel’s Linux graphics driver stack has never offered its own vendor-specific driver control panel GUI like is common among all major graphics vendors on Windows, but instead they’ve opted for the command-line experience and making use of common interfaces with what’s offered by the different desktop environments for resolution handling, multi-monitor setup, etc. But moving forward they may end up bringing a new graphics driver control panel to Linux.

With the exception of the NVIDIA proprietary Linux graphics driver that offers a GTK-based control panel interface with all meaningful controls in a GUI environment (besides also offering CLI access to the tunables too), the open-source Linux graphics drivers from the likes of Radeon, Intel, and Nouveau have relied upon the generic control panels shipped by the different desktop environments. The current round of Linux GUI settings panels are often limited to just the common RandR monitor controls / multi-monitor setup and other basic display settings, but far from what can be configured via the driver control panels on Windows.

The display settings offered currently on the GNOME desktop.

It’s not that Linux doesn’t already support those tunables, but in fact both Radeon and Intel drivers offer much of the same level of configuration just that it currently is only exposed via the command-line via sysfs/debugfs, kernel ioctls, etc, and not carried through into any feature-packaged GUI configuration area. For the AMD Radeon part, they discussed previously of porting their Qt-based Radeon Software user-interface to Linux, but in the end did not and leaving the GUI tasks up to Linux desktop environments.

The former Radeon “AMDCCCLE” driver control panel for Linux systems, no longer maintained/working.

With the Intel graphics scene getting more exciting with Icelake Gen11 graphics out later this year and the first of their discrete “Xe” graphics expected in 2020, they may end up offering a GUI driver panel for Linux.

The current NVIDIA Linux graphics driver control panel, the most feature-rich choice at the moment.

The Intel Graphics team has been teasing a new Windows control panel they are expected to announce soon, so I decided to ask about any Linux plans.

The answer came down basically as I would have expected: “The first release of the control panel, will not include Linux; however we hear you, and are exploring for future releases.

Right now Intel Linux graphics desktop users aren’t missing out on much since all necessary functionality is in place. But when it comes to discrete graphics and opening up for overclocking and advanced tweaking as many gamers are accustomed to doing on Windows, obviously it would make sense to offer a nice graphical user interface rather than hand-editing Mesa configuration files, writing values via sysfs, etc; we certainly know there is much interest in Linux on discrete Intel graphics.

Intel Sends Out First Batch Of Display/Graphics Driver Updates For Linux 5.1 Kernel


While the Linux 5.0 kernel won’t even debut as stable until around the end of February, as is standard practice, it’s open season for new feature improvements of the changes developers want to end up queuing into the “-next” branches ahead of the Linux 5.1 cycle. The Intel open-source driver developers on Monday sent in their initial batch of graphics driver changes for this next kernel cycle.

Rodrigo Vivi of the Intel Open-Source Technology Center sent in their initial Linux 5.1 Intel DRM driver material today to DRM-Next for its vetting until the Linux 5.1 merge window at the start of March.

The Icelake “Gen 11” graphics support for Linux appears to be squared away ahead of the new CPUs debuting later in the year. With this 5.1 pull request there are just a handful of Icelake “ICL” related patches mostly around the display handling and in particular for Type-C/Thunderbolt ports.

This initial 5.1 pull request is largely made up of low-level code clean-ups, random fixes, and some kernel documentation improvements. Some of the larger fixes/changes include better debugfs handling, removing hardware semaphores for Gen7 interl-engine sync, improvements around GPU resetting and hang reporting, some power management related tweaks, and other small items.

One sort of feature to mention is that frame-buffer compression (FBC) is now supported for 5K displays on Gen10 (Cannonlake) graphics and newer. But with Cannonlake graphics not materializing, that seems like it will really be a change for Icelake.

The complete list of these patches initially staged for Linux 5.1 by way of DRM-Next can be found via this pull request. Expect more changes in the weeks ahead while Linux 5.0 gets buttoned up.

Purism Announces New Laptops Based On 7th Gen Intel CPUs, 4K Option


While Purism remains very busy with their Librem 5 smartphone efforts, today they have announced their fourth version of the Librem 13/15 laptops.

With Version 4 of the Librem laptops, they have upgraded the Librem 13 and Librem 15 to Intel 7th Gen CPUs… Yes, 7th Gen from 2016. Granted, that’s done in order to retain Coreboot compatibility with their hardware, but a bit sad to see such dated processors used while the Librem 13 pricing starts off at the same $1399 and the Librem 15 at $1599. In particular, Purism is going with the i7-7500U which is dual-core plus Hyper Threading Kabylake in comparison to Intel’s newer Core i7 mobile parts being true quad-core processors plus Hyper Threading, among power efficiency improvements, etc.

The Intel CPUs on these new Purism laptops are at least an upgrade from before and still has Coreboot support. The other notable change with the new laptops is the Librem 15 having a screen upgrade option from 1080p to 4K. That’s very nice to have albeit pricey with the $1599 USD laptop having a 4K screen and Core i7 7500U processor with HD Graphics 620 but only 4GB of RAM (upgrades possible to 16GB) and a 120GB SSD.

Hopefully if Intel succeeds at open-sourcing the FSP will help Purism in being able to offer new laptop models with latest-generation processors.

More details on these new Linux laptop options via Purism.

Intel Looking To Add SYCL Programming Support To LLVM/Clang


SYCL, the single-source programming model developed by the Khronos Group and based upon standard C++, might soon be supported by the LLVM Clang compiler thanks to Intel.

Intel compiler engineer Alexey Bader sent out a public “request for comments” today on the idea of adding SYCL to the LLVM Clang compiler stack. He wrote, “We (Intel) would like to request to add SYCL programming model support to LLVM/Clang project to facilitate collaboration on C++ single-source heterogeneous programming for accelerators like GPU, FPGA, DSP, etc. from different hardware and software vendors.

This would be yet another major contribution by Intel to the LLVM/Clang infrastructure ranging from their major OpenMP commits in the past to contributing their Parallel STL implementation to libc++ and much more over the years.

While the Intel developers are soliciting feedback, they already have patches prepared for Clang that would introduce basic SYCL programming model support and they will be sending those out soon for review.

Presumably this effort is part of Intel’s planned oneAPI initiative that they announced back in December at the Intel Architecture Day event. Intel is pursuing a uniform software stack/API that would work across processors, their existing integrated GPUs, FPGAs, future Xe dedicated graphics hardware, and other accelerators. With SYCL they would have a C++-based single-source format that is already engineered by multiple vendors, continues to expand in regards to tooling/documentation/support, and would align with their goals.

With SYCL in Clang it would ultimately be possible for compiling and just running on the host CPU or offloading to various devices with LLVM back-ends. Theoretically once the SPIR-V back-end is finally in place, there would also be the options of spitting out the SYCL code to SPIR-V for then consumption by OpenCL/Vulkan drivers. Among the LLVM back-ends to point out now are obviously NVIDIA NVPTX, the AMDGPU LLVM back-end that is central to the open-source Radeon driver stack, and there is also (the currently out-of-tree) Intel LLVM graphics compiler that would be needed in order to target their graphics hardware for compute, among other LLVM back-ends that could potentially benefit.

2019 is certainly looking to be an interesting year for Intel on both the hardware and open-source software fronts.