Slashdot Mirror

Seems someone in PR realized how bad this looked, as they've updated the license: https://01.org/mcu-path-licens...

Same AC here. On Linux, this is how you'd do that is below -- preface: I do not use X/X.org (last time was in 1995!), so please take some of what I say with a grain of salt. The version of Ubuntu you're using matters greatly too. Someone more familiar with Ubuntu as a workstation/desktop, please comment!

1. Try digging around for resources relating to X.org, as that's effectively what's driving all the GUI bits and interacting with the video driver. I think this is xorg.conf or xorg.conf.d/ and there may be a config file setting (warning: that file/directory will probably scare you). I don't think your WM (window manager) is relevant,

2. Research options described in Ubuntu's Community Support; pick one or several and post there,

3. Try to track down the authors (committers) of the associated video driver and ask them. I did the work for you as best as I could: the X.org driver is called xserver-xorg-video-intel (assuming that's the chip you're using). There's supposedly an alternate driver from Intel themselves here but I have no idea if using it would solve anything (I wouldn't recommend doing the latter on a whim; I prefer to use Ubuntu packages natively if at all possible),

4. Use Launchpad to file a ticket with Ubuntu directly. Also advise searching their system to see if someone else has asked the same thing (try looking for separate terms "tearing", "vsync", "v-sync", or "vblank").

