A Preview Of Kernel-Based Mode-Setting

[phoronix]

Phoronix: A Preview Of Kernel-Based Mode-Setting

There are many new and innovative features brewing within the X.Org development community right now -- among the many are Gallium3D, the TTM memory manager, and MPX (Multi-Pointer X) -- but one of the features that has risen towards the top of the list and delivers visible benefits to the end-user is kernel-based mode-setting. As implied by its name, kernel mode-setting involves moving the mode-setting code for video adapters from the user-space X server drivers into the Linux kernel. This may seem like an uninteresting topic for end-users, but having the mode-setting done in the kernel allows for a cleaner and richer boot process, improved suspend and resume support, and more reliable VT switching (along with other advantages). Kernel mode-setting isn't yet in the mainline Linux kernel nor is the API for it frozen, but Fedora 9 shipping next month will be the first major distribution carrying this initial support. In this article we're looking more closely at kernel mode-setting with the Intel X.Org driver as well as showing videos of kernel-based mode-setting in action.

http://www.phoronix.com/vr.php?view=12240

[yoshi314]

more reliable vt switching will really help. that's where many drivers crash with x.org right now.

[TechMage89]

Can't wait until ati porting is done!

By the way, in the case of the X driver, does it just have a "dummy" ddx that passes everything to the kernel modesetting driver, or is there an actual structural change? Will there be any changes to how and where acceleration (EXA, Render, OpenGL) is handled?

[airlied]

Originally Posted by TechMage89

Can't wait until ati porting is done!

By the way, in the case of the X driver, does it just have a "dummy" ddx that passes everything to the kernel modesetting driver, or is there an actual structural change? Will there be any changes to how and where acceleration (EXA, Render, OpenGL) is handled?

Initially we are just going to use the normal DDX, with some common code, however for keeping compat with current randr-1.2 implementations, we'll need some impedance matching in the DDX layer between the kernel and randr interfaces.

nothing else will move, however we will be restricting what the X driver can access, i.e. no more direct register access, all accel should be done via kernel command submission etc.. so for Intel we have had to switch the DDX from using the ring directly to using batchbuffers and submitting those to the kernel,

the final point we want to reach is probably a driver with kernel modesetting/EXA/TTM and nothing else.

Dave.

[sc3252]

I love this site! Thank you Michael Larabel for taking the time to write about this(and to show an example). Hopefully I can see this in action on my new rv770 in the near future.

[remm]

The radeon(hd) drivers and nouveau have that stuff as a high priority item so I would expect the majority of current cards to get supported in Fedora sooner rather than later.

[Tillin9]

I can't wait for this in radeon or really any driver that isn't tied to a chipset (I don't think Intel has any discrete cards after i740).

Keep up the good work!

[Thetargos]

No Intel has no other discrete cards after the i740, but they will soon release some based on their new architecture (which in turn is based off the x86 instruction set), the name currently eludes me, as does the estimated time frame of its release.

[Michael]

Originally Posted by Thetargos

the name currently eludes me

Larrabee is the codename. Not to be confused with Larabel


Cheers,
Michael Larabel

[remm]

Larabee isn't showing up next month anyway (unfortunately, I would buy one), and I don't think good OSS support for it is going to be a problem