Linux 2.6.28 Promises Year-End Presents

darthcamaro writes "Little penguins all around the world are waiting for Penguin-Master Linus Torvalds to deliver some Glogg inspired Xmas cheer in the form of the new 2.6.28 kernel. Among the innovations in 2.6.28 are ext4 as stable, wireless USB drivers, better KVM support and the GEM graphic memory management technology. 'We now have a proper memory manager for video memory, the GEM [Graphics Execution Manager] memory manager,' Greg Kroah-Hartman said. 'This gives Linux much better graphics performance than it previously had.'"

Comments

Re:I for one...

[TeknoHog]

...welcome our old Unicode-challenged Slashdot. BÃrk bÃrk bÃrk!

Re:The new graphics

[chunk08]

Hm, sry to reply to myself but according to Wikipedia it seems that the drivers have to be rewritten to support GEM. Still not sure about user-land software tho...

Nice start...

[TheNetAvenger]

Not quite Vista's WDDM abilities in dealing with GPU RAM, but a nice start that people other than MS are actually taking GPU RAM allocation seriously beyond simple context swtiching.

Re:Nice start...

[TheNetAvenger]

Maybe I'm misunderstanding your assertion, but hasn't MacOS X had universal GPU RAM management for many years? I don't think MS has any monopoly on this... it was my impression that it was just Linux that was on Microsoft's heels playing catch-up.

Yes you are misunderstanding, and NO the Mac has not...

OS X uses the 3D GPU as a bitmap composer for the display, and that is it.

OS X's composer is years behind most Linux desktop composers as well as Vista's DWM/Aero. Vista's DWM for example is Vector/Bitmap based, and works with the WDDM of Vista that gives it a lot of power. (WDDM is the new driver model in Vista)

Here are some of the things Apple needs to add to catch up to even Vista.

