If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Comment

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.

Comment

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.

Comment

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.

Comment

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.