Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prefer OpenGL by default on Windows systems #6503

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

smoogipoo
Copy link
Contributor

@smoogipoo smoogipoo commented Jan 21, 2025

Note that for users that haven't touched the automatic selection, this will now default them to OpenGL. I'm not sure if that's an issue or how to resolve it.

I've been planning to do this for a while now... The D3D buffer management is inefficient and VeldridRenderer.CreateStagingBuffer<>() is a hack to work around it. This breaks on some systems and sometimes creates problems like this (likely). I personally use OpenGL because I notice microstutters and/or inconsistent frame timings on D3D @ 144hz.

I'll probably attempt this again soon, when I get around to implementing SDL_gpu.

@smoogipoo smoogipoo changed the title Prefer OpenGL by default on Windows systems Prefer OpenGL by default on Windows systems Jan 21, 2025
@peppy
Copy link
Member

peppy commented Jan 21, 2025

I dunno about this..

I'm less worried about performance and more about (lesser) compatibility surrounding things like exclusive fullscreen support.

@smoogipoo
Copy link
Contributor Author

smoogipoo commented Jan 22, 2025

We already have issues with exclusive fullscreen support on D3D, see:

I do not see a future where we resolve any of these issues using Veldrid-D3D, and SDL_gpu is not a priority task right now. As for OpenGL, I would expect most exclusive fullscreen compatibility issues to be isolated to Optimus devices, as osu!stable has used it for the last decade mostly without issue otherwise.

I consider all of the following under the "performance" umbrella:

  • "Exclusive" fullscreen support.
  • Microstutters
  • Frame pacing.

As well, I consider potential breakage as a result of o!f doing shoddy things to be an even bigger issue. It's hard to say whether issues like ppy/osu#31619 are of our own making in the end, regardless of whether the driver should have proper validation to not cause BSODs.

@peppy peppy self-requested a review January 23, 2025 14:40
@Susko3
Copy link
Member

Susko3 commented Jan 23, 2025

Those three issues don't seem like big problems for fullscreen on D3D.

The last two discussions also use the volume overlay to show that osu! is not running exclusive, but the visibility of the volume overlay is irrelevant in D3D/FSO. If FSO is working fine, the volume overlay will show, but it will cause a microstutter when it appears and subsequently disappears. That microstutter may be used as a diagnostic to tell if FSO is working.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants