Originally posted by Kano
View Post
Announcement
Collapse
No announcement yet.
Ubuntu 10.04 May Backport More Kernel DRM
Collapse
X
-
I would not call .33 an overall better kernel. I had issues even booting .33-rc8 on one of my systems. It just has some more interesting drivers. When you exchange the whole DRM stack it should not be that hard to do. The only problem i see is when you want to get security fixes in it. Then you have to track .32 AND .33 DRM. More likely that you will not get all. That's already now the case if you don't know it. U does not rebase after the first final of a kernel. They add extra SAUCE patches that often break stable relaese updates. So you can do serveral things: a) rebase on your own and fix the patches that are problematic, b) rebase and skip all problematic patches (that's what i did for 32-9 in Excalibur) or c) just leave the U source as it and hope all needed patches have been applied. Precompiled kernel do not interest me at all as i need some changes for extra hardware support, BFS and some extra backwards compatibility. Also U does not ship firewire headers which are required for complete external DVB updates (i.e. via dkms). I mentioned that a few times, but as it got not applied i got bored and only patched my kernel.
Comment
-
what ever they choose will have to maintained for a long time. surely a close to vanilla kernel will make this easier.
however greg kh has said that 2.6.32 will be a long term maintenance kernel (like 2.6.27). but that decision was based on the fact that big distros are planning to use it for big releases (eg ubuntu lucid).
Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
i thinks its a shame that closed source drivers might hold back new open source stuff getting to users.
Comment
-
I think the real question here is going to be whether Lucid should be "the last UMS release" or "the first KMS release".
If Lucid is going to focus on UMS (which AFAIK is *not the plan) then 2.6.32 should be OK, but if the plan is to go with KMS then pretty much all of the changes in 2.6.33 drm should be picked up, ie either a massive backport or pulling the whole drm.
Support for UMS is starting to disappear from the drivers, which means that picking up new kernel drivers (or a *lot* of backporting) is going to be how new graphics hardware is enabled in the future -- and graphics hardware changes more quickly than most other devices.Test signature
Comment
-
FWIW, I am running Lucid with the mainline kernel 2.6.33 , Radeon HD 3450
For KMS to work you need to get some firmware files manually, but even so, you get less performance than with UMS. Roughly speaking:
* Open source stack is 3 to 5 times slower than catalyst in karmic in 3D, and comparable in 2D.
* Open source stack with kernel 2.6.32 + UMS is very similar than 2.6.33-mainline + KMS
* Open source stack with kernel 2.6.32 + KMS is 25% faster.
Comment
-
Originally posted by mendieta View PostFWIW, I am running Lucid with the mainline kernel 2.6.33 , Radeon HD 3450
For KMS to work you need to get some firmware files manually, but even so, you get less performance than with UMS. Roughly speaking:
* Open source stack is 3 to 5 times slower than catalyst in karmic in 3D, and comparable in 2D.
* Open source stack with kernel 2.6.32 + UMS is very similar than 2.6.33-mainline + KMS
* Open source stack with kernel 2.6.32 + KMS is 25% faster.
* Open source stack with kernel 2.6.32 + KMS works, but 3D acceleration is not workable. I start compiz, then the screen turns white.
* Open source with kernel 2.6.32 + UMS runs so faster than kernel 2.6.32.7 + KMS in Fedora 12. 3D is OK, But it is buggy.
Comment
Comment