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

[Stefan Dösinger]

On Monday 17 October 2011 15:38:18 Henri Verbeet wrote:
> 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.
The idea is to mark formats that need glCompressedTexImage2D instead of 
glTexImage2D, so format_texture_info sounds about right.

> > +        /* 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.
The fixup is a separate issue. We can write to formats with fixups just fine if 
the input is in the correct format or we have a shader that can convert TO 
that format. The problem with the blocks is that if one pixel is modified the 
entire block may have to be modified, and we can't do that even with shaders. 
So we can't blit to e.g. YUY2 surfaces even if the input is YUY2 as well and 
the underlying luminance-alpha textures may be fbo attachable.

But following the logic of the compressed flag above, that should also be part 
of the format defintion in format_texture_info[]. When a native GL format is 
used(e.g. GL_APPLE_ycbcr_422 or standard s3tc) the check if the format is FBO 
attachable should be used. I can also move this to a separate patch.

On a somewhat related note, Windows 7 has overlay d3dx9 swapchains. The SDK 
claims that those may support YUV primaries, but according to 
http://www.virtualdub.org/blog/pivot/entry.php?id=282 and a follow-up post HW 
drivers only support RGB formats.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20111017/e28a1f7d/attachment.pgp>