How to determine the system DirectX is 11 or 11.1? - directx

I am running Windows 7. When I use DxDiag, it shows the version as 11.
When I use Visual Studio 2012 which can access Windows API, it can run the code with feature level D3D_FEATURE_LEVEL_11_1
So I agot confused, what is the exact version of my DirectX version?

There are a number of confounding factors at work here, so let's take them one at a time:
DXDIAG is part of the OS along with the DirectX Runtime but is also manually updated for that string, so it is often less than detailed/accurate about reporting "DirectX" version. For Windows Vista SP1 it doesn't say "DirectX 10.1" and says "DirectX 10". Similarly, with both Windows 8 and Windows 7 SP 1 + KB2670838 installed it still says "DirectX 11" and not "DirectX 11.1". On Windows 8.1 it still says "DirectX 11" and not "DirectX 11.2". In short, DXDIAG is not your best option for technical details like this. You could try using the latest version of dxcapsviewer in the Windows 8.1 SDK which is a bit more sophisticated in how it check things, but still needs manually updating over time so it currently says nothing about Windows 10 features like DX 11.3 or DX 12.
If you pass NULL for pFeatureLevels to D3DCreateDevice even on Windows 8.x, you will still not get D3D_FEATURE_LEVEL_11_1. This is for backcompat reasons and ensures the behavior doesn't change where NULL gets you 9.1 - 11.0. You have to manually list the 11.1 value in the array to get it--assuming the system+driver combo actually supports it. Note that if you do include 11.1 in the array, the call will fail with E_INVALIDARG on Windows Vista SP2, Windows 7 RTM, or Windows 7 SP1 without KB2670838.
Windows 7 SP1 + KB2670838 provides the DirectX 11.1 API, but does not support D3D_FEATURE_LEVEL_11_1 or any of the new optional hardware features because it doesn't include support for the new WDDM 1.2 driver model. You have to be using Windows 8 or later to get D3D_FEATURE_LEVEL_11_1 with a WDDM 1.2 driver and appropriate hardware. See Microsoft Docs
In general, the proper way to handle all this for Windows desktop applications is:
D3D_FEATURE_LEVEL lvl[] = {
D3D_FEATURE_LEVEL_11_1, D3D_FEATURE_LEVEL_11_0,
D3D_FEATURE_LEVEL_10_1, D3D_FEATURE_LEVEL_10_0,
D3D_FEATURE_LEVEL_9_3, D3D_FEATURE_LEVEL_9_2, D3D_FEATURE_LEVEL_9_1
};
DWORD createDeviceFlags = 0;
#ifdef _DEBUG
createDeviceFlags |= D3D11_CREATE_DEVICE_DEBUG;
#endif
ID3D11Device* pDevice = nullptr;
ID3D11DeviceContext* pContext = nullptr;
D3D_FEATURE_LEVEL fl;
HRESULT hr = D3D11CreateDevice( nullptr, D3D_DRIVER_TYPE_HARDWARE, nullptr,
createDeviceFlags, lvl, _countof(lvl),
D3D11_SDK_VERSION, &pDevice, &fl, &pContext );
if ( hr == E_INVALIDARG )
{
hr = D3D11CreateDevice( nullptr, D3D_DRIVER_TYPE_HARDWARE, nullptr,
createDeviceFlags, &lvl[1], _countof(lvl)-1,
D3D11_SDK_VERSION, &pDevice, &fl, &pContext );
}
if (FAILED(hr))
...
Then to detect support for Direct3D 11.1, you see if you can obtain the Direct3D 11.1 interfaces:
ID3D11Device1* pDevice1 = nullptr;
ID3D11DeviceContext1* pContext1 = nullptr;
hr = pDevice->QueryInterface( __uuidof( ID3D11Device1 ),
reinterpret_cast<void**>( &pDevice1 ) );
if ( SUCCEEDED(hr) )
{
// DirectX 11.1 is present, otherwise only DirectX 11.0
(void)pContext->QueryInterface( __uuidof( ID3D11DeviceContext1 ),
reinterpret_cast<void**>( &pContext1 ) );
}
Don't make assumptions based on Direct3D Feature Level what version of DirectX is installed or vice-versa.
Windows 8 Store apps can assume that DirectX 11.1 is present, but can't assume any particular Direct3D Feature Level (although 9.1 is the minimum you'll ever see).
Windows 8.1 Store apps can assume DirectX 11.2 is present, but again can't assume anything about Direct3D Feature Level.
Windows phone 8.0 apps can assume DirectX 11.0 is present and the devices only support 9.3.
Windows phone 8.1 apps can assume DirectX 11.1 is present and the devices only support 9.3.
Xbox One apps can assume DirectX 11.1 is present. Exclusive apps can assume FL 11.1 is present. Shared apps have to use FL 10.0.
See this post for details on the various nuances of device creation and DirectX 11.x version detection.
See this post and this one for important notes about DirectX 11.1 on Windows 7.

