RadeonSI Gallium3D Gets New State Handling

[bridgman]

Can you give some insight on why PM in particular is so hairy? Surely there's not some company out there licensing power management algorithms?

It's not so much that it's particularly hairy, this is what pretty much all releases of new IP areas are like.

[pingufunkybeat]

Thank you for keeping us updated, I am really excited about this. It's one of those killer features we are missing:

Efficient dynamic PM
OpenCL
GL compliance
Video decoding (even on shaders)
Performance

Sounds like there is progress on all these fronts, which is really great.

[Figueiredo]

I'm very curious about AMD's strategy in regard to the open drivers. In my view they would become usable for laptop users (specially APUs) once PM and video accelaration are implemented and the (re)clock bug has been fixed, in this order. It is not clear to me AMD's view of this. Seems like most of the times the os team guys are all throwing code ate the "review board" to see if something gets out. If bridgman can give any insight I would apreciate.

If the review step is actually the bottleneck for getting things done, is someone trying to speedup this process somehow?

[bridgman]

I'm very curious about AMD's strategy in regard to the open drivers. In my view they would become usable for laptop users (specially APUs) once PM and video accelaration are implemented and the (re)clock bug has been fixed, in this order.

Not sure which reclock bug you're talking about (is there a bugzilla # ?) but I imagine it's related to PM somehow so we're probably just talking about PM and video decode.

It is not clear to me AMD's view of this. Seems like most of the times the os team guys are all throwing code ate the "review board" to see if something gets out. If bridgman can give any insight I would apreciate.

We try to plan the development and IP release activities so that community developers and AMD developers can work in parallel, ie we focus on getting enough initial code and programming info out to let community developers continue while we go work on the next chunk of hardware.

We knew that video decode acceleration via UVD would be hard and we tried to make it very clear from day one that people should *not* assume there would be open source video decode accel support. PM was a different story though... it was pretty simple at the time we made plans for the open source effort but changed radically over the first couple of years.

Alex pushed out basic PM code a couple of years ago (2009 maybe ?) and I expected that community developers would continue to improve PM using information we had released in the same way they did on 3D and other areas... based on feedback from various devs it looks like I called that one wrong in a couple of ways.

First issue was that working on PM code turns out to be regarded as a lot less fun than working on pretty much anything else, second issue was that the devs who *were* willing to work on PM also had access to some of our longer range plans under NDA and didn't want to invest in the current code since there was a non-trivial chance that future code/info releases from AMD might obsolete their work. Makes sense, unfortunately.

As a result, the current PM code hasn't been improved and everyone is waiting for our "future plans" to happen instead, all for perfectly good reasons. D'oh !!

We have bumped the priority of the next round of PM work, but that doesn't make vacations go away and it doesn't do anything for the uncertainty about what we will eventually be able to release.

If the review step is actually the bottleneck for getting things done, is someone trying to speedup this process somehow?

It's not really the "bottleneck", more "the last step in the process" which is the most highly visible. In general we don't talk about internal activities until something is ready to release but that's not a great solution either... problem is that if we *do* talk early it needs to be about things which are fairly late in the process and that is going to focus attention on the back-end activities.

We try to sequence development work around the relative complexity of releasing the associated IP, and look for ways to break ugly IP areas into a series of smaller releases to get useful chunks of information into developer hands earlier (as we did with PM). It may look like things are slowing down but I don't think they are -- it's just that the easier stuff is already out and now we're working on the harder stuff.

[Figueiredo]

Thanks very much to the reply. It is really great that the developers can give us this much info (as much as possible, anyway).

Obviously the more info you give us about the process the more we will want to know about and I understand that the a things you simply cannot comment at this time. I think all this anxiety is probably not only because we don't know when to expect something to show up, but if its ever going to show up at all. If chips as old as r600 still lack so much basic functionallity 5 years after being released, it is not very encoraging from our side that the open source driver will ever cach up, even if for future chips which might be more open source friendly.

I don't expect to ever see a open source UVD implementation, but I'd be certainly more confident if there was some expectation that I'll ever be able to decode HD video on my E-350 machine using some form of gpu accelaration. Right now, neither catalyst nor r600g are able to do that. I know that there is some hack to wrap xvba in vaapi and theoretically xbmc supports xvba, but it always requires so much hacking that it is simply easier to install windows.

Anyway, I wish success for you and your team. You really are working on something great, it is just a shame you are so few.

[bridgman]

If chips as old as r600 still lack so much basic functionallity 5 years after being released, it is not very encoraging from our side that the open source driver will ever cach up, even if for future chips which might be more open source friendly.

IMO you may be generalizing too much here... the only missing things one could consider as "basic functionality" are dynamic PM and UVD support. Dynamic PM was an exception case where we guessed wrong about community involvement (and have tweaked our plans accordingly), while UVD was identified up front as a carve-out.

What other "basic functionality" do you think is missing ?

[89c51]

bridgman how well this dynamic PM (if and when is released) measures against the blob? is it as good?

[bridgman]

bridgman how well this dynamic PM (if and when is released) measures against the blob? is it as good?

No idea. None of us run the binary driver on Linux

We're aiming for "substantial improvement" relative to current state.

[curaga]

No idea. None of us run the binary driver on Linux

Heh, that's what Michael is here for, so nobody else has to compromise their morals