Question / Help Any changes with an upgraded video card?
- Thread starter Murf
- Start date
Murf
Member
Hmm I see that now, well that really sucks as the only game I stream is OpenGL. Nothing can be done except use the OBSmp when the windows HF is out that fixes the opengl issues I guess?
Murf
Member
but I don't have the same issue with another streaming program. i thought you meant it is soley an r9 issue and not an issue with how obs works with r9 cards
Murf
Member
Odd that it doesn't happen with my other streaming program. Same game. Maybe a diff encoder? using h264.amdvce with that other program as well though.
Murf
Member
Sorry I must have misundertood, or misspoke my apologies
I am using x264 in obs. The issues I am having with streaming my opengl game does not occur with another streaming program. I am using a h264.amdvce encoder on that other program.
Is the obs team working on a fix for these r9 radeon issues?
I am using x264 in obs. The issues I am having with streaming my opengl game does not occur with another streaming program. I am using a h264.amdvce encoder on that other program.
Is the obs team working on a fix for these r9 radeon issues?
Murf
Member
Playclaw, not showing any of the 'dots' and such.
That specific series of AMD adapters has a hardware or driver bug that makes the default capture method for game capture fail to function properly with OpenGL games.
Have you tried using the "Multi-adapter compatibility" option in multiplatform's game capture? It will work with OpenGL games just fine, although sadly it'll have reduced performance. This whole situation is almost certainly due to drivers/hardware specific to this hardware in conjunction with the default capture technique.
As the main dev of the program, let me explain why it's most likely not the program's fault. Before I begin, I realize that I sound like I'm defending the program here because I wrote it, but I've investigated this, and I always tend to assume my fault first before investigating just out of caution. So let me go in to the explanation of why you're not getting this with many other programs or when you use the "multi-adapter compatibility" option.
There are two "game capture" techniques through hooks:
1.) Download the backbuffer from VRAM to RAM, the most commonly used technique, the same technique which is used if you use "Multi-GPU compatibility" mode checkbox in multiplatform game capture. This is not as efficient for a program like OBS that also composites, but you'll notice it'll work without issue.
2.) Shared texture capture (essentially shared memory on VRAM that OBS can access without having to download/reupload), which is the very efficent method that can only be used if OBS is running on the same video card as the game. This technique causes the least amount of performance impact to the system, and is the preferred method that OBS defaults to due to that fact. Note that this is always working with Direct3D games because the microsoft windows compositor makes heavy use of this feature, so if it wasn't working with D3D, AMD would have noticed it immediately. However it's far, far more rare to see this feature used with OpenGL, which we do. It's basically an OpenGL <-> D3D interop feature we have to use to get this to work, and you could probably count the number of programs in existence that use this technique with the fingers of one hand.
Typically, most capture programs tend to use #1 because they're not video mixers, most of them just capture and rarely do anything else, so #2 isn't really necessary for them, which is why you don't see it in those programs. In OBS' case, it's an audio/video mixer/compositor on top of being a capture program, and for compositor programs that also capture, #2 is by far the most efficient method to use, but #2 is less reliable due to the fact that it can't work if the game and OBS are on separate adapters.
The first piece of evidence that this wasn't on my end is that I checked the OpenGL capture code, and couldn't find any real flaw in the actual capture code.
The second piece of evidence is that this doesn't happen with OpenGL games on other adapters when using the shared texture method, everything functions as expected. Even older generations of AMD work. It appears to be a driver or hardware issue specific to that generation of AMD hardware when using shared textures and OpenGL <-> D3D interop.
So to sum it up, AMD most likely did not check these specific OpenGL features with their QA, and they possibly ended up storing textures in a specific way internally that causes this graphical distortion issue with OpenGL games using the shared texture D3D/OpenGL interop capture method. Again, it wouldn't happen with D3D because they would have noticed it immediately in the windows compositor. And again, because so few programs on earth use this technique with OpenGL, it's not unlikely that an issue with it would slip past their QA.
That's my best theory at the moment at least, based upon that limited (but important) evidence.
So as easy as it would be to say it's the program's fault, that statement would be unintentionally fallacious if you don't know what's going on behind the scenes. It's very unlikely the program's fault in this case.
Unfortunately you may just have to use the multi-adapter compatibility option until AMD fixes it somehow, if that's possible for them to do.
Have you tried using the "Multi-adapter compatibility" option in multiplatform's game capture? It will work with OpenGL games just fine, although sadly it'll have reduced performance. This whole situation is almost certainly due to drivers/hardware specific to this hardware in conjunction with the default capture technique.
As the main dev of the program, let me explain why it's most likely not the program's fault. Before I begin, I realize that I sound like I'm defending the program here because I wrote it, but I've investigated this, and I always tend to assume my fault first before investigating just out of caution. So let me go in to the explanation of why you're not getting this with many other programs or when you use the "multi-adapter compatibility" option.
There are two "game capture" techniques through hooks:
1.) Download the backbuffer from VRAM to RAM, the most commonly used technique, the same technique which is used if you use "Multi-GPU compatibility" mode checkbox in multiplatform game capture. This is not as efficient for a program like OBS that also composites, but you'll notice it'll work without issue.
2.) Shared texture capture (essentially shared memory on VRAM that OBS can access without having to download/reupload), which is the very efficent method that can only be used if OBS is running on the same video card as the game. This technique causes the least amount of performance impact to the system, and is the preferred method that OBS defaults to due to that fact. Note that this is always working with Direct3D games because the microsoft windows compositor makes heavy use of this feature, so if it wasn't working with D3D, AMD would have noticed it immediately. However it's far, far more rare to see this feature used with OpenGL, which we do. It's basically an OpenGL <-> D3D interop feature we have to use to get this to work, and you could probably count the number of programs in existence that use this technique with the fingers of one hand.
Typically, most capture programs tend to use #1 because they're not video mixers, most of them just capture and rarely do anything else, so #2 isn't really necessary for them, which is why you don't see it in those programs. In OBS' case, it's an audio/video mixer/compositor on top of being a capture program, and for compositor programs that also capture, #2 is by far the most efficient method to use, but #2 is less reliable due to the fact that it can't work if the game and OBS are on separate adapters.
The first piece of evidence that this wasn't on my end is that I checked the OpenGL capture code, and couldn't find any real flaw in the actual capture code.
The second piece of evidence is that this doesn't happen with OpenGL games on other adapters when using the shared texture method, everything functions as expected. Even older generations of AMD work. It appears to be a driver or hardware issue specific to that generation of AMD hardware when using shared textures and OpenGL <-> D3D interop.
So to sum it up, AMD most likely did not check these specific OpenGL features with their QA, and they possibly ended up storing textures in a specific way internally that causes this graphical distortion issue with OpenGL games using the shared texture D3D/OpenGL interop capture method. Again, it wouldn't happen with D3D because they would have noticed it immediately in the windows compositor. And again, because so few programs on earth use this technique with OpenGL, it's not unlikely that an issue with it would slip past their QA.
That's my best theory at the moment at least, based upon that limited (but important) evidence.
So as easy as it would be to say it's the program's fault, that statement would be unintentionally fallacious if you don't know what's going on behind the scenes. It's very unlikely the program's fault in this case.
Unfortunately you may just have to use the multi-adapter compatibility option until AMD fixes it somehow, if that's possible for them to do.
Murf
Member
Thank you very much for the explanation, I guess that is why I am not seeing the same issue with the playclaw program. As for your suggestion about the OBSmp.
I have another thread in that forum already and am just waiting for the windows version of the HF to come out to try. As of now,. the opengl game does not capture at all in OBSmp (just a black screen) and you commented there to and said the hf needed to be added for windows. I will give it a shot when that is available for download. Thanks again for the reply.
\
Edit: I am waiting for windows HF for OBSmp, but until then where is the multiadapter comp option in OBSmp? cannot seem to locate it.
Last edited:
Murf
Member
Sorry the hot fix, meant update, my apologies. .12.4 says it fixed the black screen Opengl issue (which is what i am getting, just no windows release yet.)
And I see now, already had that checked, but black screen, no worries I'll wait for the windows version of .12.4 and hope it will work. .
And I see now, already had that checked, but black screen, no worries I'll wait for the windows version of .12.4 and hope it will work. .
My bet would be is has something to do with the texture compression methods they used on the R9 285, 380, 380x (and maybe the Fury series?) since not all R9 series are affected. The ones listed are of the GCN 1.2 cards as the remainder of the R9 series cards don't seem to have this issues i.e. OPs old 7850 aka R9 270 (which is GCN 1.0) and my 390 (which is GCN 1.1); both of which do not have this issue with capture.
I am not sure what changed. But on the newest OBS Studio version and on the newest Radeon Driver ( Beta 16.4.2 ) version it seems to be recording OpenGL games fine now. No glitchy / corrupted graphics on the video files.
I have a R9 380 for everyone's information.
Mind you I was messing with the advanced settings before. But when I returned from OpenGL Renderer to DirectX 11 with NV12 and 709 Partial Colors, all videos are recording correctly now.
I have a R9 380 for everyone's information.
Mind you I was messing with the advanced settings before. But when I returned from OpenGL Renderer to DirectX 11 with NV12 and 709 Partial Colors, all videos are recording correctly now.