Quote:DieterVW: The SDK contains the headers, but the runtime is shipped in the OS.
DieterVW,
DirectX9 had a number of versions. I suspect that the DX9 effects library was the main difference between versions, but nevertheless it could be considered as a vehicle to fix outstanding problems, which is why I (and GPUShader) asked. However, I appreciate that D3D11 applications are not expected to query the version of D3D11 that is installed, so you are limited in what you can fix.
That leaves me with a number of concerns. I appreciate that we are now outside the scope of this topic, but since you are involved with the DX team (and since I have no other contacts), please advise where I should take these problems:
1) D3DX11CreateEffectFromMemory appears to be absent from "d3dx11_42.dll". A version exists in "[Program Files]\Microsoft DirectX SDK (August 2009)\Utilities\Source\Effects11" but it has bugs, is not in the form of a dll (and so can only be used with C/C++), and might not be redeployable.
2) The fxc compiler with the Aug 2009 SDK is taking 7 minutes to compile a pixel shader that took only around 45 seconds with the previous SDK [Edit Oct 12th : Times estimates replaced with actual values after tests were carried out with various SDKs]. Cutting the shader down, there appears to be no single cause: it just compiles the whole lot slowly. 7 minutes (or 10 minutes for that group of shaders) is too long to iterate the very complex numerical maths that this shader performs (we are doing real time anatomical simulation, mesh generation and deformation on the GPU). Where can I report and discuss fxc issues?
Regarding your point about looking forward:
A problem with the D3D11 "shared texture" approach is that it doesn't work well with existing software architectures. For example, when upgrading our D3D9 graphics library with a D3D10.1 device I could change routines that used to draw 2D objects by creating 3D primitives to call D2D1 instead. However with the D3D11 shared surface method this is more difficult. Firstly I have to worry whether calling AcquireSync on the mutex hundreds or thousands of times per frame is a good idea in terms of good GPU/CPU usage. Secondly, the results are different. With the D3D10.1 approach, the 2D interleaves correctly with non-depth buffered 3D. This is important in some of our applications. With the D3D11 "single shared texture" approach, the 2D is put on top of all other 3D.
JB.
---
PS: I suspect that we have hit the limit of D2D1 performance, so I don't want to draw this out unnecessarily. However, for your information:
Profiling my application shows that the time appears to be spent mostly in the CPU, not GPU. Approx 3/4 of time is spent in DrawText calls, and most of the remainder in EndDraw. D2D1 is presented as a "high performance" way of drawing text, but from my results this is not the case in terms of speed - and indeed why should it be much faster than GDI, because GDI was not deliberatly inefficient. D2D1 is probably faster than GDI+. Why D3DXFont was so fast is a mystery, though they may have cached each letter of the alphabet, which may not be possible with D2D1/DirectWrite given its support for underlining etc. However the documentation should make this clear.
Quotes like "In fact, with the exception of a few specific operations such as per-primitive anti-aliasing, you'd be hard pressed to outperform Direct2D with Direct3D" (Kenny Kerr) are misleading. For 2D line/shape drawing D2D1 is about the same speed as any other not-particularly-optimized D3D approach.
[Edit: I've done some more thorough tests now. In my tests, non-filled rectangles were slow - about 1/10th the speed of the D3D "line list" equivalents. Filled rectangles were fast, and achieved 81% of the expected pixel rate of the graphics card.]
Caching text layers is not a great performance winner for us because most of the text does indeed change every frame. Using multithreading is an interesting idea, but we already have two threads that are effectively real time (graphics (40 ms/frame) and force feedback (3 ms frame max)) and that would limit us to using quad (or more) cores/processors.
For the sake of progress for Direct3D, please ensure that all my concerns in this discussion are filed as developer feedback for D3D11/D2D1 (or alternatively tell me how/where to file them).
Sincerely,
JB.
[Edited by - JB2009 on October 12, 2009 8:03:18 AM]