This commit fixes a bug that occurs on Windows 8+ when two or more
"Display Capture" sources are active that are configured to capture the
same monitor. Only one display capture would show, while all subsequent
display captures would display nothing.
Closesjp9000/obs-studio#1142
Fixes a bug where loading vertex shaders could cause error messages
about mismatching vertex buffer data to appear because the vertex shader
would try to reload the previously used vertex buffer.
When rebuilding the graphics subsystem, it's possible a shared texture
may no longer be available. In this case, just soft fail and allow the
texture to be rebuilt rather than crash the entire program over it.
Due to an NVIDIA driver bug with the Windows 10 Anniversary Update,
there are an increasingly large number of reports of "Device Removed"
errors and TDRs. When this happens, OBS stops outputting all data
because all graphics functions are failing, and it appears to just
"freeze up" for users.
To temporarily alleviate this issue while waiting for it to be fixed,
the D3D subsystem can be rebuilt when that happens, all assets can be
reloaded to ensure that it can continue functioning (with a minor hiccup
in playback).
To allow rebuilding the entire D3D subsystem, all objects that contain
D3D references must be part of a linked list (with a few exceptions) so
we can quickly traverse them all whenever needed, and all data for those
resources (static resources primarily, such as shaders, textures, index
buffers, vertex buffers) must be stored in RAM so they can be recreated
whenever needed.
Then if D3D reports a "device removed" or "device reset" error, all D3D
references must first be fully released with no stray references; the
linked list must be fully traversed until all references are released.
Then, the linked list must once again be traversed again, and all those
D3D objects must be recreated with the same data and descriptors (which
are now saved in each object). Finally, all states need to be reset.
After that's complete, the device is able to continue functioning almost
as it was before, although the output to recording/stream may get a few
green frames due to texture data being reset.
This will temporarily alleviate the "Device Removed" issue while waiting
for a fix from NVIDIA.
Instead of letting vertex buffer data be freed immediately, store it so
it can be used for rebuilding later. Also, separate the buffer building
to a function.
Unloads all device data and clears all device references. Probably not
necessary, but it's unknown how D3D11 handles this internally so
probably best to be safe.
This allows the ability to separate the blend states of color and alpha.
The default blend state has also changed so that alpha is always added
together to ensure that the destination image always gets an alpha value
that is actually usable after the operation (for render targets).
Old default state:
color source: GS_BLEND_SRCALPHA, color dest: GS_BLEND_INVSRCALPHA
alpha source: GS_BLEND_SRCALPHA, alpha dest: GS_BLEND_INVSRCALPHA
New default state:
color source: GS_BLEND_SRCALPHA, color dest: GS_BLEND_INVSRCALPHA
alpha source: GS_BLEND_ONE, alpha dest: GS_BLEND_ONE
Someone's going to yell at me about this, but fix vertical alignment for
certain member variables in the main header.
For future reference, if you must use vertical alignment, always give it
plenty of space for the type names to grow in case you need to
add/change variables in the future; don't just align to the 'longest'
value, give it an extra 8-16 spaces for potential future variables.
This is done to prevent having to make commits like this in the future
that sort of pollute the history.
When using an enumeration value with a switch, it needs to be filled out
with all possible values to prevent compiler warnings. This warning is
used to prevent the developer from unintentionally forgetting to add new
enum values to any switches the enum is used on later on. Sadly, only
good compilers actually have this warning (mingw).
Microsoft's compiler doesn't seem to care about warning about things
like initializer list ordering. Mingw actually reports on this to
prevent potential confusion about ordering.
This adds support for the windows 8+ output duplicator feature which
allows the efficient capturing of a specific monitor connected to the
currently used device.
I do not want the D3D11 library to depend on a specific compiler
version. This way, I do not have to distribute D3D Compiler libraries
with the program (proprietary binary blobs). Any particular version
works because the API for the D3DCompiler function appears to be the
same; the only things that change are other features and additions
mostly (at least as far as I can tell). Using any version available on
the system should be more than sufficient rather than depending on some
specific D3D compiler version.
If the user doesn't have it, a download of the latest D3D distributables
should be fine, though it should work with the ones that come with
windows 7+ as well.
This Fixes a minor flaw with the API where data had to always be mutable
to be usable by the API.
Functions that do not modify the fundamental underlying data of a
structure should be marked as constant, both for safety and to signify
that the parameter is input only and will not be modified by the
function using it.
Typedef pointers are unsafe. If you do:
typedef struct bla *bla_t;
then you cannot use it as a constant, such as: const bla_t, because
that constant will be to the pointer itself rather than to the
underlying data. I admit this was a fundamental mistake that must
be corrected.
All typedefs that were pointer types will now have their pointers
removed from the type itself, and the pointers will be used when they
are actually used as variables/parameters/returns instead.
This does not break ABI though, which is pretty nice.
NOTE: In texture_setimage, I had to move variables to the top of the
scope because microsoft's C compiler will give the legacy C90 error of:
'illegal use of this type as an expression'.
To sum it up, microsoft's C compiler is still utter garbage.
I had forgotten how constants worked when compiled; constants are
uploaded as constant registers. When constants are used with shaders,
multiple constants are often packed in to a single register when
possible to reduce constant register count.
For example, one 'float' constant and one 'float3' constant will be
packed in to a single register (c0.x for constant 1, c0.yzw for constant
2), but two 'float' constants and one 'float3' constant must inhabit two
registers (c0.xy for constant 1, c1.xyz for constant 2), so it must
start on a new register boundry (every 16 bytes).
I had first instinctively thought it was just a simple case of
alignment like it is on the CPU, but then I realized that it didn't
sound right, so I went back and did some more tests and then ultimately
remembered how constants actually are uploaded.
- Add dummy GL texture support to allow libobs texture references to be
created for GL without
- Add a texture_getobj function to allow the retrieval of the
context-specific object, such as the D3D texture pointer, or the
OpenGL texture object handle.
- Also cleaned up the export stuff. I realized it was all totally
superfluous. Kind of a dumb moment, but nice to clean it up
regardless.
Wouter
jp9000
BtbN