[Mesa-dev] Status update of XvMC on R600

[Christian König]

Am Mittwoch, den 10.11.2010, 17:24 +0100 schrieb Roland Scheidegger:
> On 10.11.2010 15:56, Christian König wrote:
> > 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. 
> I'm curious here, what the heck exactly is an interlaced texture? What
> does the hw do with this?
It differs in the interpolation of samples. I will try to explain what I
need for video decoding with an little example, lets say we have a 4x4
texture:
A C B D
E F G H
I J K L
M N O P

And lets also say that the texture coordinates are in the range 0..3
(not normalized), so if you fetch the sample at coordinate (0,0) you get
"A", a fetch at (1, 0) gets "B", a fetch at (0,1) gets "E", and so on.

But if you fetch a sample from coordinate (0.5, 0) you get a linear
interpolation of "A" and "B" (depending on the sampler mode used).

The tricky part comes when you fetch a sample from coordinate (0, 0.5),
with a normal texture you would get a linear interpolation of "A" and
"E", a fetch from (0, 1.5) would result in an interpolation from "E" and
"I".

Now with an interlaced texture if we fetch from (0, 0.5) we get an
interpolation of "A" and "I", and when we fetch from (0, 1.5) we get an
interpolation of "E" and "M", and so on.

It even gets more tricky since the decision of what to use is made on a
block by block basis, so switching from one mode to the other must be
fast, so we just can't copy around the lines or do something like this.

I think it will probably end up in using more than on texture fetch in
the fragment shader and calculate the linear interpolation on our own.

If you have another god idea just let me know.

Christian.