[Openchrome-devel] MPEG-LA / Re: Todo list

[Thomas Hellström]

Simon Farnsworth wrote:
> Harald Welte wrote:
>   
>> On Thu, Nov 20, 2008 at 03:07:59PM +0100, Xavier Bachelot wrote:
>>
>>     
>>> Depends on the chance we have to see the docs in a relatively short  
>>> timeframe. Only VIA can answer this, and they depend on MPEG-LA will to  
>>> collaborate (or not). Maybe Harald can update us on what's going on  
>>> currently between VIA and MPEG-LA ?
>>>       
>> Unfortunately there is no visible result yet.  Bruce has been trying to get
>> a response from the MPEG-LA directly, while I've been talking with some
>> differnt lawyers.  I hope I can clarify tomorrow if VIA wants to pay for an
>> independent legal study on this subject.
>>
>>     
> An alternative suggestion, if releasing the docs is tricky:
>
> >From what's been released, it looks like the MPEG acceleration engine
> hooks in as another input source to the HQV. Would it be possible to
> define a sensible ABI between the driver and an XvMC blob, such that an
> end user can buy a suitable blob from VIA (paying patent fees when they
> buy the blob)? Openchrome would then need a mechanism to try and load
> this blob.
>
> In the short term, this is nasty - we end up with a supported ABI to let
> a binary blob talk to the hardware. In the long-term, this simplifies
> the job of REing the hardware; instead of having to deal with traces
> that cover the whole VIA driver, we can just look at what goes through
> the defined ABI.
>
> At a first pass, we'd need:
> 1) A way to pass MC interrupts to the binary blob, and to clear them
> when the blob has handled them.
> 2) A way to allocate a single lump of video memory for the binary blob
> to use as it sees fit, including CPU-side mappings if needed.
> 3) Some way for the blob to tell the driver what HQV setup is needed
> (video format, size etc).
> 4) Some way for the driver to only present an XvMC surface type if the
> blob is loaded successfully, and to pass off handling of that surface to
> the blob, including passing on all XvMC requests, and any needed subsets
> of XVideo.
> 5) Methods for the blob to prod the hardware without interfering with
> the rest of Openchrome.
>   
A short comment on this, and in the view of the upcoming completely 
reworked via / (openchrome) DRM interface I'll be posting for review in 
a couple of days. The interface is a complete memory / execution manager 
for VIA, similar to (but IMHO superior to) Intel's GEM.

The API allows the user to create buffers in a selected memory type. 
VRAM, AGP or SYSTEM, and to, in the fastest way possible move contents 
between memory types. Buffers can be mapped, unmapped and synchronized 
with a command stream.

When a sequence of commands is submitted, it's accompanied by a list of 
buffers that are referenced by the command stream state data, and a list 
of "relocations" that are used to patch the command stream if the
buffers have changed location. After command submission a "fence object" 
is returned, and when that object has expired, the hardware is done with 
the command stream. The API is well-defined and BSD-licenced so any 
binary blob can link to that API.

So
1) Many unichromes don't support MC interrupts. Instead the blob will 
wait for / poll for the fence object to expire. If the hardware supports 
interrupts, this is abstracted in DRM.
2) Solved by the buffer allocation API.
3) I suggest any binary blob should only output a surface with a given 
format, dimension and tiling setup. The XvMC lib could then choose how 
to display that surface, either using overlay or texture engines. This 
should be all open source. CX700 does support YUV textures and the HQV 
subpicture blender should support also YUV subpictures to the joy of all 
mythtv users.
4) Again, I think the XvMCPutSurface() part should be fully open-source.
5) The blob must should not talk to hardware directly but through the 
DRM command submission interface, that way synchronization with 3D 
applications and X server will go on unnoticed.

Then again my personal opinion is that this should all be done 
open-source. Perhaps VIA could provide the documented differences 
between the Unichrome Pro and Unichrome Pro II Mpeg engines?

/Thomas



> It also has short-term advantages for VIA - those of us building systems
> on VIA hardware can buy licensed binary blobs (which can be accounted
> for properly to the MPEG-LA) to get full support *now*, while those who
> want properly Free software can help with the RE job, or wait for results.
>
> It also means that if the MPEG-LA change direction, and allow VIA to
> release the details freely, VIA has a sample implementation as well as
> documentation, so that we can see how the hardware is meant to be used.
>