DRM Patches For Linux 2.6.27 Kernel

[phoronix]

Phoronix: DRM Patches For Linux 2.6.27 Kernel

The Linux 2.6.26 kernel had featured updated Intel and ATI DRM that added the needed kernel support for the ATI R500 and Intel GMA 4500 3D support. While the merge window for the Linux 2.6.27 kernel has already closed, we will hopefully see a few more Direct Rendering Manager (DRM) patches...

http://www.phoronix.com/vr.php?view=NjY3MQ

[Louise]

Is DRM specific to each card GPU, or does the DRM not need to be updated for future GPU?

Another way to ask the same =) Does the DRM contain GPU specific code?

[bridgman]

Yes, a good chunk of the DRM is GPU-specific and the proportion of GPU-specific code is growing as memory management and kernel modesetting are added. Dave Airlie recently re-organized the DRM source code to make it more like a typical kernel driver and to make the GPU-specific portions of the code easier to find and manage.

If you think of DRM as "the kernel driver for graphics" that will give you a pretty good understanding -- with the added complication that most of the same DRM code is also used with FreeBSD, Solaris and other OSes.

[Louise]

So that was what his huge patch was about =)

Does this mean, that AMD will spilt future specifications up in a DRM spec, 2D, 3D, and ISA spec?

Or can it not be divided like that?

Thanks for the DRM ~ "the kernel driver for graphics" =)

[Michael]

Linus Torvalds to David Airlie:

Quite frankly, I'm not going to take this.

None of what you describe sounds like regressions, and this is just TOO F*CKING LATE to take big changes like this, to a fragile subsystem that has historically easily introduced new regressions.

Can you please make a branch with ONLY REGRESSIONS, or fixes for major problems that don't introduce several thousand lines of new code?

Because you seem to be constantly unable to understand what "merge window" means. And I'm not going to take this kind of crap.

Linus

[misiu_mp]

Linus Torvalds to David Airlie:

Hmm, I ve seen Linus being jumpy like that before. Maybe he should do some anger managment or sing "Im so pretty" when the steam goes up.

[Louise]

or maybe do like this guy? =)

http://www.youtube.com/watch?v=V5zvvDtAfx0

What did Airlie do? Will he still commit new patches?

[sundown]

Linus scares me :'(

[ethana2]

Scary and a little mean sounding maybe, but he /is/ right.

The thing is, I think the DRM folks wanted to get their code into the next volley of major distros....

[yoshi314]

linus has a point, but sometimes (like this one) he is way too aggressive with expressing his opinion.

i'd be pissed if i were airlied, but i would also have to agree with linus. new stuff comes in merge window, after it's closed - it's bugfixing only.

[crumja]

Yeah. I'm supporting Linus on this. David has done late merges like this not a few times.

[TechMage89]

Linus really needs to be nicer to the poor DRM devs. Sure, I can understand why he rejected the patch, but he could have been more polite about it.

[BlueKoala]

Linus Torvalds to David Airlie:

Epic fail.

[BlueKoala]

Linus really needs to be nicer to the poor DRM devs. Sure, I can understand why he rejected the patch, but he could have been more polite about it.

Sometimes polite doesn't have enough emphasis to make someone understand.

[bridgman]

So that was what his huge patch was about =)

Does this mean, that AMD will spilt future specifications up in a DRM spec, 2D, 3D, and ISA spec? Or can it not be divided like that?

The natural split from a developer's POV would be something like :

- Modesetting (basic memory management, display controllers)

- Acceleration (everything else)

This is pretty much what we ended up doing for 5xx and 6xx, although :

- the modesetting docs (released in 07) were missing some memory controller bits which we supplied separately to the devs

- 6xx acceleration was split in two parts in order to take advantage of the R600 shader ISA doc which had been prepared by our Stream Computing folks

Going forward we will probably continue to "play it by ear" a bit -- for example the 7xx is close enough to 6xx that we will probably just create a single "delta document" covering all of the differences between 6xx and 7xx rather than splitting into modesetting vs isa vs acceleration.

