If I write a DirectX 11 application using the DX11 SDK, and I don't have a DirectX card, will I be able to run the application?
I can't find the requirements for actually using the DX11 SDK.
Thanks!
Yes you can. What you are looking for is called Direct3D feature levels. With this
paradigm you can write an application with the features supported by your graphic card. Before the creation of the D3D device you can query the card and find the feature level supported, then you use this level in the device creation.
Of course you cannot use the new features provided by DirectX 11 on your hardware.
This tutorial site states that when setting up a device and swap chain, a D3D_DRIVER_TYPE of D3D_DRIVER_TYPE_REFERENCE can be used to allow DX11 features
to be explored even if you don't have a DX11 graphics card.
For further reading, click that link and scroll down halfway until you see D3D11CreateDeviceAndSwapChain().
Related
The DXGI Overview on MSDN says that the Direct3D API (10, 11 and 12) sits on top of DXGI wheras DXGI sits on top of the Hardware which is illustrated by the following picture:
The article further mentions that the tasks of DXGI basically are enumerating adapters and present images on the screen. Now, if DirectX sits on top of DXGI, how are all the math related tasks invoked on the actual hardware (GPU)? Or is the the architectural overview wrong and D3D_ also directly access the hardware?
This diagram is a logical map, not an explicit map of how everything actually gets implemented. In reality, Direct3D and DXGI are more 'side-by-side' and the layer that includes the User Mode Driver (UMD) and the Kernel Mode Driver (KMD) is the Windows Display Driver Model (WDDM) which uses the Device Driver Interface (DDI) to communicate to the kernel mode which in turns communicates with the hardware. The various versions of Direct3D are also 'lofted' together to use the same DDI in most cases (i.e. Direct3D 9 an Direct3D 10 legacy applications end up going through the same Direct3D 11 codepaths where possible).
Since "DXGI" means "DirectX Graphics Infrastructure" this diagram is lumping the DXGI APIs with WDDM and DDI.
The purpose of the DXGI API was to separate the video hardware/output enumeration as well as swapchain creation/presentation from Direct3D. Back in Direct3D 9 and prior, these were all lumped together. In theory DXGI was supposed to not change much between Direct3D versions, but in practice it has evolved at basically the same pace with a lot of changes dealing with the CoreWindow swapchain model for Windows Store apps / Universal Windows Platform apps.
Many of the DXGI APIs are really for internal use, particularly when dealing with surface creation. You need to create Direct3D resources with the Direct3D APIs and not try to create them directly with DXGI, but you can use QueryInterface in places to get a DXGI surface for doing certain operations like inter-API surface sharing. With Direct3D 11.1 or later, most of the device sharing behavior has been automated so you don't have to deal with DXGI to use Direct2D/DirectWrite with Direct3D 11.
The real question is: Why does it matter to you?
See DirectX Graphics Infrastructure (DXGI): Best Practices and Surface Sharing Between Windows Graphics APIs
With the push towards multimedia enabled mobile devices this seems like a logical way to boost performance on these platforms, while keeping general purpose software power efficient. I've been interested in the IPad hardware as a developement platform for UI and data display / entry usage. But am curious of how much processing capability the device itself is capable of. OpenCL would make it a JUICY hardware platform to develop on, even though the licensing seems like it kinda stinks.
OpenCL is not yet part of iOS.
However, the newer iPhones, iPod touches, and the iPad all have GPUs that support OpenGL ES 2.0. 2.0 lets you create your own programmable shaders to run on the GPU, which would let you do high-performance parallel calculations. While not as elegant as OpenCL, you might be able to solve many of the same problems.
Additionally, iOS 4.0 brought with it the Accelerate framework which gives you access to many common vector-based operations for high-performance computing on the CPU. See Session 202 - The Accelerate framework for iPhone OS in the WWDC 2010 videos for more on this.
Caution! This question is ranked as 2nd result by google. However most answers here (including mine) are out-of-date. People interested in OpenCL on iOS should visit more update-to-date entries like this -- https://stackoverflow.com/a/18847804/443016.
http://www.macrumors.com/2011/01/14/ios-4-3-beta-hints-at-opencl-capable-sgx543-gpu-in-future-devices/
iPad2's GPU, PowerVR SGX543 is capable of OpenCL.
Let's wait and see which iOS release will bring OpenCL APIs to us.:)
Following from nacho4d:
There is indeed an OpenCL.framework in iOS5s private frameworks directory, so I would suppose iOS6 is the one to watch for OpenCL.
Actually, I've seen it in OpenGL-related crash logs for my iPad 1, although that could just be CPU (implementing parts of the graphics stack perhaps, like on OSX).
You can compile and run OpenCL code on iOS using the private OpenCL framework, but you probably don't get a project into the App Store (Apple doesn't want you to use private frameworks).
Here is how to do it:
https://github.com/linusyang/opencl-test-ios
OpenCL ? No yet.
A good way of guessing next Public Frameworks in iOSs is by looking at Private Frameworks Directory.
If you see there what you are looking for, then there are chances.
If not, then wait for the next release and look again in the Private stuff.
I guess CoreImage is coming first because OpenCL is too low level ;)
Anyway, this is just a guess
I am writing a small utility that reports system capabilities. One is the highest shader model supported by the installed graphics card, and I am currently detecting this using Direct3D 9.0c's device capabilities and checking the VertexShaderVersion and PixelShaderVersion fields of the D3DCAPS9 structure.
HRESULT hrDCaps = poD3D9->GetDeviceCaps(D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, &oCaps);
if (!FAILED(hrDCaps)) {
// Pixel and vertex shader model versions. Use the minimum number of each for "the" shader model version
const int iVertexShaderModel = D3DSHADER_VERSION_MAJOR(oCaps.VertexShaderVersion);
const int iPixelShaderModel = D3DSHADER_VERSION_MAJOR(oCaps.PixelShaderVersion);
However, both these values return shader model 3 even for cards that support higher models. Here is what GPU-Z returns for the same card, for example:
This question indicates that DX9 will never report more than SM3 even on cards that support a higher model, but doesn't actually mention how to solve it.
How do I accurately get the shader model supported by the installed card? That is, the card capabilities, not the installed DirectX driver capabilities.
The utility has to run on Windows 2000 and above, and work on systems where a graphics card and even DirectX are not installed. I am currently dynamically loading DX9, so on those systems the check gracefully fails (which is ok.) But I am seeking a similar solution: something that will still run on all systems, and work correctly (detect the SM version) on most systems.
Edit - purpose: I am not using this code to dynamically change features of a program, ie select shaders. I am using it to report hardware capabilities as a 'ping' to a server, which is used to we have a good idea of typical hardware that our customers use, which can inform future product decisions. (For example: how many customers have SM4 or above? How many are using a 64-bit OS? Etc.) This is why either (a) gracefully failing, so we know it failed, or (b) getting an accurate shader model number are the two preferred modes.
Edit - answers so far: The answer below by SigTerm suggests instantiating DirectX 11, 10.1, 10, and 9.0c in order, and basing the reported shader model on which version instantiated without failures (shader model 5, 4.1, 4, and DXCAPS in that order.) If possible, I'd appreciate a code example of the DX11 and 10 ways to do this.
This may not be a reliable solution. For example, I am running Windows on a VMWare Fusion virtual machine on OSX. The Fusion drivers report DX11 in DxDiag, yet I know from the Fusion tech specs that it only supports DX9.0c and shader model 3. Still, with this exception, this method seems the best way so far.
version 4 is only supported on Direct3D10. Therefore, D3D9 api won't report it. Use D3D10/D3D11 api to detect higher version.
something that will still run on all systems, and work correctly (detect the SM version) on most systems.
Attempt to initialize D3D10/D3D11 to check functionality, if it fails init D3D9. Use LoadLibrary + GetProcAddress to load D3D10 functions, because if you link with D3D10 using .lib file, your application will fail to start if d3d10 is missing.
Or use OpenGL and try to map capabilities reported by OpenGL to D3D capabilities (probably a very bad idea).
Or build GPU database and use that.
where a graphics card and even DirectX are not installed.
I think you're asking for the impossible, because shaders are provided by DirectX, and the driver/GPU might not even have a concept of a "shader model" under the hood. In this case the only way to detect capabilites will be to make GPU database of some sort, detect installed devices, and return answer from database. This won't be relabile, of course.
Here is a link about DirectX versions and supported shader models.
If I want to do scaling and compositing of 2D anti-aliased vector and bitmap images in real-time on Windows XP and later versions of Windows, making the best use of hardware acceleration available, should I be using GDI+ or DirectX 9.0c? (Actually, Windows XP and Windows 7 are important but we're not concerned about performance on Vista.)
Is there any merit in using SDL, given that the application is not cross-platform (and never will be)? I wonder if SDL might make it easier to switch to whichever underlying drawing API gives better performance…
Where can I find the documentation for doing scaling and compositing of 2D images in DirectX 9.0c? (I found the documentation for DirectDraw but read that it is deprecated after DirectX 7. But Direct2D is not available until DirectX 10.)
Can I reasonably expect scaling and compositing to be hardware accelerated on Windows XP on a mid- to low-spec PC (i.e. integrated graphics)? If not then does it even matter whether I use GDI+ or DirectX 9.0c?
Do not use GDI+. It does everything in software, and it has a rendering model that is not good for performance in software. You'd be better off with just about anything else.
Direct3D or OpenGL (which you can access via SDL if you want a more complete API that is cross-platform) will give you the best performance on hardware that supports it. Direct2D is in the same boat but is not available on Windows XP. My understanding is that, at least in the case of Intel's integrated GPU's, the hardware is able to do simple operations like transforming and composing, and that most of the problems with these GPU's are with games that have high demands for features and performance, and are optimized for ATI/Nvidia cards. If you somehow find a machine where Direct3D is not supported by the video card and is falling back to software, then you might have a problem.
I believe SDL uses DirectDraw on Windows for its non-OpenGL drawing. Somehow I got the impression that DirectDraw does all its operations in software in modern releases of Windows (and given what DirectDraw is used for it never really mattered since the win9x era), but I'm not able to verify that.
The ideal would be a cross-platform vector graphics library that can make use of Direct3D or OpenGL for rendering, but AFAICT no such thing is available. The Cairo graphics library lacks acceleration on Windows, and Mozilla has started a project called Azure that apparently has that but doesn't appear to be designed for use outside of their projects.
I just found this: 2D Rendering in DirectX 8.
It appears that since Microsoft removed DirectDraw after DirectX 7 they expected all 2D drawing to be done using the 3D API. This would explain why I totally failed to find the documentation I was looking for.
The article looks promising so far.
Here's another: 2D Programming in a 3D World
I am developing an in-house app that would use XInput or DirectInput to read from the Xbox 360 controller. (I think it'll be the cheapest/easiest way to get multiple controls in the operator's hands.)
I will need to source-control all source and tools, which means also the SDK's. I'd rather not take all of DirectX -- is DirectInput and XInput separable from the whole DirectX SDK?
The short answer is no. Technically it would be possible to extract the required portions of the runtime, but if you look at the SDK EULA and redistribution agreement you will see that you're only allowed to install the full DirectX runtime.