On 10.11.2010 20:31, Christian König wrote: > 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.
Ah so one texture contains data for both fields? I guess in this case without hardware support you'd indeed need to do the linear blend on your own (i.e. calculate 4 coordinates, use point sampling and blend - or maybe instead of point sampling could use fetch4 functionality at least). For 3d graphics though an interlaced texture would be an awkward concept. I guess if more modern hw supports this we could add an interface for it (and hope that hw actually agrees on how it works exactly). Roland _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
