On 16 October 2011 23:05, Stefan Dösinger stefan@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.
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 GLaccepts 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.
On 17 October 2011 19:54, Stefan Dösinger stefan@codeweavers.com wrote:
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.
That's mostly a limitation of the individual blitters. You could certainly make YUY2 and UYVY work with e.g. FBO blits as long as you only blit on block boundaries, and I wouldn't be all that surprised if you have to blit on block boundaries anyway in D3D. YV12 would be harder, but at least d3d10/11 hardware could probably do it.
On Monday 17 October 2011 20:32:43 Henri Verbeet wrote:
That's mostly a limitation of the individual blitters. You could certainly make YUY2 and UYVY work with e.g. FBO blits as long as you only blit on block boundaries, and I wouldn't be all that surprised if you have to blit on block boundaries anyway in D3D.
Only as long as you don't have to filter. When the sizes don't match even point filters break, even if you're reading and writing on block boundaries.
But you could handle that in a fragment shader if the circumstances allow you to calculate the values for the whole block in each shader run. Should be possible for blits at least.
-
Henri Verbeet -
Stefan Dösinger