2013: A Good Year For Open-Source AMD?

[bridgman]

So I stand by my words: "you can forget about H.264 support (whether it be UVD or shader approach) in the open drivers for the coming years."

I guess... if you're just saying "I am knowingly taking the most pessimistic range of interpretations" then that's fair, and I have been very clear that people making buying decisions should not assume UVD support in the open driver yet.

On the other hand, pretty much everything with the open drivers so far has faced similar challenges and an awful lot of things *have* happened, so I think saying unequivocally that something is *not* going to happen is just as misleading.

My main objection with your previous post was not those words, however, but the (incorrect) statement that Christian had only done work on video decode before starting at AMD and that we had stopped him from working on that and shifted him to other tasks, along with the other conclusions you based on that statement.

[AnonymousCoward]

I guess... if you're just saying "I am knowingly taking the most pessimistic range of interpretations" then that's fair, and I have been very clear that people making buying decisions should not assume UVD support in the open driver yet.

On the other hand, pretty much everything with the open drivers so far has faced similar challenges and an awful lot of things *have* happened, so I think saying unequivocally that something is *not* going to happen is just as misleading.

But that's different. AMD has always been very secretive about UVD. How long did it take before we could use UVD with closed source Catalyst? Years no?

My main objection with your previous post was not those words, however, but the (incorrect) statement that Christian had only done work on video decode before starting at AMD and that we had stopped him from working on that and shifted him to other tasks, along with the other conclusions you based on that statement.

Is he working on video decode right now? Full time? I don't think so. Of course you're in a better position to know than me. But from what I can see from the internets it seems he's working on compute support?

[smitty3268]

The opposite of "nothing" is not "everything";

Well, actually, it is. If anything in his post was correct, then saying "nothing" was correct was false.

But I was being a little tongue-in-cheek to begin with.

OK, short version -- as posted here a couple of times before, shader work turned out not as well as hoped because the parts we could accelerate on GPU had already been implemented pretty efficiently on x86 SIMD instructions, so Christian switched to working on UVD.

I'm a little surprised you didn't see this coming ahead of time. Years and years ago AMD put out marketing info that the bits of h.264 that couldn't be accelerated on shaders were good for 50% of decoding time. It was part of the reason they created UVD in the first place.

[TobiSGD]

Wait I don't get it, may be this can be explained to me. Actually you are saying that you bind the power of this developer to work on features that possibly will never be released due to license issues? Wouldn't it make much more sense to let this developer work on things that still have known issues/are unsupported, but can be released? And may be let him work on what he is doing now when your legal department has done its job to find out if you can release that work?
I mean, you yourself stated that manpower is not a resource that you have a vast amount of, so why are you wasting it?

[archibald]

may be let him work on what he is doing now when your legal department has done its job to find out if you can release that work?
I mean, you yourself stated that manpower is not a resource that you have a vast amount of, so why are you wasting it?

The legal guys look at his code and decide whether it can be released - if nobody works on UVD then they will never have anything to review, so nothing could ever be released.

Another reason to work on it is that people are asking for it.

[bridgman]

Correct. Typically we also need to modify the code a few times before it can be released, so no code = no progress towards release. In some cases we are able to get a yes/no before doing any work, but for more complex blocks that is usually not the case.

Note that the review is really more by technical leads across the company than by legal -- the model is more like "legal figures out what acceptable risk is and establishes guidelines for the project, technical leads figure out what the specific risks are, then if B < A we release". It's not really that simple but you get the idea.

In the specific case of UVD, what we said (and did) was postpone any significant work until we had mostly caught up with the introduction of new hardware and had initial support in place for the APU parts, ie for the first few years of the project. At that point we felt it was worth diverting some developer time to work on decode acceleration, with the knowledge that we might not be able to release the results of that work, because video decode was considered so important by our users.

There are good arguments for and against this, obviously, depending on where video decode sits on your personal list of priorities. I suspect that roughly half our users felt we started too late and the other half felt we started too early.