On Wed, Nov 10, 2010 at 3:56 PM, Christian König <deathsim...@vodafone.de>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. > 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. Marek
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