DirectX Feature Levels
https://msdn.microsoft.com/en-us/library/windows/desktop/ff476876%28v=vs.85%29.aspx
A feature level is a well defined set of GPU functionality.
Your DirectX version is 11, but depending on your hardware (GPU) you might get feature level 11_1. If your friend down the street has Windows 8.1 and a supporting graphics card, they might have 11.2 features.
Although from what it sounds like, you have at least some 11.1 features available to you.

As said before: Run dxdiag -> go to display -> check driver model. If you have WDDM 1.3 than DirectX 11.2 is installed in your system, if you have WDDM 1.2 than you have DirectX 11.1.

https://walbourn.github.io/directx-11-1-and-windows-7-update/ (http://blogs.msdn.com/b/chuckw/archive/2013/02/26/directx-11-1-and-windows-7-update.aspx)
DXDIAG: Even after applying KB 2670838 to Windows 7 SP1, DXDIAG will still report it as "DirectX 11".
When in doubt, I would suggest relying on the feature level returned from CreateDevice (et al) to be correct.

Related

DirectX 11/12 without UWP possible?

I've haven't looked at DirectX since the DX9 era. Is it possible to make DX11/12 applications without having to also make them UWP applications?
I'm a little concerned about the overhead of UWP-- for fun, I made an empty application, and I noticed it uses ~30MB just to draw a blank window.
I'm guessing by "WUP" you mean the Universal Windows Platform (UWP). Direct3D 11 is supported for Win32 classic desktop apps on Windows 7, Windows Vista SP2, Windows 8.x, and Windows 10. Direct3D 12 is supported for Win32 classic desktop apps on Windows 10. Both are also supported for UWP and Xbox One.
To catch up on the modern story for DirectX, you should see: MSDN, Where is the DirectX SDK (2015 Edition)?, and Getting Started with Direct3D 11, as well as the DirectX Tool Kit tutorials tutorials
There are three basic appmodels for UWP: XAML, XAML+DirectX, and DirectX (i.e. no XAML). A basic DirectX app for Direct3D 11 with just a swap chain and device has an EXE of about 100 KB as an x86 application in Release mode. A DirectX+XAML 'empty' app is around 347 KB.
UPDATED: The basic DirectX app for Direct3D 11 as Release mode for x86 has a RAM footprint of around 6.1 MB in full-screen mode. A DirectX+XAML 'empty' app in Release mode for x86 is 11.2 MB. That's pretty good since a 1920 x 1080 BGRA32 render target texture is 8 MB of VRAM.

Can D3D11_CREATE_DEVICE_DISABLE_GPU_TIMEOUT be passed with D3D_FEATURE_LEVEL_11_0?

MSDN on D3D11_CREATE_DEVICE_DISABLE_GPU_TIMEOUT says:
Direct3D 11: This value is not supported until Direct3D 11.1.
Does this mean runtime version or feature level?
Can I pass the flag to D3D11CreateDevice but only pass feature level 11_0?
Is the feature level irrelevant and it just depends on the installed runtime version? What happens if I pass the flag to a DX runtime 11.0? Will it just be ignored silently? Or do I first have to detect the DX runtime version somehow, and then pass the flag only if the DX runtime version is at least 11.1?
The 'correct' way to determine if you have the Direct3D 11.1 Runtime would be as follows:
#include <d3d11_1.h>
#include <wrl/client.h>
#pragma comment(lib,"d3d11.lib")
bool IsDirect3D11_1OrGreater()
{
Microsoft::WRL::ComPtr<ID3D11Device> device;
HRESULT hr = D3D11CreateDevice(
nullptr,
D3D_DRIVER_TYPE_NULL,
nullptr,
0,
nullptr,
0,
D3D11_SDK_VERSION,
device.GetAddressOf(),
nullptr,
nullptr
);
if (FAILED(hr))
return false;
Microsoft::WRL::ComPtr<ID3D11Device1> device1;
return SUCCEEDED(device.As(&device1));
}
You then call IsDirect3D11_1OrGreater. If it's true, then you are safe to use a flag like D3D11_CREATE_DEVICE_DISABLE_GPU_TIMEOUT that requires the Direct3D 11.1 Runtime
Keep in mind that you shouldn't be using D3D11_CREATE_DEVICE_DISABLE_GPU_TIMEOUT as a matter of course. It really only should be used for DirectCompute-heavy programs that are free to tie up the GPU a lot and potentially cause the system to become unresponsive to UI. Use it with caution.
That also implies your application will require a Direct3D Feature Level 11.0 or greater card to use DirectCompute 5.0 -or- it will require Direct3D Feature Level 10.0 and need to do a CheckFeatureSupport(D3D11_FEATURE_D3D10_X_HARDWARE_OPTIONS, ...) call and verify D3D11_FEATURE_DATA_D3D10_X_HARDWARE_OPTIONS.ComputeShaders_Plus_RawAndStructuredBuffers_Via_Shader_4_x is true for DirectCompute 4.0.
If IsDirect3D11_1OrGreater returns false, then you should tell the user:
This application requires the DirectX 11.1 Runtime. It is supported on
Windows 7 Service Pack 1 with KB2670838 or later Windows operating systems.
See also DirectX 11.1 and Windows 7 and DirectX 11.1 and Windows 7 Update.
This is about runtime version, so you need Windows 8 at least to have this feature enabled.
You can request a Feature Level 11 only device while having this flag, just tried and it worked perfectly.
Otherwise it would be problematic since NVidia card support 11.1 only since their 900x generations.
It refers to runtime version.
You might detect OS version, but you might go easier by checking installed DirectX runtime .dll version instead, by trying LoadLibrary on:
{
"d3d11.dll",
"d3d11_1.dll",
"d3d11.dll",
"d3d11_1sdklayers.dll",
"d3d11_2sdklayers.dll",
"d3d11_3sdklayers.dll",
"d3d12.dll"
}
sequentially until it fails (returns NULL). Or in reverse order, until it succeeds. This is the same hack as with creating device with highest feature level.

