[FFmpeg-devel] [RFC/PATCH 0/8] ffmpeg: add tidsp hwaccel support to avcodec

[Felipe Contreras]

2010/9/8 M?ns Rullg?rd <mans at mansr.com>:
> Felipe Contreras <felipe.contreras at gmail.com> writes:
>> 2010/9/8 M?ns Rullg?rd <mans at mansr.com>:
>>> Felipe Contreras <felipe.contreras at gmail.com> writes:
>>>> 2010/9/8 M?ns Rullg?rd <mans at mansr.com>:
>>>>> Felipe Contreras <felipe.contreras at gmail.com> writes:
>>>>>
>>>>>> ?libavcodec/tidsp_mpeg4.c ? ? ?| ?157 ++++++
>>>>>
>>>>> I dislike the "tidsp" name. ?This patch is for one specific, and
>>>>> mostly obsolete, interface to the DSP. ?It is like calling MPEG4 ASP
>>>>> "the codec".
>>>>
>>>> As I pointed out in the mail:
>>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/staging/tidspbridge
>>>>
>>>> The linux kernel driver is called tidspbridge, you might dislike that
>>>> name, but that's it's name, and it's the only real requirement from
>>>> this code. "bridge" denominates the communication MPU <-> DSP, so the
>>>> only logical name for the whole system is tidsp.
>>>
>>> To any rational person, the name "tidsp" signifies something related
>>> to TI DSPs in general, whereas dspbridge is but one of several methods
>>> of communicating with it.
>>
>> Let me outline the whole system:
>>
>> tidsp (user-space) -> tidspbridge (kernel-space) -> hw -> dsp-bridge
>> (DSP OS) -> dsp socket-node
>
> Yes, so?

So tidspbridge is the only way to access that particular DSP system.

>> In the releases that TI provides for OMAP[1], the binaries are
>> supposed to work *only* with tidspbridge. If you want to use dsp-link,
>> you need different binaries. So the whole system is tied.
>>
>> And tidspbridge, is the *only* method to access the bridge that has
>> any chance of getting into linux upstream.
>
> How can you be so sure of that? ?You do not control what is accepted
> upstream. ?Tony does.

First of all, the acceptance of tidspbridge is out of Tony's hands as
it's not in linux-omap's tree, but it's in 'staging' so it's up to
Greg now.

And second, dsp-link is not on staging, not even on linux-omap, or
linux-davinci, it's nowhere near the scope of any linux maintainer as
there have never been any set of patches submitted for review on any
subsystem. And Jason Kridner told me there are no plans of ever doing
that.

>>>> It is far from obsolete, in fact, it's the *only* interface TI (or
>>>> anyone) is pushing to merge into upstream, and it's the only that has
>>>> reached the "staging" status.
>>>
>>> Most people outside Nokia seem to be using dsplink
>>
>> Who?
>
> Every user of Codec Engine.

Who? Motorola? HTC? Samsung? Nobody in the mobile market would touch
Codec Engine, mainly because of the lack of power management in
dsp-link.

You said "most people" outside Nokia, I wonder who that is.

>> I know at least Motorola and Google use dspbridge. In fact, probably
>> all mobile manufacturers do, because only dspbridge has
>> power-management features while dsp-link doesn't.
>
> Regardless of which features one or the other may have or lack, both
> systems exist. ?Pretending your favourite is the only one is
> presumptuous.

Well, it's the only one in linux.

But let run a though experiment. Let's assume someone submits a patch
to get CodecEngine into FFmpeg, would such code for a dead-end API,
proprietary, not present widespread consumer devices, nor intended to
ever get into linux upstream be accepted? And if so, which name would
you give it? My suggestion would be tice. So, there, no conflict with
tidsp.

However, that's not happening, and might never happen. Why not worry
about the naming "conflict" when (if it ever) happens?

>> dsp-link was developed by the other side of TI; the one that is in
>> charge of Davinci platform, and is not interested in power
>> performance, which explains why there is no power-management support.
>>
>> I know only of the Armstrong distribution that prefers dsplink, mostly
>> because of Koen I guess.
>
> It would help your credibility if you at least took care to get the
> names right. ?The distribution to which I assume you refer has nothing
> to do with astronauts or jazz music.

s/Armstrong/?ngstr?m/ that doesn't change the argument.

>>> which has been further abstracted to form syslink.
>>
>> That's not true; it's completely independent.
>
> For future reference, call this statement #1.
>
>> In fact, if anything, it's based on tidspbridge as the same
>> developers are involved, and it's reusing code like iommu and
>> mailbox, which dsp-link doesn't.
>>
>> In fact, the architecture of syslink has many elements of what Hiroshi
>> Doyu (from Nokia, maintainer of dsp-gateway) pushed for TI get into
>> tidspbridge.
>>
>> ---
>> SysLink is an evolution of both the previous-generation IPC drivers -
>> DSPBridge and DSPLink.
> ? ? ? ? ? ? ? ?^^^^^^^
> Note the contradiction with statement #1 above.

