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...

No answers to your question in TFA.

[rts008]

""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.

Re:No answers to your question in TFA.

[TheRaven64]

Although not part of GEM, one related improvement is moving modesetting into the kernel. Currently, when you switch to an X11 VT, X11 requests the console be set back to VGA then initialises it to the correct mode itself. This is really horrible, and doesn't play nice with power management (because the kernel doesn't know anything about the GPU state, so can't easily save and restore it). The modesetting branch in X.org has been defining some clean kernel interfaces for doing this, simplifying both the kernel and the X server in the process (since both previously contained lots of special-purpose code for doing the same thing for each device).

As with GEM, this isn't a Linux-specific thing, it's driven by X.org and being implemented on Linux, *BSD and Solaris.

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...

[Anpheus]

Because the UAC window is on an independent desktop that other applications cannot interact with. The only possible flaw is if something has installed itself as a mouse or keyboard input driver, I believe. But doing that will spawn a great big red unsigned driver prompt.

Re:Nice start...

[FishWithAHammer]

It prevents shatter attacks. It can be turned off and a UAC window made to act like any other.

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

Re:Nice start...

[TheNetAvenger]

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.

Re:Nice start...

[644bd346996]

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.

Compare this with Quartz 2d Extreme, now known as Quartz GL (and not abandoned as you say). Existing applications can have their drawing accelerated at the cost of a potential for glitches or performance problems (due to limited bandwidth from the CPU to the GPU), and new applications can enable acceleration at the discretion of the developer.

Re:Nice start...

[TheNetAvenger]

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.

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

[Neil Hodges]

We had one of those when 2.6.9 came out, but not since. A shame.

Re:To clear somethings up

[Mad Merlin]

A memory manager for the graphics memory is very useful because it allows direct rendering and direct redirected rendering and such.

A definite step in the wrong direction.

One of the things I've always liked about *nix is the separation between kernel and graphics.

No matter how horked X is, I the system always boots in text mode console and work to repair X or a driver, install new software, etc, and even accomplish things with Mutt and links2.

Then, when I'm ready to "go graphical", simply run startx.

