I am using a geometry shader in my DirectX application which is compiled using shader model 4.0 (gs_4_0). The shader works correctly on my development pc with a DirectX 11 card but fails on two client PCs with DirectX 10.1 cards. The application fails when it calls CreateGeometryShader using the compiled bytecode with a return result of E_INVALIDARG.
I assume that the client PC graphics cards or drivers do not support some feature I am making use of in the geometry shader.
The client machines do not have the DirectX SDK installed so I can't get a more detailed error message.
How can I investigate this issue further?
Is there a list of likely causes of this problem which I can run through?
Related
i'm working on directx9 and i'm trying to get my hand on shaders, here is my shader:
sampler texLastPass : register( s0 );
float4 main(in float2 t : TEXCOORD0) : COLOR
{
float4 color = tex2D(texLastPass, t);
return float4(color.rgb, 1.0f);
}
In theory there should be no change with it, but instead my whole objects is filled with pixel that exists on position (0, 0) in texture.
So why provided pixel coordinates to shader are wrong?
Your shader code has a sampler, but where is the texture? From Microsoft Docs:
Three things are required to sample a texture:
* A texture
* A sampler (with sampler state)
* A sampling instruction
Since you are missing the binding to the texture, Direct3D 9 is going to provide you a value of 0,0,0 for all texture references.
texture tex0 : register( t0 );
Without this it still builds because it implicitly assumes you mean t0.
You are using 'explicit binding' in this shader, which is perfectly fine and recommended if you are avoiding the use of the legacy Effects system. That said, Direct3D 9 developer education materials and samples were heavily based on Effects which uses a slightly different syntax, and therefore a source of confusion.
You don't show your C/C++ code, so it could be related to your binding code as well.
Note that if writing Direct3D 9 code these days, a few important things to keep in mind:
The DirectX SDK is deprecated and legacy, and it's use is strongly discouraged. See Microsoft Docs. It has a number of known issues and is challenging to even install.
The core headers for Direct3D 9 are part of the Windows SDK, so they are already part of Visual Studio 2012 or later. You don't need the DirectX SDK to build Direct3D 9 code.
The D3DX9 utility library is also deprecated, but is really the only way to get Direct3D 9 support code. As of earlier this year, you can now consume it from NuGet with a simple side-by-side redistribution rather than rely on the legacy DirectX SDK or the legacy DirectX End-User Runtime Redist. See this blog post.
The Direct3D 9 Debug Device is not supported on Windows 8, Windows 8.1, or Windows 10.
All the samples for Direct3D 9 from the legacy DirectX SDK can be found on GitHub.
You should take a look at DirectX 11 as a better starting point which has much better debugging support, tools support, and open source libraries. See this blog post.
I'm porting C code to HLSL (compute shader).
The compiler is crazy with one of the for loops. At runtime, the display device driver detect an unreasonable amount of time to execute the code.
Here is the partial source code with the offending for loop:
P = FloatToAsciiNoExponent(F * Factor, DstBuf, 7);
uint TmpBuf[FTOA_BUFFER_SIZE];
uint BytesWritten = IntToAscii(Exp10, TmpBuf, BASE10);
DstBuf[P++] = 'E';
[fastopt]
for (uint I = 0; I < BytesWritten; I++)
DstBuf[P++] = TmpBuf[I];
At run time, I got the following debug message:
D3D11 ERROR: ID3D11Device::RemoveDevice: Device removal has been
triggered for the following reason (DXGI_ERROR_DEVICE_HUNG: The Device
took an unreasonable amount of time to execute its commands, or the
hardware crashed/hung. As a result, the TDR (Timeout Detection and
Recovery) mechanism has been triggered. The current Device Context was
executing commands when the hang occurred. The application may want to
respawn and fallback to less aggressive use of the display hardware).
EXECUTION ERROR #378: DEVICE_REMOVAL_PROCESS_AT_FAULT]
If I comment out the two for-loop lines, everything is OK (Except of course the final result which lacks his last part).
FloatToAsciiNoExponent() is a function which convert his first argument into a list or ascii code stored in the second argument (an array of uint). The last argument is the numeration base for conversion. It has been validated.
IntToAscii() is a function converting his first argument into a list of ascii code stored in the second argument (an array of uint). It has been validated.
The original C source code I'm porting can be found here: https://searchcode.com/codesearch/view/14753060/
I'm running on Windows 7 and DirectX SDK of June 2010 (The last one running on Windows 7). Windows update has been executed and every update installed. The graphic card is an NVidia Quadro K4200 having 24GB of RAM with driver version 431.02.
Any help appreciated.
With DirectCompute you still need to make sure each instance completes in a reasonable time or you will hit TDR timeouts (~2 seconds).
See Microsoft Docs
With DirectX 11.1 (Windows 8 or later), you can use D3D11_CREATE_DEVICE_DISABLE_GPU_TIMEOUT to give you a bit more time for a long-running DirectCompute shader, but you can make the system unresponsive.
You can install a partial version of DirectX 11.1 on Windows 7 Service Pack 1 via KB2670838
You should also read this blog post for more up-to-date information about the legacy DirectX SDK.
UPDATE Apparently this was actually an HLSL compiler bug with the legacy DirectX SDK. Note that you can and should use the latest Windows 10 SDK HLSL compiler even for DirectX 11 on Windows 7. See this blog post and Microsoft Docs.
Answering myself:
I upgraded my PC to Win10 which includes DirectX12. Now the source code is working as expected. This confirm that the June 2010 compiler is bugged.
I would like to add Direct3D as an optional graphics backend of a 2D game to get around DirectDraw's limitations (such as the horrid DirectDraw emulation in Windows 8).
Can I do this in such a way that the majority of users would not need to install anything? I noticed that Windows XP comes with some Direct3D files, can I target that version of the runtime?
According to John McCaskey, a software engineer on Steam:
Games which don't use the D3DX helpers (such as Source engine games) don't require running the annoying installer on first launch as they only depend on major d3d9/10/11 versions being installed. However, games that do use D3DX must run it as it's the only way Microsoft has allowed for distributing and checking the version info on the files.
Thus, using Direct3D 9 (d3d9.h) directly should be fine, assuming the user has some version of DirectX 9 installed.
Source: Why Steam Makes You Reinstall DirectX - Rock, Paper, Shotgun
i'm currently in the process of creating a Windows 8 applicaiton using SharpDX (the managed c# directx wrapper). However I have ran into problems with one of my shaders and I want to know if its possible to debug such applications. PIX doesn't seem to work of directX apps as the executable does not like opening directly, and the new visual studio graphics debugging toolkit in VS2012 always states "unable to start the experiment" when I try to capture any information about my session.
Thanks!
I'm coming to this post a bit late, but I would just like to add for future visitors to this thread that I have successfully used the Visual Studio 2012 Graphics Diagnostics ('the DirectX Debugger') in both SlimDX and SharpDX projects. There are a few things that can disrupt the process, notably in SlimDX projects I couldn't debug apps with mixed DX10/11, DX10 doesn't seem to work with VS2012, at least for managed code. So if you have any text rendering for example, you will have to remove it for the debugging session. I'd say using the following to isolate your DX10 code should work
#define DXDIAGSESSION
// ...
#if DXDIAGSESSION
// your DX10 code goes here.
#endif
And for the SharpDX project (C# / WinRT / XAML / SharpDX) I couldn't use the Managed Only Debugger. I had to set the Debugger to Mixed (Managed and Native) to make it work.
The DirectX Visual Studio debugger only works with native code. You'll get the error that you are until you right-click on the project, select "Properties", go to the Debugging tab, and enable native debugging.
While that will remove the error it may or may not resolve the problem. I've got a similar scenario using SurfaceImageSource (C++) being hosted in a managed component and a DirectXPage in a C++ project. In both projects it appears that DirectX debugging is failing to capture frames. It appears this feature only works for programs that are using a DirectX UI (no managed UI components).
I am writing Windows Hooks for DirectX 6.1. I want to intercept calls for EMBM (Environment Mapped Bump Mapping) and pass the data to own bump shader, so application which depend on EMBM will work correctly. The only problem is that DX 6.1 don't allow shaders at all. I can't simple replace Direct3DDevice3 with class from newer SDK, because it's methods uses different sets of arguments and application that use my hooked dll will crash. I do not know how to workaround through. I am not so good at DirectX (maybe there is more effective way to implement bump in DX 6.1 that will work on modern hardware?) Maybe it is possible to query some interface in D3Device that will allow me to use shaders?
Anything that could point me in right direction would be much appreciated.
Each Direct 3D device derives directly from IUnknown so no you cannot QI from a v6 device to a v9 device.
The only way you can do what you want (above driver level) is to implement the entire v6 device and translate all calls to their v9 equivalents. Of course you then have a problem if the game implements embm via v7 or v8 ...