No, you said syslink was abstracted from dsp-link, which is not true.
The text above doesn't say what was "abstracted" from what, just that
syslink is the next generation of IPC drivers.

In fact, dsp-link was a spun off dsp-bridge; by removing features. But
then dsp-bridge evolved quite a lot, and dsp-link stayed the same.

>> It provides a symmetric IPC interface on both the host processor and
>> remote/slave processors.
>> ---
>>
>> For more info:
>> http://www.omapzoom.org/wiki/Syslink_Project
>>
>>> It is the only interface available on OMAP4 and Netra, where it is
>>> used for communication with all the various coprocessors, not only
>>> the DSP.
>>
>> Yes, and the plan is to have it upstream too...
>
> A while ago you insisted that nothing but dspbridge would ever make it
> upstream. ?Which way is it?

Nothing dsp-*.

syslink is not only for DSPs, so if it makes it into FFmpeg, it would
be tisyslink, or something like that, presumably resembling what the
driver is called in linux.

>> along with tidspbridge, and share as much code as possible.
>>
>>>> You can read more in the dsp clarification page[1]. dsp-link is dead;
>>>> [1] http://elinux.org/BeagleBoard/DSP_Clarification
>>>
>>> Nice try, referencing a page you wrote.
>>
>> Take a look at the authors: Mrchapp (TI), Omar rmz (TI, and maintainer
>> of tidspbridge), Nmenon (TI). And you can see on the discussion page
>> also Jkridner (TI, in charge of dsp-link).
>
> You created the page, and most of the changes were made by you. ?This
> means you may not use this page to back up your claims in a discussion.

I am not backing up any claims, I merely suggested you *could* take a
look at that page. You can decide to only look at what other people
wrote, or you can ignore that text and only read the discussion, or
you could just follow the reference links, which where not written by
me.

Or you could just not read it and look for the information yourself,
and you could participate in the wiki by correcting any mistakes you
might find in your independent research (which you wouldn't find).

>>>> TI will not be pushing it upstream or do any reviewing or cleaning up.
>>>
>>> TI plan to push syslink upstream.
>>
>> Which is not related to dsp-link (any more, and probably less, than
>> tidspbridge).
>>
>>>> So for all intends and purposes, tidspbridge is the only interface;
>>>
>>> In your world.
>>
>> Do you want me to CC Jason Krider and Ohad Ben-Cohen to explain to you
>> that syslink is not related to dsp-link, and that dsp-link has no
>> plans to get into upstream at all?
>
> Feel free.
>
>>>> the only one actively maintained, the only one with a shot getting
>>>> upstream,
>>>
>>> On the contrary, syslink is maintained and will be pushed upstream.
>>> How long a process that will be is impossible to predict of course.
>>
>> Unrelated.
>
> So syslink is largely based on parts of dspbridge, yet is unrelated?

syslink is unrelated to this discussion, as it wasn't "abstracted"
from dsp-link.

>>>> and the only one shipped on consumer products, current
>>>
>>> Except the consumer products shipping with dsplink, that is. ?There
>>> are many of those.
>>
>> Unrelated.
>
> Unrelated to what? ?Your claim was that only dspbridge is used in
> shipping products. ?Counterexamples to this claim cannot be simply
> dismissed as unrelated.

I said *consumer* products; e.g. mobile phones.

Feel free to list some of those consumer products that use dsp-link,
but even if they are, I fail to see how it would affect the naming.

>> And there are no OMAP4 products yet.
>
> I am certain there will be some within a year.

Yes, perhaps, but that's not what you said before; I'm just correcting
(not that it matters for this discussion anyway).

>>>> and future.
>>>
>>> Do you have a crystal ball?
>>
>> I work in Nokia.
>
> Does Nokia have a corporate crystal ball? ?Does Nokia decide what
> everybody else is allowed to do?

If Nokia releases one product with dsp-bridge, that counts as a future
consumer product. I didn't meant to say that there would be no
dsp-link consumer products in the future, but as a matter of fact if
there has never been any before, I fail to see why would there be any
later on.


But anyway, lets assume there are products using dsp-link... that
doesn't change the fact that only tidspbridge has been requested for
inclusion in FFmpeg.

What is the problem with tidsp if it doesn't conflict with the plans
of anybody else? There would be no tidsp-link, if anything it would be
tice. And even if for some reason somebody in the future managed to
get something working without CodecEngine (not sure if it's possible),
the name tidsp-link wouldn't conflict, *THEN* we might decide to
change the name of tidsp.

What's the point of discussing about this now?

If you like hypotheticals, how about that in the future tidspbridge
and dspbridge get merged into one driver? Or there is an abstraction
on top? tidspbridge_mpeg4.c wouldn't make sense any more, right?

I don't know what is your goal, but if you are seriously against the
tidsp naming we could start a new thread about the naming of this
code, and my proposed libtidsp library involving people working on
syslink, dsp-link, and tidspbridge. I personally think that's overkill
as we can always rename the code later, if it ever becomes a problem.

-- 
Felipe Contreras