This adds gs_enum_adapters and gs_get_adapter_count to the opengl
backend and promotes these to multiplatform graphics functions.
However we need to make an internal device change, device_enum_adapters
must pass in the current device on opengl to ensure that adapter #0 is
the display adapter. We do this to avoid changes to plugins already
checking against obs_video_info.adapter which is always 0 and expected
to be the device OBS was initialized on.
The actual implementation reports the dri render node (or /Software).
This allows plugins to query non-video features of the adapters like
VA-API/NVENC/etc or other cross device functionality. `/Software` is
chosen to avoid opening random files in the current directory if its
passed along as a file path like the regular dri render nodes.
MSVC noticed inline is not allowed, and new/delete replacments also
don't belong in a header file. We're also just leaning on
__STDCPP_DEFAULT_NEW_ALIGNMENT__ being 16 for MSVC x64 now.
A few reports came in of cache files with the correct size but full of
null bytes, presumably from a system crash and an SSD lying about buffer
flushes. This commit adds a checksum at the end of the compiled bytecode
so we don't try to use invalid data.
Co-Authored-By: derrod <dennis@obsproject.com>
NVIDIA GPUs in multi-GPU setups cannot safely perform a fast clear until
driver 527.37. Implement a check against the Vendor ID and driver
version of the adapter to determine if the adapter can safely perform a
fast clear.
Co-authored-by: derrod <dennis@obsproject.com>
DXGI_ADAPTER_DESC's DedicatedVideoMemory and SharedSystemMemory are
unsigned long long int, but we were logging them as unsigned int. For
GPUs with memory values higher than 4294967295, the logged value would
roll over. Use %PRIu64 (%llu on VS2022) instead of %u in the log call.
Because Intel has wonderful code which forces it to run on the iGPU if
there are both an Intel iGPU and an Intel dGPU on the same system, the
adapter index OBS is set to internally will no longer be valid, thus if
anyone calls `obs_get_video_info()` to try to find out what adapter
index OBS is running on, it will be invalid on those computers.
Wonderful.
So, basically, this code here just fixe it so if you want to call
`obs_get_video_info()`, it'll actually have a valid adapter index now,
that way we can reference the adapter index when determining what GPU
we're actually running on without having to like, do anything super
complicated and silly like comparing adapter GUIDs just to figure out
what adapter OBS is actually runing on. I don't want the code to be a
mess anymore.
(I like how in any other situation on the face of the planet, there's no
need to force OBS to run on an integrated adapter. *Normally* OBS
*should* run on the dedicated adapter, that way it can actually capture
games properly. You can probably guess as to why they're forcing it to
run on the integrated adapter rather than the dedicated adapter. But you
know what? Whatever. I don't really care anymore I guess. Just...
whatever. Here we are I guess. Also I was in a bad mood while writing
this just as a disclaimer.)
(I hate that this commit exist. I hate that the commit c83eaaa51c exists
even more.)
Some users stream projectors, so don't let them tear. Use the waitable
object to check the flip queue, and only flip if there's space.
Metal and Vulkan can probably perform similar flip throttling once OBS
starts using them.
We'll need flip model swap chains in the future for HDR, and we don't
want to limit HDR to WIndows 11. The new test is the existence of
IDXGIFactory5, which was introduced in Windows 10 1607. This should be
enough for HDR, for which we use APIs in Windows 10 1703.
Hopefully having SetMaximumFrameLatency(40) this time will make enough
of a difference to not bring back reports of degraded performance when
using flip model on Windows 10.
