   Learn DX11 or Opengl?
  I have learn DX9 some time and write some tiny code....I feel DX better.But i also found some problem that i can't solve.......For example:1. I write some code for Shadow Map. when i use D3DDEVTYPE_REF, the result is correct, but when i don't use D3DDEVTYPE_REF, the result is wrong. But i can't found why, because the HRESULT(return from DX9 API call) is all SUCCEEDED.2. When i compile and run DX9 app in VC2005, the app is correct. But when i run compiled app(outside VC2005), the app exception and aborted...3. When i run compiled DX9 program is OK, but when i use PIX for Windows to load the DX9 program, exception occur and program abort, so i can't debug the VS and PS. 4. In Pix for Windows, The float type only have Three decimal places(0.xxx), but in Render Target(Shadow map), the Precision is at least five decimal places(0.xxxxxx), so i can't know the results are correct or not?Recently, i buy a new PC. i want to learn DX11 continue. But when i carefully think about problem about DX9, i want to learn OPENGL. In Opengl, debug shader is easy? Are there have better shader debugger tools for OPENGL. I want to listen to your views.Thanks.i can speek english a little, please don't mind......   
  There's really not any special way you can debug a shader in OpenGL either. I don't know anything about those four problems you've listed, but I'm sure you'll find some quirks in OpenGL as well.I use it and find it to be fairly straightforward and easy, but I don't know if you'll find it any easier than DX (especially if you already know the API).   ;  I don't think any of the things you mentioned is a reason to switch APIs. It's almost guaranteed that you're going to encounter problems of this sort no matter what API you're using - switching to OpenGL probably isn't going to help much in this regard.I don't know much about shader debugging in OpenGL, but FWIW, I've found the Direct3D debugging and diagnostic tools to be pretty hard to beat. Like karwosts, I don't have answers for the specific problems you mentioned, but it sounds like some of them at least might just be basic Windows development and deployment issues (e.g. not having your app configured correctly, not having resources or libraries in the right place, etc.).Maybe someone with more DX experience will recognize the problems you've described and will be able to help...   ;  For GLSL debugging, I came across this recently (but I haven't tried it yet):www.vis.uni-stuttgart.de/glsldevil;  1: The reference rasterizer supports the entire feature set of the API. It is very possible that you simply use a feature that isn't supported by your hardware. You can query for hardware capabilities from the IDirect3D9 object. Do note that you need to read documentation of each operation you do in order to determine what capabilities you need. That said -- in programming, reading documentation is effectively mandatory anyway. 2:You are probably trying to load an external resource file during the execution of the program. You can't assume anything about file paths outside Visual Studio. It is possible to determine the path of the currently running executable by using GetModuleFileName and stripping out the filename from the returned string. This is a common approach to establishing resource loading paths during runtime.You can prevent crashing altogether by carefully checking the return values of the API functions as well as the interface pointers that they return. Statistically, most D3D-related crashes are caused by access violations as the program tries to use invalid pointers.3:-Instead of PIX, have you enabled the D3D debug runtime and examined the debug output stream of your program? It gives a lot of warnings if your API handling is faulty.-PIX itself has some bugs, so it is possible that the crash is actually related to using it. However, experience tells me that you should first suspect your own app instead of your tools.-Have you updated your graphics drivers? Faulty drivers can cause all kinds of troubles seemingly related to D3D.4:This is a formatting issue in PIX. The design intent in the data visualizers in PIX has been that the user can check whether the data is somewhat correct (that is, no adverse logic bugs).You can dump most D3D resources to system memory manually from within your own program, so you can then do any checks against the data on the CPU side. However, depth buffers in particular are difficult since their internal format depends on the hardware in D3D9, and are therefore not normally lockable by D3D standard methods. For this, you'd need to use hardware-specific hacks to get access to the depth data.Incidentally, D3D11 lets you interpret the GPU memory in somewhat unrestricted way. You could just dump any resources to system memory directly without IHV-specific hacking.   