AMD Releases Open-Source R600/700 3D Code

[DoDoENT]

Just to be clear, we're dealing with finite resources here so the question is not "would it be nice to have MPEG2 accel ?" (even I can answer that one ) it's "should the community work on MPEG2 accel instead of H.264/VC-1 accel ?", ie which should be worked on first ?

I vote for H.264/VC-1 acceleration, although I desperately need power management and faster 3D acceleration on my M56 chip (R500-based Mobility Radeon X1600).

Why don't you create a forum poll, so everyone could give it's own opinion about what should be created first?

[bridgman]

Yes
Yes

Just to be clear, we're dealing with finite resources here so the question is not "would it be nice to have MPEG2 accel ?" (even I can answer that one ) it's "should the community work on MPEG2 accel instead of H.264/VC-1 accel ?", ie which should be worked on first ?

For Rage, Radeon, FireMV-2D: video decoding 1st, then power management, then 3D

For FirePro-3D, FireGL-3D: 3D 1st, then power management, then video decoding

The GPU programming is pretty much the same for the two families, so sequence of implementation would be the same for both. If you were combining the families, what would the sequence be ?

Obviously bridgman needs rambling decode acceleration. That was a half hour that could have been spent on XvMC.

Agreed, but that is another example of a workload which needs specialized hardware and is difficult to parallelize

[Dieter]

bridgman> The only discussion in the thread was about whether it was
bridgman> worth implementing XvMC, which is currently MPEG2-only

Yes

bridgman> whether MPEG2 decoding placed enough load on the system to
bridgman> justify implementing XvMC

Yes

bridgman> I think we all agree that support is meeded for the more demanding
bridgman> formats, particularly H.264. The question *there* is whether that
bridgman> is a higher priority than 3D support, which is what we are working on now.

For Rage, Radeon, FireMV-2D: video decoding 1st, then power management, then 3D

For FirePro-3D, FireGL-3D: 3D 1st, then power management, then video decoding

Have I left out any video chip families?

--------------

smitty3268> I think the FFMPEG devs probably have a better idea about how to
smitty3268> write a codec than AMD does

Wow! Given that ffmpeg core dumps constantly, you must have a *really* low
opinion of AMD.

--------------

bridgman> I just spent another half hour going through [ ... ]
smitty3268> I wouldn't worry about trying to decode that rambling

Obviously bridgman needs rambling decode acceleration. That was
a half hour that could have been spent on XvMC.

[bridgman]

I'm not sure what the current thinking is re: LGPL in xorg drivers but will ask. I guess the best approach would be to make a subset library from the current decoder which only handled the work we did not offload to the GPU then link the binary in - that would also allow multiple drivers to share the same lib.

Interesting idea - thanks !

[Kjella]

So far the second option seems conceptually simpler but more work unless we can borrow the entropy decoding stage from an existing software decoder; that gets tricky because all of the software decoders seem to be GPL or LGPL licensed. You can move code from an MIT-licensed X driver to GPL-licensed software decoder but you can't move from a GPL-licensed SW decoder to an MIT-licensed driver without contacting all the copyright holders and getting their agreement to relicense (which, in practice, rarely seems to happen).

GPL is maybe tricky, but is there a problem with LGPL? You could keep the software decoding stages in their own library and thus it wouldn't affect any other bits. I thought that was the general idea of the LGPL = Library GPL, any changes you make to the library itself must be released but nothing else. Throw in a configuration flag to build with (LGPL dep) or without (MIT) video support and the rest is still free game. You're talking to someone that thinks the X stack being under the MIT license is a contributing reason why it's gotten no futher than it has though, so I'm obviously biased.

[bridgman]

Yep. The tricky part is that if the "most code-sharing-y approach" also requires the most work to be done before showing any useful results, the choice becomes harder.

The slice level approach also means that the driver devs need to maintain the front end (eg entropy decode) code in each driver whereas if we had a slightly lower level API then that code would be maintained once in the player or whatever decoder sat between the player and the driver API.

In other words, there's a practical difference between "sharing a single copy" and "having one set of code which can more or less be used by a bunch of different drivers, each with their own copy, each being maintained independently by different developers and probably drifting in slightly different directions over time". Going with a slice level API is the second case, unfortunately.

[RobbieAB]

Ooops, sorry, I misunderstood what you meant.

I was just thinking that if developers is the big limitation on opensource drivers, anything that gets more use from the code available is a good thing.

[bridgman]

Yes, I think the code would be largely common across any chip using shaders rather than dedicated hardware. I was thinking of "duplicate" in the sense that this code has already been implemented in a number of GPL-licensed software decoders.

[RobbieAB]

2. Standardize on a slice level API recognizing this means we will need to duplicate some existing CPU code for the things we won't be offloading to the chip.

Surely the non-offloaded parts will mostly be the same for multiple chips?

[bridgman]

It would definitely allow code sharing up in the player. I doubt there would be much code to be shared in the driver, assuming the Via driver just stuffs slice level info into the chip as I suspect.

I think in the end we're going to have to pin all the APIs up on a wall and game out what happens if we use each one. We (and the open source devs for other HW) really need to choose between two options :

1. Choose or create an API which matches the functionality we plan to offload to the chip (practically speaking, this means we do *not* offload entropy decode, probably *do* offload IDCT, and definitely offload everything from that point)

2. Standardize on a slice level API recognizing this means we will need to duplicate some existing CPU code for the things we won't be offloading to the chip.

So far the second option seems conceptually simpler but more work unless we can borrow the entropy decoding stage from an existing software decoder; that gets tricky because all of the software decoders seem to be GPL or LGPL licensed. You can move code from an MIT-licensed X driver to GPL-licensed software decoder but you can't move from a GPL-licensed SW decoder to an MIT-licensed driver without contacting all the copyright holders and getting their agreement to relicense (which, in practice, rarely seems to happen).

Putting GPU acceleration into an existing SW decoder (say libavcodec) seems like an obvious option but is tricky because the codec would then need to be come a drm client and follow the DRI protocols; practically speaking you end up having to define an API to get into the X driver stack anyways. This is where Gallium3D could get interesting, assuming that the final implementation automatically brings along the drm/dri integration so the codec could just say "this state, this shader, go".

BTW I confirmed over the weekend that our older IDCT hardware will *not* be able to support H.264 acceleration; looks like H.264 uses a modified IDCT with different coefficients from the ones hard-wired into our older MPEG2 hardware. That's why I said "probably" for offloading IDCT; I think it will work OK on shaders but I haven't actually seen anyone do it yet.