Intel Sends First Batch Of Changes To DRM-Next For Linux 4.12: 550+ Patches

[phoronix]

Phoronix: Intel Sends First Batch Of Changes To DRM-Next For Linux 4.12: 550+ Patches

Intel is off to the races in preparing their new feature material work they plan to have introduced for the Linux 4.12 kernel, even though Linux 4.11-rc1 was just introduced on Monday and thus still nearly two months until the 4.12 merge window...

http://www.phoronix.com/scan.php?page=news_item&px=Intel-DRM-Next-First-Linux-4.12

[uid313]

Intel supports OpenGL 4.5 and OpenGL ES 3.2.
But there is still work to be done on extensions that are not part of OpenGL.

https://mesamatrix.net/#Version_Otherextensions

Also Intel's Kaby Lake wont have a GPU that will be able to match the GPU of upcoming AMD Ryzen processors with high-performance integrated AMD graphics that will blow the graphics of Intel out of the water.

Does Intel still have no interest in Gallium3D?
What is the state of OpenCL, OpenVG, and OpenMAX?

[boxie]

Intel supports OpenGL 4.5 and OpenGL ES 3.2.
But there is still work to be done on extensions that are not part of OpenGL.

https://mesamatrix.net/#Version_Otherextensions

Also Intel's Kaby Lake wont have a GPU that will be able to match the GPU of upcoming AMD Ryzen processors with high-performance integrated AMD graphics that will blow the graphics of Intel out of the water.

Does Intel still have no interest in Gallium3D?
What is the state of OpenCL, OpenVG, and OpenMAX?

so - let's break this down - there is always more work on extensions, the primary market for Intel graphics is business desktops and small laptops (and it does this really well), AMD has to at least match that with their own chips, as well as go higher end. No Intel has no interesting in Gallium 3D, it would be a massive effort to rework it for little potential gain. OpenCL (via beigenet) is getting to 2.0 levels and performance. NFI on OpenVG or OpenMAX

[polarathene]

Something in the 4.9 kernel causes 2nd suspend/resume cycle to freeze the system(can't switch to different TTY or SSH in, logs or I/O rather seems to have stopped too...). From those affected(myself included), seems to be Skylake reported only. 4.8 works great but 4.9, 4.10 and presumably 4.11 all have this issue. Any idea how to debug it? Could it be some Intel power management or similar that was changed in 4.9? I'm using the iGPU with generic modesetting driver.

[Mystro256]

polarathene my first approach is always to bisect and report the broken commit. Granted, I would think 4.8 to 4.9 must be a pretty big window.

[FireBurn]

so - let's break this down - there is always more work on extensions, the primary market for Intel graphics is business desktops and small laptops (and it does this really well), AMD has to at least match that with their own chips, as well as go higher end. No Intel has no interesting in Gallium 3D, it would be a massive effort to rework it for little potential gain. OpenCL (via beigenet) is getting to 2.0 levels and performance. NFI on OpenVG or OpenMAX

Before Ilo was removed from Mesa there was talk of wiring it up to use Nir like vc4 - the belief being that most of the Intel stuff could be reused from Gallium - there wasn't much interest though

[pal666]

4.8 to 4.9 must be a pretty big window.

luckily bisection has logarythmic difficulty

[tajjada]

Something in the 4.9 kernel causes 2nd suspend/resume cycle to freeze the system(can't switch to different TTY or SSH in, logs or I/O rather seems to have stopped too...). From those affected(myself included), seems to be Skylake reported only. 4.8 works great but 4.9, 4.10 and presumably 4.11 all have this issue. Any idea how to debug it? Could it be some Intel power management or similar that was changed in 4.9? I'm using the iGPU with generic modesetting driver.

I can confirm this issue on Kaby Lake.

Is there a bug report for it to track progress?

[polarathene]

I can confirm this issue on Kaby Lake.

Is there a bug report for it to track progress?

Yes, please join in and contribute anything to help get it fixed

https://bugzilla.kernel.org/show_bug.cgi?id=194631

[polarathene]

polarathene my first approach is always to bisect and report the broken commit. Granted, I would think 4.8 to 4.9 must be a pretty big window.

I've not done such before, is it difficult to do first time or just time consuming? Does it require compiling kernels from git commits and using those to verify when the bug was introduced? I've never compiled kernels before nor familiar with how to set them up for using at boot. It might be best left for someone more experienced/familiar with all that, though I'll help where I can.