D3D11: Finish up

[hrydgard]

Remaining features to fix and/or implement:

• Framebuffer depalettization (FF: Type-0 shadows, Sonic Riders, etc)
• Framebuffer readback
• Framebuffer debug features, rework GE debugger to not use GL
• FramebufferManagerD3D11::BlitFramebuffer
• Postprocessing shaders (autotranslate from GLSL using SPIRV-Cross)
• Mysterious missing text in PaRappa
• Full support for "framebuffer blending" (REPLACE_BLEND_COPY_FBO)
  • DBZ: Tenkaichi Tag Team
  • Avoid blitting for a bunch of gpu blending modes #6350 ?
  • Requires BlitFramebuffer
• Logic op blend
• Make sure depth buffer copies work (Saint Seiya)
• Fix most resource leaks
• Fix all remaining significant resource leaks

For Windows 7:

• Avoid using DXGI_FORMAT_B4G4R4A4_UNORM which is only available on Win8+

Please report other issues with D3D11 in this issue.

[mrcmunir]

NOTE : In the info shading language returned N/A but load UI and render.

bugs detected

Gripshift (Background) Black screen or partially in the logo REDMILE and no 3D load can't view this problem not exist in DX9.

[xebra]

I think it also needs backends selection menu in MainWindowMenu.cpp.

[hrydgard]

Thanks @xebra , adding that soon.

[zminhquanz]

@xebra if D3D11 backend work great , and you can continue to implement HW Tessellation

[hrydgard]

hardware tess for D3D11 should be as easy as with GL. I'll leave it for @xebra :)

[hrydgard]

Alright, that's three checkboxes :) Gripshift should work better now.

[mrcmunir]

@hrydgard Grihpshift bug DX11 are fixed. only has glitch flickering in the inferior of screen but this bug happen in DX9/OpenGL too I open new issue for that?

[hrydgard]

Yeah, I think that deserves an issue. Please make a search first and see if there is one already, I don't remember.

[xebra]

Yeah, now I'm trying :)

[tywald]

All of my games crashes when I try to open them if I turn on any kind of texture scaling(xBRZ etc.). Maybe it's just not implemented yet for D3D11?

[hrydgard]

Good catch, I haven't tried that yet. I'll fix it up.

[hrydgard]

@tywald found the bug, committed a fix. Should be all good now.

[xebra]

I implemented it on DX11 but it has some issues similar as DX9 one.
I'll try to fix it so please wait a while.
Anyway, shader compilation very slower than OpenGL.

[hrydgard]

At least you shouldn't be running up against any limits in D3D11...

[xebra]

Probably fixed it without using "instanced tessellation" only with spline.
It's heavy duplicated vertex calculation at the edges of each patch.
Of course, it's no problem in bezier but it's wasted in spline.
This fixes probably improve also DX9 a bit.

Well, DX11 backend still buggy on my PC(Win7), so I can't test well.
The error occurs almost always in CheckAlphaRGBA8888SSE2(), I avoided this issue with commented out this SSE version function, I think this may be alignment issue.

Also, FF4CC doesn't work with unstable error. FF4 is the best platform with testing about spline/bezier.
I know Win7 still unsupported, so I'll wait for this backend more improved :)

[hrydgard]

Oh, yes, that sounds like a possible alignment issue - are you on 32-bit? On 64-bit all allocations should be aligned by default.

Though the main issue on windows 7 is that for some silly reason the B4G4R4A4 texture format is not supported so we need to upconvert those textures to RGBA8888, which is a pain because the code currently assumes that the format converted to has the same amount of bits...

[hrydgard]

@xebra I fixed the alignment crash.

[xebra]

Thanks!
Well, I'm on 64-bit anyway.

[xebra]

Ah, this fixes for 32-bit...
Hmm, anyway, Now I'm testing.

[xebra]

Noooo, I was misunderstanding.
I'm using Win7 64-bit but ppsspp builds was 32-bit so it's fixed :)

[xebra]

I saw the issue about Win7. It's 16-bit texture format issue, I think it also crashes with 5551 and 565 not only 4444.
Tales of Eternia is using format 5551, and crashes when texture creation.
I searched about format, 16-bit textures are supported DX11.1 or higher. Win7 must be supported DX11.1 with SP1 applied hotfix KB2670838. I'm using Win7 SP1 and already applied it but error occurs...
Probably Win7 is supported the formats but error occurring because of runtime-library bug...?

[mrcmunir]

@xebra Pixel formats 5551, 565 or 4444 Only implemented in Windows 8 and higher.

So these variables
DXGI_FORMAT_B5G6R5_UNORM
DXGI_FORMAT_B5G5R5A1_UNORM
DXGI_FORMAT_B4G4R4A4_UNORM

Microsoft never implemented it under Windows 7 system

[hrydgard]

Yup, so we'll need to convert them all to 32-bit texture formats to work correctly on Win7. Silly of Microsoft, I guess they didn't think anyone would want such poor texture formats anymore, but we do :) And so did others because they're back in Win8.

[xebra]

Yeah, it's silly decision anyway :(

[xebra]

