Intel Sends In The First Set Of Changes For Linux 4.16 i915 DRM

[phoronix]

Phoronix: Intel Sends In The First Set Of Changes For Linux 4.16 i915 DRM

While Linux 4.15-rc1 was just released this past weekend, Intel open-source graphics driver developers have already sent in their first pull request to DRM-Next of new feature material targeting Linux 4.16...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.16-Intel-i915-Pull-1

[MuPuF]

So now you need to have Cannonlake computers, other and older intel hardware is buggy according to intel developers.

Let's not push it, please. We have been bad at not regressing the kernel, but in the past year, we have improved dramatically! Our CI system tests every family since 2004, we prevent regressions there, and even fix bugs on them. Go find another company doing anything close to that.

Check out https://intel-gfx-ci.01.org/tree/drm-tip/, https://intel-gfx-ci.01.org/, and https://lwn.net/Articles/735468/ for more information.

[tildearrow]

Typo:

Simplications around GT power savings and power-gating.

[MuPuF]

Why there is a lot of intel drm bug reports in Mesa bug reporting system.

Answer, because wintel developers are in the wintel conspiracy to sell new wintel hardware.

I do not work for AMD, so I can't comment on that. For the Intel issues, do you have a links to the bugs, please? Were they a regression or has it never worked?

In any case, we are working on not *regressing* the kernel, features and bug fixing are on a best-effort basis (especially on such an old hardware). Even though we have been increasing drastically the HW coverage of our system, the testing is only as good as our test suites... There will always be regressions in corner cases...

[polarathene]

I do not work for AMD, so I can't comment on that. For the Intel issues, do you have a links to the bugs, please? Were they a regression or has it never worked?

In any case, we are working on not *regressing* the kernel, features and bug fixing are on a best-effort basis (especially on such an old hardware). Even though we have been increasing drastically the HW coverage of our system, the testing is only as good as our test suites... There will always be regressions in corner cases...

I think you guys are doing great and really appreciate the rate of improvements As far as older generations go, it seems mostly fine from broadwell and up these days with skylake and cannonlake having some additional features(presumably because the hardware makes that possible and previous generations lacked it). I do have a haswell laptop which misses out on some of those features like the better GVT support, but I totally understand that it just isn't possible/viable to extend the support back to that generation for whatever reason

Keep up the good work!

[timofonic]

This needs a separate news article, it deserves more atention:

Many GVT changes for 4.16: - CSB HWSP update support (Weinan) - GVT debug helpers, dyndbg and debugfs (Chuanxiao, Shuo) - full virtualized opregion (Xiaolin) - VM health check for sane fallback (Fred) - workload submission code refactor for future enabling (Zhi) - Updated repo URL in MAINTAINERS (Zhenyu) - other many misc fixes

What about full virtualized GPU in full accelerated environment without using remote desktop tools? How are going the dmabuf experiments? What about possibility to use a vGPU with Optimus? I know it's not Intel's issue, but many people with Optimus laptops are suffering this nightmare and miss more flexibility when dealing with Virtual Machines. If Intel solves this, it will get even bigger fame in FOSS

[timofonic]

repeated

[MuPuF]

I think you guys are doing great and really appreciate the rate of improvements As far as older generations go, it seems mostly fine from broadwell and up these days with skylake and cannonlake having some additional features(presumably because the hardware makes that possible and previous generations lacked it). I do have a haswell laptop which misses out on some of those features like the better GVT support, but I totally understand that it just isn't possible/viable to extend the support back to that generation for whatever reason

Keep up the good work!

Thanks for the kind words.

I do not know why GVT-x was not enabled on Haswell, but we generally enable features as far back as we can. However, we would rather work on exposing newer features as early as possible (before the platform hits the shop) rather than prioritizing older platforms.

As an example of us enabling features for older hardware, here is the latest example: https://patchwork.freedesktop.org/series/43902/ . This enables color-keying for planes on VLV/CHT, which was apparently released around 5 years ago.

[polarathene]

Thanks for the kind words.

No problem I have heard GVT support is lacking in newer Intel models? 8th gen Kabylake-R for example? At least, iirc some users have tried to use it on such hardware over at r/vfio and found it doesn't work? If that's the case do you know if there are any plans to add support to these new models?

[chithanh]

in the past year, we have improved dramatically! Our CI system tests every family since 2004, we prevent regressions there, and even fix bugs on them. Go find another company doing anything close to that.

So you don't test/care about anything prior to 2004?
To my knowledge, i810/i815 are broken and have been for years. i830/i845/i865 are wonky.

Also are there still improvements planned for Intel chips with 3rd party GPUs? Recent reports about Clear Linux support for Radeon (possibly Kaby Lake G / Vega M related) seem to indicate that Intel at least has marginal interest. But what about Atom x3 (SoFIA), will it get similar treatment when mesa-lima progresses? And the PowerVR Atoms?