- GPU RAM Virtualization/sharing (something kind of like what they are trying do with the Intel chipsets and Linux in this article - except Vista does this over the AGP/PCI bus with any Video card and works with or without dedicated GPU VRAM.

- GPU Scheduler - In Vista, the OS, not the applications controls the GPU, and Vista brings pre-emptive multi-tasking to the GPU. (And no this is not like OpenGL applicaiton yielding/cooperative multitasking, as DirectX also does what OpenGL does. This is an OS level management system that opens up a new way of thinking beyond one 3D application on screen at a time concepts that don't depend on applications yielding the GPU. Kind of like the move to the 32bit era where the Intel CPUs offered a pre-emptive scheduler.

(Example: several games on screen at once in Vista, set transparent with a HD video waterfall playing in the background and losing very few FPS in each game and Aero also using the 3D GPU to do its things, like compose the Game Windows with a transparent waterfall behind them and do a shared texture combine write to the video card.) - This is not something you want to try on a Geforce 5200, but it will work, and on newer video cards, even the 7900 series from Geforce, you can do some really amazing things when running multiple games 'viewable' on the screen at once.

- Legacy application 3D acceleration. Apple tried to get this going with 10.4 as an optional switch, but it was too buggy and scrapped as a feature for 10.5. This means that OS X still renders content using good old fashion legacy 2D GPU features or SSE Intel extensions. On Vista, even Windows 3.1 applications get a performance boost as GDI drawing, Font Rendering, and even internal bitmap APIs are shoved through the 3D GPU because it is significantly faster than older 2D GPU rendering methods.

- Vector composer. On Vista when it is running newer WPF applications, instead of the DWM getting a bitmap that is composed to the final render of the screen, the WPF applications tell the DWM/Aero what changes are made, usually vector based (XAML), and the Vista composer makes the changes at the composer level instead of the application having to redraw the application and send a new bitmap of the Window to the composer to assemble. (This is also why RDP (Remote Desktop) on Vista is faster and more featured than XP, as it works at the DWM level and a lot of the operations sent over the network to render the screen are vector based and lightweight, leaving the client to do the heavy rendering instead of passing bitmaps all the time. This is why you can do Aero Glass and WPF 3D over a slow RDP connection remotely.

----
Ok, I am going to stop here, as I am writing this off the top of my head and it would better if you would just visit technet at www.microsoft.com and lookup the Vista WDDM and DWM and WPF technologies.

The whole driver and video changes in Vista were dramatic and borrowed ideas from the XBox 360 development team and do some really impressive things, even though MS didn't put much into the 'cute' uses of it in the UI like they are doing with Windows7.

---

Linux/*nix also has some good composer technologies that make OS X's composer pretty sad in comparison.

With Linux there are still some major driver and kernel level hurdles

To clear somethings up

[Anonymous Coward]

GEM is short for Graphics Execution Manager, it is a graphics memory manager for the kernel written by Intel.

If graphics device drivers want take advantage of GEM, then they need to add some code for GEM in the device driver.
A memory manager for the graphics memory is very useful because it allows direct rendering and direct redirected rendering and such.
This means you can now do things "the real way" which have previously either not been possible, or been done using some dirty hack such as indirect rendering.

Re:To clear somethings up

[squiggleslash]

Kind of a shame, I was hoping they were integrating the Digital Research Mac-like User Interface system for DOS (and the Atari ST) into the kernel, just to annoy purists...

Re:To clear somethings up

[Anonymous Coward]

That really does not impress me.

You're not supposed to be impressed, you're supposed to be able to easily fix your graphics (or any other driver/configuration) setup with more-or-less your expected setup. Non-expert users will be impressed by that. Or at the very least less pissed off by the problem they're experiencing.

Cry me a river.

Yeah, fuck all those people who don't want to learn X configuration file formats off-by-heart! But I bet you'll be the first person bitching and moaning when vendor X doesn't provide Linux drivers and vendor Y's software doesn't support Linux. Newsflash genius, it's the masses that bring the recognition and the cash to make the vendors take notice. If you ever want Linux to do all those things that "Year of Linux" spouters have been droning on about for the last decade you're going to have to realise that making Linux useable, maintainable, and fixable by average Joe's with as little fuss as possible is the only thing that matters to the long term future of Linux as a desktop OS.

Further enlightenment into 2.6.28

[sega01]

If you haven't been following every commit's short log, you may find http://kernelnewbies.org/Linux_2_6_28 useful. I for one, would like 2.6.28 for Christmas.

Re:2009

[Shetan]

The moderators are drunk on Christmas spirits.

Re:The new graphics

[grantek]

Intel staff were the ones mainly responsible for implementing GEM, so their driver supports it. The open-source ATI drivers recently got a layer of glue to use GEM on the outside without changing much of the TTM-based code that was on the inside. I don't know what nouveau is up to, but the nvidia blob has had a lot of memory management stuff implemented independently for a while now in their X driver.

Phoronix follows a lot of this stuff well.

Linus just released it

[diegocgteleline.es]

http://lkml.org/lkml/2008/12/24/105

It doesn't really matter what day it is, or what holiday (if any) you're
celebrating, because even if you sit at home, alone in your dank basement,
without any holidays or friends, I bring you a tiding of great cheer: you
can now download Linux-2.6.28, and compile it to your hearts content!

Listen to the cheerful grinding of your harddisk as you reboot into an
all-new kernel - and I'm sure that if your computer could smile, it would
have a big silly grin on its non-existent face. So as you sit there in
your basement, give your computer the holiday cheer too.

In fact, even _if_ you have friends or family, leave them to their endless
toil over that christmas ham or turkey, and during the night, when they're
asleep, you can give them that magical present of a newly updated
computer. When they wake up tomorrow morning, tell them how you saw Santa
crawl down the chimney with his USB stick in hand, updating the OS of all
good boys and girls.

Ho, ho, ho,

                Linus "almost Santa" Torvalds

Re:2009

[_Sprocket_]

It's because every year is the year of Linux. Its just funny that some people haven't realized it yet.

Re:2009

[Anonymous Coward]

The moderators are drunk on Christmas spirits.

Which is only proven by the fact that they modded you insightful for that very comment.

Re:The new graphics

[dow]

What should be important is that maybe next gen games should be released on Linux as a platform equal to Windows.

I was a long term Linux user, who went to XP just for the games. My gaming rig is waiting an RMA on a PSU, so rebuilt an old system and installed Slackware.

On an older machine with slower drives and a quarter the Ram, the responsiveness of the OS is amazing. If mainstream games were released for Linux I'd have no choice.

Sadly, I mainly use computers these days for relaxation, shopping and play, and if I'd continued as I set out, would no doubt be a full time Linux user... However, as a gamer, I put up with XP64 as a day to day OS.

Re:Heh

[TheRaven64]

To clarify:

DRI1 is a big lump of ring-3 code and a small chunk of ring-0 code. The ring-3 code issues commands, the ring-0 code validates these commands (to make sure that DMA is being safely used and so on) and passes them off to the device. With DRI1, you have some things, like setting the graphics mode, which are implemented in the kernel's (X-independent) driver and then implemented again in X.org. This leads to copy-and-paste errors and all sorts of other problems (like power saving, since the kernel driver now knows less than it needs to about the state of the GPU).

The ring-3 blob is also responsible for setting up memory mappings for DMA, which is bad for three reasons. Firstly, it means that every driver is implementing almost identical code. Secondly, it means each driver is implementing code that depends a lot on kernel interfaces, making porting harder than it should be. Finally, it is bad for security.

With DRI2, the kernel controls the IOMMU (if there is one) and sets up memory mappings so that the driver just mmap()s regions of device memory or physical memory. There are quite a lot of related improvements, although I'm not sure exactly which ones are part of the DRI2 'brand.'

The non-GL acceleration interface is cleaned up a lot, to make supporting compositing and spline rendering easier and the GL state tracker is moved out of the driver and into a separate bit of (ring-3) code. This simplifies the drivers even more, since their interfaces to the system is now stateless (DRI2 drivers are a fraction of the size of DRI1 drivers). This means that they all share a lot more code, which is good for stability (since it's now code that's tested by a lot more people) and good for cost (it's now cheaper to support X.org). The nice side effect of removing the state tracker is that it's possible to plug in new ones, for example OpenGL ES or DirectX. the WINE guys have been talking about porting their DirectX back end to issue DRI2 calls directly, rather than OpenGL, so that there is no overhead - DirectX and OpenGL are both first-class user APIs on top of the low-level API.

The DRI2 stuff is a good example of open source done right. The result will be that each of the concerned parties (kernels, driver writers, X server, GL state tracker) all have a simpler codebase to maintain as a result of using standardised interfaces to other code. This leaves nVidia out in the cold - they are stuck maintaining their own memory manager, mode setting code, GL state tracker, and so on, while their competitors aren't. Developing a Free Software GPU driver costs a small fraction of the cost of maintaining the nVidia driver, which to my mind is a far better way of advocating Free Software than bludgeoning people with reciprocal licenses (the DRI stuff in X.org is MIT licensed, only the Linux kernel part is GPL'd).

Re:The new graphics

[morgan_greywolf]

Ditto on Ubuntu. The package management scripts are very intelligent in regards to Xorg and Mesa updates when the NVidia drivers are installed. Kernel updates, Xorg updates, and Mesa updates will all trigger init scripts that re-install the NVidia restricted drivers.