[Mesa-dev] Status update of XvMC on R600

Christian König deathsimple at vodafone.de
Wed Nov 10 06:56:00 PST 2010


Am Montag, den 08.11.2010, 23:08 +0000 schrieb Andy Furniss:
> Looking (for the first time) at iso13818-2 I think the chroma handling 
> would be part of display rather than decode, though the iso does specify 
> how chroma is laid out for fields in 6.1.1.8.
> 
> An article that describes the issues (it actually starts describing the 
> opposite problem of progressive treated as interlaced) is here.
> 
> http://www.hometheaterhifi.com/volume_8_2/dvd-benchmark-special-report-chroma-bug-4-2001.html

Thanks for the link. I understand the problem now, but can't figure out
how to solve it without support for interlaced textures in the gallium
driver. The hardware supports it, but neither gallium nor r600g have an
interface for this support, and I have no intentions to defining one. 

> > Do you have any idea what is causing the remaining block artefacts? I
> > have the strong feeling that it has something to do with ignoring the
> > "motion_vertical_field_selection", but I haven't figured out what
> > exactly is going wrong here.
> 
> Not a clue :-)
> 
> My understanding of mpeg2 is a bit too high level, though I've no excuse 
> not to try and read the detailed spec.

I figured out an usable workaround for motion_vertical_field_selection
and now even field based mc looks 99% correct, only some minor colored
artefacts left in your Pendulum.mpg test video. If you like you could
test some other interlaced videos now.

The down side is that I had to disable every interpolation on the y-axis
to get this working, here we would also need interlaced textures to get
it 100% right.

I also started to profile the performance of the code a bit, as expected
we spend far to much time deciding of how and where to draw something
compared to really drawing something. Up to 50% of the whole cpu time is
spend in gen_block_verts!!!

My todo list now looks something like this:
1. Speed thinks up allot by using a different vertex buffer approach.
2. Implement different colour formats.
3. Maybe implement missing motion types (16x8 and dualprime)
4. Either do iDCT myself or relay on the work of somebody else.
5. Get drunk while watching an XvMC accelerated episode of Simpsons.

Regards,
Christian.



More information about the mesa-dev mailing list