You don't really understand the consequences of doing kernel mode setting then. None of your use cases will be impacted by the addition of kernel mode setting, except that you'll be able to more easily get different resolutions out of your virtual consoles (you can already do that with framebuffer consoles, sometimes, depending on the hardware, and what driver you're using with X (if any)).

Re:To clear somethings up

[Anpheus]

Let me put it to you in a way that should impress you: Kernel modesetting allows things like the Windows BSOD and the Mac Kernel Panic, which means that when your kernel dies you can get a direct, immediate error message with details.

Those STOP messages in BSODs are pretty important for figuring out what's wrong with Windows, I imagine with the open kernel of Linux, you could have much more detailed errors.

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.

Re:To clear somethings up

[Kjella]

This allows people who are not so technically proficient to fix their computer without having to resort to using a command line.

Cry me a river.

May you be forced to debug some WTF message without any browser but lynx to help you. Of course, you're probably among the 1% that knows that lynx exists and is able to navigate your way to google and find the answers without a mouse to click. Great that you're built that way, but l33tnix is over there ------------> and the rest us of would like a system that isn't more arcane and user-unfriendly than necessary.

Re:To clear somethings up

[Hal_Porter]

The reason for 640x480 is because safe mode uses the generic VGA driver and 640x480 is widely supported. Actually since XP the generic VGA driver which allows higher resolution modes. No hardware acceleration of course since every manufacturer implements that in their own way.

Actually XP had a cool trick with graphics drivers. If a thread hung inside the manufacturer provided accelerated graphics driver the GDI would switch to the generic VGA driver and pop up a message explaining what had happened and prompting you to reboot. I.e. it could switch from 1024x768 accelerated 32 bit color to 640x480x16 color and keep running, even though a kernel mode thread had hung.

Re:To clear somethings up

[cyber-vandal]

making Linux useable, maintainable, and fixable by average Joe's with as little fuss as possible

I'm still waiting for Windows to get to that point never mind Linux.

Re:To clear somethings up

[Yfrwlf]

"instead of having a distinct HAL in X you use the system one"

Wasn't that their point? That it's a separate system, so that if it fails, you'll still at least have the command line?

You can always make the argument that, well, if the code is good, then it should work, so what is the issue here that everyone is beating around the bush about? I think it's stability via intelligent programming. If you have the command line as a failsafe for when X fails, it gives you extra protection against bugs, which will always be there somewhere. You shouldn't just expect code to be written correctly, you should fortify yourself for when things break. If this can still be done even with kernel mode setting and such, if the kernel can switch to a failsafe if GEM or whatnot fails, then that will certainly help. Simplifying software stacks and creating APIs for performance and ease of programming = good. Removing failsafes = scary, unless they added some other failsafe somewhere else or whatnot, or maybe there's already one there.

And no, don't say reformat reinstall, that's the Windows failsafe. :P

Re:To clear somethings up

[radish]

That page is a hoot. In general I groan whenever a software homepage has a "Philosophy" section, but the installation instructions more than make up for it...

Installation for Non-Programmers (emphasis mine)
      1. FBUI resides inside the 2.6.9 kernel, so the first thing you must do is to get the kernel, un-tar FBUI in its directory, select the necessary options mentioned in the README, then make the kernel and update your loader to let you boot the new kernel. (I will offer a precompiled x86 kernel later.)
      2. You also need to tell your boot loader to switch to the VESA console during booting. In LILO use the expression vga=792 for a 1024x768 display or vga=789 for 800x600.
      3. Then you boot with the kernel. Next you need to set up the PCF font directory, populating it with fonts from the X distribution, making sure to uncompress them. The PCF font reader is really just a temporary chunk of code so I'm not going to update it to perform automatic decompression. Note, if you aren't sure where the fonts are, type (as root) find / -name "*.pcf*". To make sure libfbui knows where they are, you can use the PCFFONTDIR environment variable (as in export PCFFONTDIR=/path...).
      4. Once you've done these things, just compile the sample programs in /usr/src/linux-2.6.9/libfbui and run them from there. You may find it helps to run a program in a different virtual console using the -c switch.

See how easy? I am a programmer and that's... well... yeah.

Re:To clear somethings up

[Bert64]

Or you can use a LiveCD to fix your linux install...
While it's rare to require the command line on windows, this is primarily because the cli isn't powerful enough to make it viable for most tasks.
Most tasks in linux are possible without the CLI too, but when you ask an expert for advice they will often tell you the CLI way because it's usually easier to explain... Trying to baby someone through a gui where they might have changed the color scheme or moved things around is very difficult, telling someone "type this" or giving them some text to copy/paste is much easier, assuming they can read.

It's not uncommon to require registry editing to fix windows problems, a task which is more arcane and complicated than anything on linux... The CLI on linux has man pages and help flags for individual commands, and text files you might need to edit usually have helpful comments... What does the registry have? a bunch of arbitrary text strings and undocumented numbers?

It's Christmas!

[Chris_Jefferson]

It's Christmas! Be sure to go to bed, get up, and spend the day with friends, family and food. Do you really need to update your kernel today? Why not let other people find out if there are some terrible early bugs in it?

Re:It's Christmas!

[Hal_Porter]

Santa provided this kernel. If you install it and if kills your box you must have been naughty, if it works well you must have been nice.

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:Oh oh GEM is copyrighted

[John Hasler]

I yhink that you are trying to say that "GEM" is a registered trademark. One cannot "copyright" a three-letter string.

Re:The new graphics

[diegocgteleline.es]

I recommend reading this link to get an idea of what's going on in the Linux graphics stack:

"So currently there is not one field where construction done but several. These are 2D Acceleration, Memory Management, 3D Acceleration and 2D Modesetting. And they are all being worked on at the same time to speed things up.

But the problem is that more or less all of these depend on proper Memory Management, which is also the hardest thing to get right.

Now lets look at how Xorg works today; every Xorg driver implements its own way of memory management and provides the DRI1 functionality when it comes to 3D. Furthermore it is responsible for modesetting, which is quite suboptimal, since some perliminary modesetting is already done in kernel, so it can output messages during bootup. The Xorg driver resets the hardware again when it is loaded.

Kernel Based Modesetting

In order to solve this duplication the modesetting code is about to be moved into the kernel, so the hardware can be setup once and for all. But since modesetting involves memory management which is not done properly yet too."

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:Linus just released it

[Anonymous Coward]

Oh, my... The man is insane.

Best Christmas Gift, in the Kernel way

[DiegoBravo]

A new and single sound stack (valid for the next 10 years); with the added promise of discontinuing (deleting from the main tree) all the others by 2010.

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:I know these changes are awesome

[Paradigm_Complex]

You're correct that the vast majority of improvements in the Linux kernel - when taken by themselves - are unlikely to change anything for any specific end user. These become significant when you add them all together. Odds are slim that any one person will ever use some new hardware support being added in a given kernel update, or some notice some change that ups battery life by couple a percent. However, when you compare the hardware support or battery life of a modern Linux distro to one even a few years old the change is drastic.

There is a huge number of examples I could give, but a recent event really stands out for me. Just a couple days ago a friend was having computer problems (couldn't read a DVD) and wasn't sure if it was a hardware or software issue. A simple check was to boot off Linux off of a USB flash drive and see if it worked (it didn't - ends up the DVD was funky). What's amazing here is that on a completely random system - built as a Windows gaming machine without Linux in mind - a Linux install which has never seen this hardware before performed flawlessly. It booted off of the USB drive faster than the (clean, relatively minimal bloat) XP did from the hard drive, detected and automatically connected to wifi, et al. Everything just worked.

Adding support for a few new webcams or wifi adapters or some new memory management or power stuff isn't going to make a difference. Doing that repeatedly for years, however, and all of a sudden you've got the best hardware support (out of the box anyways) and best performing OS around.

Re:The new graphics

[Antique Geekmeister]

The NVidia blobs remain a big problem. It's not the kernel blob: it's their replacement by setting aside of the OpenGL libraries, used to access the NVidia features. This part of the NVidia process destabilizes every OS that it touches because any updates to those libraries overwrite the NVidia libraries and seriously break your graphical setup.

It's theoretically possible to rewrite the Xorg and Mesa packages to cooperate with this 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. So NVidia remains a dangerously unstable set of tools to install in any sytem that gets any updates otherwise.

Re:For me, it's something else

[Tubal-Cain]

With Linux, you first have to look for those Microsoft web fonts before you call a potential convert to have a look!

That's never been my experiance (I stopped installing MS TrueType fonts when I realized they didn't do anything for me), but there is <whisper>Red Hat's Liberation fonts</whisper>

Re:H Tree Indexing .. Will it speed ls & rm?

[Mandrel]

I hope this fixes the two annoyances I have with Linux:

1. Doing an ls on a directory containing 1000 ext3 files on my quite modern computer takes nearly 10 seconds.

2. Deleting a multi-gig file such as a TV recording locks up the OS so badly that other apps freeze. If mencoder is recording TV it will fail to keep up with the stream. AV sync is lost, ruining the rest of the recording.

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.

Re:The new graphics

[Elektroschock]

Basically the next generation games consoles will be based on Linux + some API.

Re:Not sure about GEM

[MostAwesomeDude]

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.