Diagram of upcoming X features

[elanthis]

Well, for what it's worth, Fedora Rawhide is working awesome for me.

Only thing is that KMS is still apparently disabled for R600 -- at least Plymouth is still showing text boot for me on a 780G integrated chip. There were some comments in the kernel changelog about disabling KMS so EXA acceleration would work (why?) but that was a while ago.

KMS supposed to still be disabled, or is there something else I should be helping to debug?

[bridgman]

Yeah, GEM/TTM allows some more OpenGL features to be supported in Mesa, and those features allow apps to run more efficiently. The good news is that (in theory) those features are already supported in Mesa's Gallium3D code paths so (again in theory) once Gallium3D is supported on a GPU the higher level code should already be there. In practice it's never quite that simple, of course.

The diagram looks good; RDR probably belongs either in Mesa or Gallium3D, probably the latter.

One other thing worth mentioning is that some of the dependencies are "hard" (A can't work without B) while others are "soft" (A is being implemented using B, but could be implemented without B if someone felt like it).

Examples of "soft" dependencies are :

- Gallium3D is being implemented over DRI2 and GEM/TTM, but could be implemented over the existing stack

- KMS and GEM/TTM are being implemented and tested together (airlied's priority is KMS but he needs GEM/TTM to do it) and are switched on and off as a set; GEM/TTM could work without KMS in principle

[bridgman]

Only thing is that KMS is still apparently disabled for R600 -- at least Plymouth is still showing text boot for me on a 780G integrated chip. There were some comments in the kernel changelog about disabling KMS so EXA acceleration would work (why?) but that was a while ago.

KMS builds on GEM/TTM, so the acceleration code in the X driver also needs to be changed so that it uses GEM/TTM buffers rather than managing memory locally.

I don't think GEM/TTM for 6xx and up is running yet, and by running the non-KMS code paths you don't need GEM/TTM.

[elanthis]

Ah, okay. Thank you for the explanation, I've been wondering about that for a while.

[suacy]

Take Four

I made a quick image that might help users understand when their complaints will be solved. Let me know if it's accurate.

http://img16.imageshack.us/img16/553...nsolutions.png


Thanks

[Kreed]

With both GEM/TTM and KMS moving into the kernel, it looks like all the *BSD's will be left behind.

[bridgman]

Do you think so ? I agree that the rate of change is huge right now (which is really hard on the FreeBSD devs) but I didn't think there was anything inherently incompatible with FreeBSD coming down the pipe.

This is another reason to keep user modesetting alive; I think it'll be a couple more years before it goes away completely. For now we're just trying to keep the code relatively common between kernel and user modesetting, so that each change only has to be made maybe 1.2 times rather than 2 or 3 times

[bridgman]

I made a quick image that might help users understand when their complaints will be solved. Let me know if it's accurate. http://img16.imageshack.us/img16/553...nsolutions.png

That looks good; and clear.

Only one change; DRI2 will give a standard solution for OpenGL under Compiz, but my understanding is that DRI2 isn't needed for video under Compiz (at least video going through the X server). DRI2 probably *is* needed for direct-rendered video but there isn't much of that happening yet.

Hm. Maybe keep it as-is

[Michael]

With all both GEM/TTM and KMS moving into the kernel, it looks like all the *BSD's will be left behind.

NetBSD is expected to have it sooner rather than later due to the security benefits of running the X Server without root privileges.

In regards to OpenSolaris umbrella, well, something is happening Details will be on Phoronix soon as I am allowed to share.