[4/7] wined3d: YUY2 and UYVY are block based

[Henri Verbeet]

On 16 October 2011 23:05, Stefan Dösinger <stefan at codeweavers.com> wrote:
> +    BOOL gl_compressed;
I think the "gl_" prefix is somewhat questionable since the format
being compressed or not is a property of the D3D format, it doesn't
depend on what GL format we use, at least in the way the flag is
currently used. You can change the meaning of the flag to be specific
to the GL format, but then you'd have to set it in the
format_texture_info[] table.

>  static const struct wined3d_format_compression_info format_compression_info[] =
>  {
> -    {WINED3DFMT_DXT1,   4,  4,  8},
> -    {WINED3DFMT_DXT2,   4,  4,  16},
> -    {WINED3DFMT_DXT3,   4,  4,  16},
> -    {WINED3DFMT_DXT4,   4,  4,  16},
> -    {WINED3DFMT_DXT5,   4,  4,  16},
> -    {WINED3DFMT_ATI2N,  4,  4,  16},
> +    {WINED3DFMT_DXT1,   4,  4,  8,  TRUE    },
> +    {WINED3DFMT_DXT2,   4,  4,  16, TRUE    },
> +    {WINED3DFMT_DXT3,   4,  4,  16, TRUE    },
> +    {WINED3DFMT_DXT4,   4,  4,  16, TRUE    },
> +    {WINED3DFMT_DXT5,   4,  4,  16, TRUE    },
> +    {WINED3DFMT_ATI2N,  4,  4,  16, TRUE    },
> +
> +    {WINED3DFMT_YUY2,   2,  1,  4, FALSE    },
> +    {WINED3DFMT_UYVY,   2,  1,  4, FALSE    },
>  };
If you decouple "block-based" and "compressed", it doesn't make sense
anymore to set them in the same table like this. The "compressed"
property should go to either the format_texture_info[] or the
format_base_flags[] table, depending on whether it's considered a
basic property of the format, or specific to the GL format we use for
it.

> +        /* Block-based formats can't be rendered to with FBOs even if GL accepts them
> +         * (e.g. WINED3DFMT_YV12, which is just a GL_ALPHA texture). Even fragment shaders
> +         * can't account for that if a block is partially drawn.
There's no such restriction on the GL side, the internal format just
has to be color-renderable. The reason we can't render directly to
these is because there a fixup associated with the format, but that
has nothing to do with either being FBO-attachable or being
block-based, and applies to e.g. P8 as well.

> +         *
> +         * Furthermore some drivers crash instead of generating an error if we attempt to
> +         * attach s3tc textures to an FBO */
This was an issue with some versions of fglrx, but should be fixed in
current versions.