I also own an Intel NUC, but it's a headless server box for building third-party MIPS and ARM router firmwares, so I don't use the GUI (I don't even have a monitor hooked up to it). Plus we might have different NUCs (their on-die GPUs certainly differ between models), and I'm running a fairly old Ubuntu (intentionally).

Sorry I couldn't be of more help, but the above steps is the road I would take if I had to deal with said issue.

The general infrastructure works.It was fixed years ago. The problem with Skylake was introduced when Intel hanged their graphics architecture.Intel Skylake GPUs needs a firmware blob. Intel needs to debug the firmware and the driver. More information here: https://01.org/linuxgraphics/intel-linux-graphics-firmwares and and https://www.phoronix.com/scan.php?page=news_item&px=Intel-SKL-BXT-Firmware-Blobs

https://01.org/linuxgraphics/i...

"No reverse engineering, decompilation, or disassembly of this software is permitted."

The binary blobs are themselves dangerous - driver software is typically running with very high security clearance, and you have absolutely NO idea what is going on inside those blobs.

Well, on thing that might not be going on inside those blobs is "running on the CPU". The Intel download page for the firmware says of the GuC firmware:

GuC is designed to perform graphics workload scheduling on the various graphics parallel engines. In this scheduling model, host software submits work through one of the 256 graphics doorbells and this invokes the scheduling operation on the appropriate graphics engine. Scheduling operations include determining which workload to run next, submitting a workload to a command streamer, pre-empting existing workloads running on an engine, monitoring progress and notifying host SW when work is done.

and of the DMC firmware:

DMC provides additional graphics low-power idle states. It provides capability to save and restore display registers across these low-power states independently from the OS/Kernel.

The first of those sounds as if it runs on the graphics processor - the host submits work to the GPU, and it schedules the work to be done. The latter of those sounds as if it might run on the graphics processor as well, saving and restoring the display registers from within the GPU.

So this might not be running in the driver at all; the driver might just be loading that firmware into the GPU.

1. Intel HD 6000 has been supported since 2014Q2 release, https://01.org/linuxgraphics/downloads/2014/2014q2-intel-graphics-stack-release. They didn't even do the Windows(tm) thing of installing the drivers from a driver disk or download after install. This complaint is the equivalent of installing Windows without installing the graphics drivers for your card and then complaining when the display looks horrible. Or, the could have done it the Linux(TM) way and installed a distro that included the drivers. 15.04 is in beta release.
2. Arch Linux is that way. It is a "just this side of roll your own distro". Those were not problems, those are things you do to get Arch up and running. Luckily their docs are awesome. There were a few issues on Ubuntu, but that was mainly because of all of his special requirements (3 OSes, sharing partitions, non-standard gui, etc). I think the screen tearing around docking and undocking from his docking station and the trackpad/trackpoint interaction were his only hardware issues.
3. The bug (527157) is extremely nitpicky. If the bug affects me, then it seems like a feature. I have 10 levels of brightness. Do I want 20?

While Intel may not officially support OpenCL on their GPUs under Linux, there is Beignet, the open source implementation: https://01.org/beignet

Beignet supports OpenCL 1.2 on Intel GPUs on Linux, and is developed largely by Intel people. It's separate from their proprietary Windows OpenCL, so it's not as mature and has none of the tool support, but in my limited experience it actually works fairly decently.

I don't see why your BeagleBone black example is systemd's fault. It has a convoluted way of managing network interfaces because it uses connman, a network-management daemon from Intel that is not part of systemd.

Encoding was added to the VAAPI interface, but was never supported by Intel hardware. There's not much sense implementing a protocol when there's no hardware to interface with. You may be looking for the Intel Media SDK [intel.com], which wasn't made publicly available until the middle of last year.

Intel says otherwise: Hardware encoding is supported with Intel HD 2000 and newer (Sandy Bridge)

That's not what he's saying and you know it. He's staying on the topic of this article which is Intel has provided open source h.264 encoding (VAAPI) for years while AMD is now releasing code. You could do a little research. As for ffmpeg, it doesn't support VAAPI but that is a choice of the ffmpeg developers not to include it; however, through the external libx264 library, you can get ffmpeg to encode h.264. This has nothing to do with Intel as they released the code. That's like complaining that it's the Khronos Group's fault if PowerVR decided not to support OpenCL on their new GPUs.

From the article - https://01.org/linuxgraphics/documentation/2013-intel-core-processor-family

As long as we have the actual engineers to write the code. In case of Intel, we are lucky to have the Intel Open Source Technology Center with heaps of professionals working on projects.

If this is in linux, this might have something to do with ACPI. The firmware has a table called the DSDT (Differentiated System Description Table) which basically tells the operating system how to turn integrated peripherals like network cards off and on when going to sleep or waking up.

One peculiarity of the DSDT is that the ACPI specification allows it to include different instructions to different operating systems, and this is a common source of problems in linux installs. Some manufacturers (Toshiba) deliberately sabotage non-Windows operating systems in their DSDTs. Others simply deliver DSDTs that are untested and potentially buggy in non-windows operating systems.

Anyhow, an OS can switch devices off an on itself using ACPI, so I think ACPI may trump BIOS settings. One way to test this is to boot with ACPI turned off. If this fixes the problem of the mic being available even when disabled in BIOS, then you have and ACPI/DSDT problem. If not, then it is a design flaw in the machine's design (e.g. turning the mic off in BIOS simply turns the gain to 0) and you wasted your time reading this post.

It's not hard to determine that. Even task manager will tell you total CPU cycles/IO cycles wasted on a per/process basis.

Not enough information.

When they started looking at reducing Linux's power usage it turned out that it wasn't running stuff in the background that was the problem - it was how you decided when to run in the background.

If a 100 tasks are all wakeing up on 100 different timers then the system will never get a chance to sleep, enter low power states and so on.

If those processes can be made to cooperate and start on, say, 10 different timers, then the system will spend more short times running at max power, and longer running at low power states.

The breakthroughs started with powertop.

Try here: https://01.org/android-ia/downloads

Hey all,

You can all download the latest builds here: https://01.org/android-ia/downloads.
Hope everyone likes it!

No, these drivers are never going to be fully Open Source at the same time they give access to all the hardware capabilities.

I think "never" is a bit too strong of a word, maybe if you're talking for the current cards, perhaps, but Intel has seemed to be able to provide open source Linux graphics drivers.

True, true, they don't make the same cards as the high end guys do, but it's closed minded to even think that disparate computing model w/ discrete GPUs is going to last forever.

IMO, I'd rather do everything in software rasterizer -- Pixel & Vertex shaders still don't give me the same sort of control I had doing everything CPU side... We use hardware for the speed, but it's just a crutch -- a band-aid -- have to write the whole GPU pipeline myself anyway except now it's shaders instead of CPU side code, and with the slow main RAM to GPU bottleneck in the way, it prevents all sorts of wonderful physics -- No, don't get me wrong, you can do awesome stuff on the GPU, I've written whole applications in there, majority of game state and all physics in the GPU with CPU side code just providing the raw data streaming and control input / networking, but it's still terribly limited and a PITA to code that way. Heterogeneous computing will let us do some really awesome stuff, but what we need is just tons of parallelism in the CPUs / FPUs and a fast frame buffer -- then it would be just like the good ol' days. It's coming. The line between GPU and CPU is blurring. And when that happens, You can kiss your "never" goodbye.

Hey, remember when the FPU wasn't always just a given? Heh, yeah, had to chose between SX vs DX, and even then only special programs utilized the advanced "math co-processor", and most programs had to be written as if it wasn't there because you couldn't rely on it being present. Hey, remember when you couldn't count on the computer being able to perform multiple threads in hardware? Hey, remember when computers were single core?

Hey, remember when GPUs and CPUs used to be separate things?

I'm glad someone has finally found a use for Intel's Android port.