We looked at organizing the documentation around the driver components, however in the current X/DRI architecture there is a fair amount of duplication between the X driver and the DRM driver. That duplication will continue (and maybe even grow for a while) but hopefully will disappear once kernel modesetting becomes the norm. Once that happens the X/DRI graphics stack will be more like the rest of Linux, with kernel drivers doing all the register-banging and usermode drivers passing command buffers down through DRM to implement acceleration APIs.

[sundown]

Yeah, but he is kind of accusing people that they don't know what a "merge window" is, instead of tutoring them in a true mentor style :p

[bridgman]

I think some of this is just about making the rules more clear. There have been previous comments saying "only bug fixes after the merge window" but all of Dave's changes *were* bugfixes. Linus' email makes it sound as if the real expectation is "only bug fixes for *regressions* after the merge window", which is a big difference and which is probably *too* strict for effective development.

It may just be that Dave's changes came in *after* rc4 so Linus is enforcing the "regressions only" rule because the next milestone is hopefully "final" and there is no room for further fixes. If so, that means the rule is really "only bugfixes for regressions after rc4", which would be totally reasonable.

[deanjo]

Yeah, but he is kind of accusing people that they don't know what a "merge window" is, instead of tutoring them in a true mentor style :p


They obviously DON'T understand what a "merge window" is. I have to stand by Linus on this one. If people don't follow the deadlines your QC is at risk.

[Saist]

I read the thread and the response to Linus by Mr. Airlie:

Your reply now serves as place to point people at when they ask why Red Hat/Fedora ships features that they can't get for 1-6 months, and I'm fine with that.

Dave.

I think... Mr. Airlie is wrong about his statement. The fact is, the patches he's submitting are available. Anybody can take those patches and merge them into their own kernels.

There should not be anybody then asking why Red Hat / Fedora ships with code that they can't ship, unless the code is proprietary. If the changes to the code are that dramatic and useful, vendors will simply include the code themselves, rather than waiting on an official kernel version.

Then if the vendor won't include the code, there's nothing to stop the end user themselves from including the code.

So, I'm not sure what Mr. Airlie is fine with. On the surface, it sounds like he's fine with proprietary code and keeping it locked away... I just can't imagine that being his intent.

My guess is that Mr. Airlie didn't actually think about what he wrote back, instead trying to be cute and make Linus look bad while promoting his own product.

[jeffro-tull]

Maybe I'm giving him the benefit of the doubt, but I'm siding with Linus.

Why the qualification? Because if he asked nicely we wouldn't here about it. At all. Not just his response, but the whole thing. He probably did. Maybe not to this particular dev, maybe not on this particular issue, maybe not for this particular kernel. But I can guarantee that he's asked nicely in a similar situation before.

Sometimes you gotta lay down the law.

[mityukov]

Scary and a little mean sounding maybe, but he /is/ right.

The thing is, I think the DRM folks wanted to get their code into the next volley of major distros....

Whether he right or he doesn't, in this decision, he should be more polite, IMO..

Graphic cards manufacturers have comparable little profit from Linux owners share of market. And what ATI or Intel do currently for X, can be called "welfare" in some kind.

I believe, that commiters really wanted to get some things to be fixed/updated ASAP.

Maybe, they didn't understand "Merge window" clearly enough. But I still don't like what Linus said..

[ivanovic]

Whether he right or he doesn't, in this decision, he should be more polite, IMO..

Graphic cards manufacturers have comparable little profit from Linux owners share of market. And what ATI or Intel do currently for X, can be called "welfare" in some kind.

I believe, that commiters really wanted to get some things to be fixed/updated ASAP.

Maybe, they didn't understand "Merge window" clearly enough. But I still don't like what Linus said..

