On Mon, 11 Nov 2019 at 21:07, Paul Gofman gofmanp@gmail.com wrote:
On 11/11/19 20:12, Henri Verbeet wrote:
Although looking a bit closer at the patch, it still seems a relatively fragile way to fix the issue. It works because texture_upload_data() uses e.g. GL_BGRA/GL_UNSIGNED_INT_8_8_8_8_REV for uploading WINED3DFMT_B8G8R8X8_UNORM data, but the caller isn't supposed to care about that, and a different backend (e.g. Vulkan) could do uploads in a different way.
I think the only reason why this type of fixup is needed is because we have the underlying format for _B8G8R8X8_UNORM which has an explicit alpha. So I suppose if WINED3DFMT_B8G8R8X8_UNORM gets underlying format without alpha, this conversion should not break but rather become redundant, as probably upload conversion should put alpha of 1.0 in this case. Should I maybe move this alpha fixup to wined3d_texture_gl_upload_data()?
It seems more appropriate to do it in wined3d_texture_gl_upload_data(), yeah. Ideally, it would also check for the actual condition we care about. I.e., uploading to a GL internal format with alpha channel, from a D3D format without alpha, but a GL upload format with alpha. We don't track that information about the OpenGL formats though, and it's probably not worth adding just for this, so perhaps checking for uploads from a D3D format without alpha to a D3D format with alpha is close enough.
One more observation is that e.g. WINED3DFMT_B8G8R8X8_UNORM has an equivalent format with alpha, WINED3DFMT_B8G8R8A8_UNORM, which could be used for looking up the masks and byte counts.