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
Video decoding (even on shaders)
Sounds like there is progress on all these fronts, which is really great.
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?
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.
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.
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.
What other "basic functionality" do you think is missing ?
bridgman how well this dynamic PM (if and when is released) measures against the blob? is it as good?