Delphi - TCameraComponent won't find flash

I'm using Delphi 10.0 Seattle and trying to use the rear cameras's light on a Lenovo Thinkpad tablet running Windows 10 Pro. I am using TCameraComponent.
I tried using CameraComponent.TorchMode := TTorchMode.ModeOn from FMX.Media, but it raises an exception saying that the device has no torch.
Anyone know why this happens, and if there is some way to access this light/flash?
FMX in Delphi 10.0 Seattle does not implement either Flash or Torch functionality at all on Windows. It is only implemented on OSX, iOS, and Android.
You will have to resort to using Windows-specific APIs, or even manufacturer-specific APIs, to access light/torch functionality. For example, there are FlashControl and TorchControl classes in the Windows UWP API.

Will programs compiled with Delphi 2010 run on Windows 10 without problems?

Are there any problems with programs that are compiled with Delphi 2010, using Rave reports (no database connection) running on Windows 10?
In principle, there's no reason why a program compiled with Delphi 2010 will not work perfectly well on Windows 10. Indeed, a program compiled with any 32 bit version of Delphi (Delphi 2 or later) can, in principle, be executed on Windows 10.
The usual caveats apply though. You have to make sure that your code respects features like UAC. So don't attempt to write to HKLM, system directories, etc. as standard user.
As a broad guideline, if your program executes on Windows 8.1, you can expect it to execute on Windows 10 also.
So, in summary, you should be perfectly capable of producing a program that runs on Windows 10 using Delphi 2010. However, it's impossible for anyone to tell you definitively that your program will run because only you know the full details of how your program is implemented. You should test your program on each new operating system as it is released, if not before it is released.
I'm not sure, but the internal Kernel ID from Windows is set from 6.x (Windows Vista - Windows 8.1) to 10.0 (Windows 10) so this can be a problem.

Delphi XE7 Application on Galaxy P5200

I downloaded the trial version of Delphi XE7.
After successfully compiling and running some demos on a a virtual device, I connected a Galaxy Tab 3 P5200 through the USB cable.
When I compile and run an application, it is correctly deployed to the device, but when it starts a black screen appears with the following message:
Application does not support this device
In the Delphi XE7 datasheet there is a small box with the "Supported Deployment Platforms" ... for Android they say that an ARMv7 device with NEON support is required. The Galaxy 3 P5200 has an Intel Atom CPU Z2560 ... so Delphi XE7 simply cannot build applications for this device ...
I don't know if you still have this problem but I'll answer it anyways since this problem might occur to other people as it happened with me.
I was able to solve this issue following this:
Running Delphi Applications on Android Intel
From what I could understand, Firemonkey tries to inject code into the application as a some sort of test, and by doing so it uses both mips and x86 architecture, and those are not supported by Intel Atom processors...
Galaxy Tab 3 uses an Intel processor, so I'm sure this will work for you.
In the IDE, open the Deployment Manager (Project > Deployment), and locate the following entry:
After doing so, clean and re-build your project, the application should work just fine.
You can read more about it on Embarcadero's Wiki.

Resources