<div class="gmail_quote">On Wed, Nov 10, 2010 at 3:56 PM, Christian König <span dir="ltr"><<a href="mailto:deathsimple@vodafone.de">deathsimple@vodafone.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Am Montag, den 08.11.2010, 23:08 +0000 schrieb Andy Furniss:<br> <div class="im">> Looking (for the first time) at iso13818-2 I think the chroma handling<br> > would be part of display rather than decode, though the iso does specify<br> > how chroma is laid out for fields in 6.1.1.8.<br> ><br> > An article that describes the issues (it actually starts describing the<br> > opposite problem of progressive treated as interlaced) is here.<br> ><br> > <a href="http://www.hometheaterhifi.com/volume_8_2/dvd-benchmark-special-report-chroma-bug-4-2001.html" target="_blank">http://www.hometheaterhifi.com/volume_8_2/dvd-benchmark-special-report-chroma-bug-4-2001.html</a><br> <br> </div>Thanks for the link. I understand the problem now, but can't figure out<br> how to solve it without support for interlaced textures in the gallium<br> driver. The hardware supports it, but neither gallium nor r600g have an<br> interface for this support, and I have no intentions to defining one.<br></blockquote><div><br>Why not? If the hardware supports it, let's use it. I propose adding a new "interlaced" bit in either pipe_sampler_state or pipe_sampler_view.<br> <br>Marek<br></div></div>