On Fri May 15 11:37:21 2026 +0000, Henri Verbeet wrote:
With current upstream Wine, the applications print the "Swapchain views not supported." FIXME with both the GL renderer and the Vulkan renderer, correct? I.e., the basic issue is that the applications end up rendering to the texture's "default" view, which differs from the RTV's format in terms of sRGB.
Yes, both GL and Vulkan log "Swapchain views not supported." FIXMEs. Indeed the textures swapchain "default" view format is UNORM for flip swap_effect which requires RTV with SRGB format but creation is skipped because of the buffer_count \> 1 FIXME constraint.
In the GL case, which blitter ends up being used for swapchain_blit(), and why? I think you're hinting it's the GLSL blitter, but we'd normally expect the FBO blitter (fbo_blitter_blit()) to be used here.
fbo_blitter_blit() is called by swapchain_blit() via raw_blitter_blit() forwarding according to Frostpunk splashscreen which flickers when wined3d_swapchain_gl_rotate() is not skipped: Right, the reason for the "backbuffer_count" check and FIXME is that if there's more than one buffer in the swapchain we need to handle rotating the views created on them as well. That's also the reason there's flickering when rotation isn't disabled; the underlying backbuffer resource essentially ends up being rotated out from under the view. Instead of disabling GL_FRAMEBUFFER_SRGB in swapchain_gl_present(), I think we need to disable it in texture2d_blt_fbo(), somewhat like we're doing in wined3d_context_gl_apply_blit_state():
diff --git a/dlls/wined3d/texture_gl.c b/dlls/wined3d/texture_gl.c index 311ee954c23..68a731f3710 100644 --- a/dlls/wined3d/texture_gl.c +++ b/dlls/wined3d/texture_gl.c @@ -913,6 +913,12 @@ static void texture2d_blt_fbo(struct wined3d_device *device, struct wined3d_cont gl_info->gl_ops.gl.p_glDisable(GL_SCISSOR_TEST); context_invalidate_state(context, STATE_RASTERIZER); + if (gl_info->supported[ARB_FRAMEBUFFER_SRGB]) + { + gl_info->gl_ops.gl.p_glDisable(GL_FRAMEBUFFER_SRGB); + context_invalidate_state(context, STATE_SHADER(WINED3D_SHADER_TYPE_PIXEL)); + } + gl_info->fbo_ops.glBlitFramebuffer(src_rect->left, src_rect->top, src_rect->right, src_rect->bottom, dst_rect->left, dst_rect->top, dst_rect->right, dst_rect->bottom, GL_COLOR_BUFFER_BIT, gl_filter); checkGLcall("glBlitFramebuffer()");I'm a little surprised not having that hasn't been more of an issue before.
wglSwapBuffers has Steam overlay comment which seems related to UI flickering addressed by your staging patch:
``` /* call wglSwapBuffers through the gl table to avoid confusing the Steam overlay */ gl_info->gl_ops.wgl.p_wglSwapBuffers(context_gl->dc); ```
Without wglSwapBuffers the screen never updates and remains the initial clear color which is all white for Frostpunk and all black for others. No, that's a different issue; the "Steam overlay" here refers to the in-game Steam overlay that can be brought up by pressing some key combination. Also, as you've found, you can't just remove the wglSwapBuffers() call; the alternative here would be doing a normal wglSwapBuffers() call, as opposed to going through the function pointer we retrieved in wined3d_adapter_gl_init(). These logs were kept for the patch until considered fully resolved:
``` 0190:fixme:d3d:wined3d_swapchain_init The application requested more than one back buffer, this is not properly supported. Please configure the application to use double buffering (1 back buffer) if possible. 0190:fixme:d3d:wined3d_swapchain_init Unimplemented swap effect 0x3. ```
This MS example has a comment referring to BufferCount = 2 as double buffering: https://learn.microsoft.com/en-us/windows/win32/api/dxgi/ne-dxgi-dxgi_swap_e... The "more than one back buffer" FIXME should have been removed long ago, but never was. The terminology can be a bit confusing at times though; some places consider a swapchain containing three images to have one front buffer and two back buffers, while other places would say the swapchain has three back buffers, one of which is currently the front buffer. The d3d10/dxgi documentation cleaned that up a little by explicitly saying "BufferCount" includes the front buffer, and is simply the total number of images in the swapchain. I'm also reviewing d3d tests for correctness because despite d3d9/tests/visual.c failing, d3d9 games tested so far that use flip swap_effect work with the patch without any issues. However these d3d9 games do not render darker for vulkan even without the patch. You're unlikely to notice a difference with a typical game. Typical games clear and redraw the entire render target / back buffer each frame, at the display's refresh rate. Where swapchain rotation matters is applications doing "damage tracking", only redrawing the parts of the screen that changed, as needed. Typically that's desktop applications, although IIRC there were a couple of games as well. @stefan may remember specific applications. This post might show up twice. I think Gitlab ate my first one, or I posted it elsewhere by accident.
I don't know of any d3d9 games that depend on the flip swap effect. This was mostly a thing in the DirectDraw days. Prince of Persia 3D and Empire Earth 1 are two games that recycle the frontbuffer contents. Pop3d in the main menu and Empire Earth for the in-game HUD - but only with some graphics settings. But even for these two games I don't expect a visual difference between copy and flip. The DirectX 7 SDK has a ddraw sample that differentiates between "odd framebuffer" and "even framebuffer". -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10567#note_139997