CreateTexture() must returns success or fail, if 16-bit texture is unsupported, it must return fail(reason is unknown/unsupported format), but crashes in the function so it's a BUG I mean.

[hrydgard]

Well, not really a bug, it's defined not to work. So we'll just work around it. Well, I will. Soon :)

Though you're right that it should return an error code not crash, heh.

[xebra]

I found a bug with Pursuit Force. See below. This seems polygons flipped front face to back face.

[xebra]

Hmm, maybe depth buffer or alpha blending issue...

[hrydgard]

Yeah, looks more like broken depth buffering...

[hrydgard]

@xebra , Now that that's been merged, should no longer crash on 16-bit textures on D3D11. Please try it :)

[xebra]

@hrydgard Nice work, thanks :)

[LunaMoo]

D3d11 still closes on boot for me on win 7 when not running with VS debugger attached, but I used CodeXL to debug and got https://github.com/hrydgard/ppsspp/blob/master/ext/native/thin3d/thin3d_d3d11.cpp#L752 with

The thread tried to read or write data that is misaligned on hardware that does not provide alignment. For example, 16-bit values must be aligned on 2-byte boundaries; 32-bit values on 4-byte boundaries, and so on.

Win 10 unaffected.

[hrydgard]

But it does work with it attached?

Bizarre that alignment would be an issue when calling the shader compiler. Same result with both 32-bit and 64-bit builds?

Maybe we simply fail to load it for some reason and the error message is just some kind of side effect of that?

[LunaMoo]

Yeah with VS debugger attached it does run fine. Edit: and yes, 32/64 bit builds have same result.

[hrydgard]

You should be able to attach MSVC to the crashed binary before pressing the close button in the dialog that comes up (in some cases the crash dialog should even display a debug button but I can't remember what makes that happen). I'm baffled though.

[hrydgard]

Dolphin uses the old D3DX11CompileFromMemory instead, though I think nowadays that just forwards to D3DCompile. Not sure if it would be worth doing the same for backwards compatibility with something.

[LunaMoo]

One of my pc's was just closing without any error, but with another I could attach debugger after crash, maybe something useful here:

[hrydgard]

We can see that ptr_D3DCompile is nullptr. That makes it impossible to build shaders so we need to bail.

Probably simply need to use Dolphin's method to load the shader compiler as it's more backwards compatible.

However, the thing where it only worked in the debugger on one of your PCs is still odd.

[LunaMoo]

I mean it works from the debugger on both pc's, but if I run ppsspp normally outside of VS, only one pc get's error message, the other closes silently.
Maybe this is also useful:

[xebra]

I got the same issue. I think this issue is missing DLL.
So take the "d3dcompiler_47.dll" to the folder of exe's root or "Windows/System32(SysWOW64)", it fixed.
Seems Win7 doesn't have the DLL by default, however VS has it in "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin".

[hrydgard]

Hm, I wonder what you need to install to get it, like a DX redistributable or something. Or if there's another version that's available by default.

[LunaMoo]

Thanks for the hint xebra, I copied C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\d3dcompiler_47.dll into C:\Windows\System32 and 64 bit build works fine:). And indeed this file is installed with Win 10(althrough slightly different version than the VS one).

Oh see this

The D3DCOMPILER_46.DLL or D3DCOMPILER_47.DLL from the Windows SDK is not a system component and should not be copied to the Windows system directory. You can redistribute this DLL to other computers with your application as a side-by-side DLL.

[mrcmunir]

d3dcompiler_47.dll found in SDK windows 8.1 so maybe fault too in Windows 8 .

Windows Kits\8.1\Redist\D3D\x64 -> For Runtime x64
Windows Kits\8.1\Redist\D3D\x86 -> For Runtime x86

[xebra]

BTW, running on Win7 works fine so we don't need below code in GameSettingsScreen.cpp anymore :)

	if (!DoesVersionMatchWindows(6, 2)) {
		// Hide the D3D11 choice if Windows version is older than Windows 8.
		// We will later be able to support Windows 7 and Vista (unofficially) as well,
		// but we currently depend on a texture format that's only available in Win8+.
		renderingBackendChoice->HideChoice(2);  // D3D11
	}

[hrydgard]

So the issue is that while the latest available version of DirectX for a Windows version is always installed by Windows Update, D3DCompiler.dll is not: https://msdn.microsoft.com/en-us/library/ee416644.aspx

"Note The HLSL compiler (D3DCompile*.dll) and the D3DX utility library for Direct3D 11 (D3DX11*.dll) are not built into any version of the Windows operating system, but they can be deployed as part of an application's installer by using the existing DirectSetup technology; for more information about using DirectSetup, see DirectX Installation for Game Developers"

Most games can precompile their shaders so you don't need to ship the compiler, but we can't.

Sigh. So will need to redistribute it somehow, I wonder if it's alright to just grab the _47 DLL and ship it or if we should link to an installer.

[hrydgard]

Apparently it is alright to redistribute it, at least according to this answer:

http://stackoverflow.com/questions/25873609/directx-11-2-development-on-windows-7d

[hrydgard]

wrong button

[hrydgard]

The major work is done!

A few bugs left to fix etc.