Mesa 7.5 RC3 Brings Build, Bug Fixes

[MostAwesomeDude]

MAD, I miss you in #zen-sources, you weren't there since ages.

The features I needed in zen-sources have gone upstream. I don't really need it anymore. :3

Maybe I'll /join again.

[Louise]

As soon as KMS+GEM works on those cards, I'll add radeon softpipe support for them, which means that DRI2 SW rendering will work. After that, it'll be the long, slow road of porting r6xx-rewrite into the Gallium architecture.

Last time we heard from Bridgman, I think he said that AMD now is working on writing the power management specs and example code.

We haven't heard from the Novell developers in a long ting, and the last we heard from Red Hat was their work in KMS being their main interest.

Do you have an update where things are going, and who is working on what?

[bridgman]

Alex pushed initial power management code (engine clock, clock gating, pcie lanes) a while back, then Yang added engine clock adjust to radeonhd. Matthias just published a patch to add clock gating to 5xx/rs6xx, and Alex wrote up a summary of the power management info & options in his blog :

http://www.botchco.com/agd5f/?p=45

In terms of who's doing what, the transition to KMS is still the main focus, with glisse working on merging in new TTM code and a number of devs working on getting the radeon-rewrite branch of mesa ready to merge into master. We're doing most of the 6xx-7xx 3d work, and again there the big effort over the last couple of months was moving across to the radeon-rewrite code base as well. MostAwesomeDude is still making progress on the 3xx-5xx Gallium3D port, and at least one other dev is contributing there as well.

[Louise]

Alex pushed initial power management code (engine clock, clock gating, pcie lanes) a while back, then Yang added engine clock adjust to radeonhd. Matthias just published a patch to add clock gating to 5xx/rs6xx, and Alex wrote up a summary of the power management info & options in his blog :

http://www.botchco.com/agd5f/?p=45

In terms of who's doing what, the transition to KMS is still the main focus, with glisse working on merging in new TTM code and a number of devs working on getting the radeon-rewrite branch of mesa ready to merge into master. We're doing most of the 6xx-7xx 3d work, and again there the big effort over the last couple of months was moving across to the radeon-rewrite code base as well. MostAwesomeDude is still making progress on the 3xx-5xx Gallium3D port, and at least one other dev is contributing there as well.

Cool break down. It is always interesting to hear where things are going

I remember Linus not being too keen on the KMS merge to the kernel. Have that been sorted out, or are there potential show stoppers there?

Btw. I have read the Anandtech review of the much awaited Athlon II X2 250, and according to Wikipedia, it hit the channel June 2nd.

I assume June 2nd is for the US. Do you have an estimate how long it takes for a new CPU to be available world wide, as I don't live in the US?

[Yfrwlf]

After that, it'll be the long, slow road of porting r6xx-rewrite into the Gallium architecture.

I thought Gallium3D was supposed to greatly simplify the writing of drivers. Or is it simpler, but still not incredibly easy?

[NeoBrain]

I thought Gallium3D was supposed to greatly simplify the writing of drivers. Or is it simpler, but still not incredibly easy?

It's not neccessarily simpler nor easier, but the code will be a lot cleaner (easier to debug and stuff) and once you've got it working, Gallium3D provides access to the whole range of state trackers (e.g. OpenGL 1-3, video decoding acceleration, OpenCL, network debugging, etc).

[Yfrwlf]

It's not neccessarily simpler nor easier, but the code will be a lot cleaner (easier to debug and stuff) and once you've got it working, Gallium3D provides access to the whole range of state trackers (e.g. OpenGL 1-3, video decoding acceleration, OpenCL, network debugging, etc).

So then it *is* simpler if you want things like OGL and whatnot...if it didn't make it simpler to write and manage "fully-featured" drivers, then there'd be utterly no point in Gallium3D.

I think I could condense down the entire point of software into that, actually. Better software has more features as well as making it easier to create those and future features and create content in general. (ok and of course tack on the usual less buggy, performs better, etc, but I lumped those into "features")

Look forward to the day when you can easily snap in a few things to create the program you want, or better yet just think about it. It's coming, but needs to hurry the $!@# up.

[bridgman]

I thought Gallium3D was supposed to greatly simplify the writing of drivers. Or is it simpler, but still not incredibly easy?

Yeah, I think that sums it up pretty well. Using Gallium rather than the classic Mesa hardware driver model seems to take the task from "mind-numbingly difficult" to "a lot of hard work", which of course is a significant improvement.

[Yfrwlf]

Yeah, I think that sums it up pretty well. Using Gallium rather than the classic Mesa hardware driver model seems to take the task from "mind-numbingly difficult" to "a lot of hard work", which of course is a significant improvement.

OK, whew, sanity check passed. ^^

Too bad there's not some way of making it excruciatingly easy!

[bridgman]

There is... we could go back to making GPUs the way we did 10 years ago, where the GPU registers more or less matched the OpenGL state variables