The Extraordinary DRM Pull Request For Linux 3.11

[halo9en]

Considering the amount of work on 3.10 and 3.11 I hope to see a couple of benchmarks to see how the new kernel compares to the older ones in terms of performance and power usage.

[Delgarde]

Another interesting thing is to see if any extensive code review is done (many eyes on your code, right?) since that is one of the points of FOSS. I'm mainly thinking of the following words of wisdom:

Remember, this is just the pull into the main tree - it's not like someone has just made a single massive commit. The actual changes would have been a large number of small commits, which tends to be much easier to review.

[Ericg]

I think his rants about big merges were only directed at requests made late in the merge window.
Also given the size of the DPM code seems justified, not much you can do about it.

Yeah Linus got mad because people were doing late / big merges after the merge window (and ESPECIALLY after rc3). If the kernel grows in size and its not bloat / things that dont belong in kernel, then Linus doesn't care. Given that all other power management work is done in kernel, its not a big surprise that graphics power management is also in kernel. Linus may make a remark or two about it, but he shouldnt flame Alex or David over this.

[liam]

Does anyone know where the interface to vebox exists?
I've looked through the enablement and testing commits, but I couldn't find any place where userspace could make use of it.
I'm asking b/c the description of vebox makes it sound like hw enabled postprocessing which could be useful as we don't have many of those with the open drivers that I've seen.

[Vim_User]

I think his rants about big merges were only directed at requests made late in the merge window.
Also given the size of the DPM code seems justified, not much you can do about it.

Actually, his rants were about people adding features in the RC state of the kernel, which is for bugfixing, not adding features (this is what the merge window is for).

[PsynoKhi0]

I was just recollecting his previous responses to large merges, like the "What is this crap?!" that he's said before. But perhaps that's just from a testing viewpoint, and not code review. I guess he doesn't really have time to do code reviews of the things he merges.

I think his rants about big merges were only directed at requests made late in the merge window.
Also given the size of the DPM code seems justified, not much you can do about it.

[chithanh]

No? The HD 8000s are only rebrands right now, with the exception of some low end GPU. The next actual graphic cards will be HD 9000s.

Kabini/Temash are new products, not rebrands. Similar for Hainan, which is not low-end. Richland uses VLIW4 for 3D, so is not all-new. The rest of 8000 are Southern Islands chips I think.

[Calinou]

The age of AMD has officially begun.

No? The HD 8000s are only rebrands right now, with the exception of some low end GPU. The next actual graphic cards will be HD 9000s.

[AJenbo]

By the sounds of it .. how do you fit such as big driver with the kernel updates, boot disks and distributions. I would love to see them have a basic core driver that is simple and small to get the computer started and then allows the system to load or swap drivers to enable playing games and advanced features. If it's done right we have the convenience of a small driver that is included everywhere and the user can then load the fancy stuff after the initial boot. Otherwise we are left with big packages and updates even before you can boot.

All 3d stuff is in Mesa so in a way this is already the case. In any cases i can almost assure you that what you are loading with Linux is smaller then what you would load with catalyst (not that that automatically equals faster)

[blackiwid]

It's going to be fun to see Linus' response to this =)

Another interesting thing is to see if any extensive code review is done (many eyes on your code, right?) since that is one of the points of FOSS. I'm mainly thinking of the following words of wisdom:

I wanted to respond to this comment in my last comment.