Slashdot Mirror
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.'"
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...
Do away with our corrupt tax code. Support the Fair Tax
""We now have a proper memory manager for video memory, the GEM [Graphics Execution Manager] memory manager," Kroah-Hartman said. "This gives Linux much better graphics performance than it previously had."
The video improvements in Linux also extend to power utilization for graphics. Red Hat Fedora Project Leader Paul Frields told InternetNews.com that the 2.6.28 kernel enables reduced power consumption across the video driver subsystem in the vertical blanking routines, which will be helpful to mobile users."
That is all that is mentioned (above quote) about the state of 'the new graphics' in the new kernel.
Down With Slashdot BETA!!! I've been around the corner and seen the oliphant; you can only abuse me from your perspecti
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.
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.
It is also another open source project OpenGEM based on the original DRI GEM. GEM was a Windows like 16 bit interface for DR-DOS and MS-DOS like Windows 3.X was. Apple sued them and they had to change their look a feel, and Atari used GEM as a GUI for TOS.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
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.
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
It prevents shatter attacks. It can be turned off and a UAC window made to act like any other.
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
Except that this isn't at all equivalent to that. That would be the equivalent of moving the X server into the kernel, not just some directly hardware facing parts of the drivers.
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
The independent desktop for UAC is true, and it would require a driver to interact with it. (And yes a big red driver prompt, warning, etc)
Also the UAC 'desktop' runs at TrustedInstaller or System level security, so it takes a system level driver to respond to it. (It is not impossible, but it would be pretty hard for a driver exploit to get past this, as the driver would have no way to 'see' what was on the screen to know where to click, etc.)
A side note, Vista supports multiple desktops (and even varied security) launched in a single user login, even though there is no UI for this feature (One can be downloaded from Sysinternals).
I'm not sure how useful this is, but as the Sysinternal's utility allows, it creates 'virtualized' desktop without the virtualizing, as the desktops are independent full desktop contexts.
So each desktop can run a separate version of Explorer, etc - within the same user login.
(The term 'desktop' here is used loosely as it pertains to GUI process context in Windows.)
This is not a revolutionary feature, just something kind of interesting, as it is separate desktop contexts within a user login within a multiple user environment.
...by bundling the Nvidia package and its libraries to a package matching the Mesa components and install one or the other, but no one has yet done so.
Gentoo does an excellent job of managing the upgrades - the Mesa and Nvidia drivers are installed to different locations and symlinks are used to choose the right one, with a nice wrapper script to make it easy to choose what one you want with eselect.
GDI graphics are not hardware accelerated on windows vista (WDDM 1.0), you can read this everywhere on the internet. However, GDI hardware acceleration will return with Windows 7 (WDDM 1.1). I suspect this is why Windows 7 will be much "snappier" than Windows Vista. Also memory usage will be reduced, because GDI graphics can be kept in the graphics memory of the videocard, instead of as a bitmap in memory and as a bitmap in the frame buffer (and off screen acceleration memory?).
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).
I am TheRaven on Soylent News
Debian Sid is fine with the Nvidia drivers too. No conflicts with Mesa as long as you use the packages from non-free. Apt also recompiles the kernel driver every time you install a new kernel!
Nick
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.
My blog
Graphics stuff must be in the kernel at some level. The reason for GEM is that the entire system needs to have unified memory management for GPUs, just like for CPUs.
Also each GEM-capable driver has to support legacy mode. Linus was *very* clear on that point. So, starting with 2.6.29, each KMS or GEM driver supports non-KMS and non-GEM mode. (Some drivers, like the Radeon drivers, are all-or-nothing, so running KMS without GEM won't work.)
You're probably a BSD guy. Which is fine. Nothing wrong with that. Unfortunately, your upstreams have shown a rather lackluster interest in actually participating in these DRM changes. While there are a few guys working on porting this stuff, most of us are not BSD guys and are certainly not required to make it work across kernels. We're trying to make it as open and clean as possible, though. (DRM is actually built from a shared core that has Linux and BSD wrappers.)
And really, you don't want drivers in X. That's what we've done for a long time, and frankly, it sucks. Poor memory management, poor direct rendering. Lock contention, kernel sareas, GETPARAM/SETPARAM insanity. Each new feature requires kernel modifications and new ioctls which then have to remain working for a decade despite Mesa being the only real consumer of those ioctls. (nVidia doesn't use our DRM. They got this stuff working a long time ago on their own code. That's right, the closed-source drivers do this.)
Sorry for ranting, but that's the way it is.
~ C.
In Vista, the DWM prevents GDI commands from being accelerated, which represents a regression relative to XP. The compositing does mean that moving windows can be smoother, but when the contents of the window change, Vista is liable to be slower (in addition to using twice as much memory for that window due to a pixel format mismatch between DirectX and GDI). Thus, legacy applications are not likely to be able to draw any faster on Vista than on XP.
I know there have been discussions on this before, but it isn't a complete either or...
Some GDI functions are not shoved through the 3D GPU nor the 2D side of the GPU (assuming there is one), and yes you are correct that these are CPU processed.
However, there are a lot of GDI functions that are shoved through the 3D GPU more than compensating for any CPU rendered GDI functions.
For example we could go through a list, and there are some line drawing, bitmap/DIB drawing, and scattered GDI and especially GDI+ functions that are rendered on the 3D GPU. (Font rendering is 3D assisted as well, no matter if WPF or GDI calls the functions.)
Also when you get into GDI+ level functions like transparency/layered windows, these are very much shoved through the 3D GPU for rendering.
And again, these are actually GDI routines being hosted/processed by the 3D GPU, not just the end result of the 3D Composer as you suggest I am conflating.
Actually there is the Fluendo MP3 codec which is licensed and legal for use and free distribution. For DVD, there are legal players like LinDVD and PowerDVD, but they aren't free. I didn't realize this until I did a search just now, but apparently you can buy PowerDVD from the Canonical store (for Ubuntu), and other distros probably have something similar.
I'd love to scrap the Direct3D code I have to use now on Vista in order to get decent blitting performance.
Why are you even hitting into DirectX, you should be shoving it through .NET 3.5 and WPF, as this is even accelerated on XP via 3D acceleration.
The whole WPF API set is there specifically so you don't have to drop to DirectX unless you are trying to squeeze the last ounce of performance out of a high end game. You should even be able to obtain a Windows 'texture/image' and use it as a brush via WPF, getting the performance you might be needing that GDI just can't do.
If I am reading your post correctly, you might want to consider tapping into the DWM API as well. From there you can request and process 'thumbnails' of running application windows. And they can be any size from tiny to original to even enlarged version of the source Window Bitmap, and they are also fully live previews, so when you tap the DWM 'thumbnail' of another application you can get as well as directly render the Window to your own form/window at the DWM level. (3rd party applications like the expose' clone use this to scatter the Windows like on OS X with the contents still being live and responding as if they were the original application Window.
There are a few aspects of WDDM that are not API accessible at least in Vista, and hopefully this changes with Windows7 and its WDDM API updates to expose the DWM and in between operations. WPF also has some abilities in this area, but it is still young.
Good luck...
It was much easier (and guaranteed to be fast enough) to switch to Direct3D rather than to rewrite the application using .NET and WPF (the app existed before Vista was released), although this is very off-topic with regards to GDI acceleration.
I'm not interested in fetching data from on-screen windows/surfaces so I don't have any use for the DWM API (even though I was already aware of it, including it's limitations). All I wanted was fast GDI blits (in any way) but I couldn't pull this off. ATI and Microsoft employees (reluctantly) confirm that there is no longer any GDI acceleration in Vista, so you'll need to come with something concrete (such as a link) in order to convince me of the opposite.