IMO you are partly correct with what you say. Still it is not only the world of graphic cards manufacturers. Yes, improvements in the DRM part of the kernel are a great thing since they speed things up. But they are also likely to cause problems and regressions since it is a big area of code that is critical for stability. If the merge window was really adhered it would be possible to maybe get a new kernel out in something like 6 weeks after the first rc. This is only occurring bugs and regressions need to be fixed and it is unlikely that many new ones are introduced by late merges.

Yes, commiters want to see their work in the kernel ASAP. Still there is a reason for this merge window to speed up the general releases of new kernels. This is: many contributors are able to get their code into the kernel in this small merge window, why not all? If you look at the last three kernel releases you will see that the release of the final version was delayed due to regressions in late merges. Basically all of the rest was working nicely, there were just extra problems introduced by later merges. Without those the kernel would probably have been out at least two weeks, maybe even four weeks earlier.

Adhering the rules will help and reward other contributors to the kernel by a faster release cycle. Since there are not only graphic card manufacturers working on the kernel, but eg manufacturers of embedded systems and the like. The kernel is not only about 3D graphics and their acceleration but also about all the other stuff the OS should offer like drivers for your mass storage devices.

[Vighy]

I read the thread and the response to Linus by Mr. Airlie:



I think... Mr. Airlie is wrong about his statement. The fact is, the patches he's submitting are available. Anybody can take those patches and merge them into their own kernels.

There should not be anybody then asking why Red Hat / Fedora ships with code that they can't ship, unless the code is proprietary. If the changes to the code are that dramatic and useful, vendors will simply include the code themselves, rather than waiting on an official kernel version.

Then if the vendor won't include the code, there's nothing to stop the end user themselves from including the code.

So, I'm not sure what Mr. Airlie is fine with. On the surface, it sounds like he's fine with proprietary code and keeping it locked away... I just can't imagine that being his intent.

My guess is that Mr. Airlie didn't actually think about what he wrote back, instead trying to be cute and make Linus look bad while promoting his own product.

You maybe didn't get the point: Airlie didn't talk about proprietary code.

He said that most of the distros do not add those patches, and stay with a stock mesa/DRM from the kernel snapshot; and since kernel development doesn't take little time to release new versions, in Fedora you can find features that in other distros you can't see for months.

This means that the answer of linus will be, for Dave, the sentence that explains why this happens.

I think this is more coherent with what Dave said...

[bulletxt]

lol ive always loved torvalds replies :) and i also love the fact that im writing this post from my psp :D

[TechMage89]

Let me make the point that making a polite refusal is usually much more effective than cursing and insulting the person you are refusing.

Linus's answer may be blunt, but I don't think it does a very good job of making his point.

[yoshi314]

i also love the fact that im writing this post from my pspand your point is...? what's so special on posting from psp?

like linus himself once said - "i think of richard stallman as of a great philosopher. and he thinks of me as a mere engineer".

engineers don't have good interpersonal skills :]

[energyman]

Hmm, I ve seen Linus being jumpy like that before. Maybe he should do some anger managment or sing "Im so pretty" when the steam goes up.

nope, just last week he was angry about the networking crew to send a mega-patch and told them that so late in rc-cycle big patches (outside of regression fixes) are inacceptable. And then David sends a mega-patch too.

This is normal Linus-behaviour. And he is right.

[RealNC]

Usual Linus; arrogant and offensive. I never liked him and it gets worse as time passes.

[energyman]

Usual Linus; arrogant and offensive. I never liked him and it gets worse as time passes.

then you haven't really read his mails.

Or the whole history. Just last week he lectured people in a lot of mails about patches. When, what. The first one was harsh, the others friendly. And this week David sends a mega-patch.
How would you act in Linus' place?

Yes, he often sends harsh mails - but after that he also sends nice helpfull mails in which he explains how to do it better.

He has to manage a very big project. A lot of stuff has been explained a lot of times. People like David A. or Dave J. should know better than to send big patches at rc4. Harsh mails are normal.

If you really want to read a bashing, look for Al Viro.