I'm new to Visual Studio 2010, as I was used to compile my CUDA codes with nvcc using Linux as operating system. Incidentally in some posts of this and the NVIDIA Developer Zone forums, I have read warnings on proper compilation in Visual Studio (Debug/Release modes, see link for the difference between the two) to correctly use of the NVIDIA Visual Profiler. In my (poor) understanding, Visual Studio automatically compiles under a "Debug" mode, but for a successful profile the "Release" mode is necessary.
My (simple) questions are:
1) How do I switch from the "Debug" mode to the "Release" mode? Is it enough to use Properties -> Configuration Properties and select "Release" instead of "Active(Debug)"? Also, I noticed that I have to repeat the selection each time I want to Rebuild the project.
2) Is this enough for a correct usage of the Visual Profiler?
Thank you very much in advance.
1) You're switching from Debug to Release in the wrong place. The setting you're using is just for selecting which build settings to view or edit. You should use Build | Configuration Manager or (easier) the Solution Configurations dropdown box in the Standard toolbar. If you don't see the Standard toolbar, right click in the toolbar area by the menu, and select it there. You will find that you don't have to reselect the setting for each build now.
2) The CUDA compiler optimizes aggressively even in Debug mode. I don't know if it matters which configuration you use. Both should work. You can try and see if you get any different results.
See Roger Dahl's answer for how to set the configuration.
There are several forms of profiling.
Performance Profiling
This should definitely be done with optimizations enabled on the CUDA kernel. Disabling optimization and specifying debug information performs more operations than a CPU but it does do other modifications to the code (stack overflow checks) that will impact counters.
Source Level Profiling
This can be done on Debug or Release builds. Nsight 3.0 CUDA Profiler has source level experiments that will show statistics per C source, PTX, or SASS line. The CUDA 5.0 Visual Profiler supports code correlated experiments but will not show the results for every line (only problematic lines). Disabling optimizations will result in significantly more accurate line information for the SASS to PTX to C code mapping. For many analysis cases this is fine. However, if you want to understand the code generation per C line then you should enable full optimizations and heavily look at the SASS code and only use C source and PTX as a guide.
In order to get C source level correlation you need to use the default debug configuration which generates full debug information or use a custom configuration that enable -lineinfo. This option can be enabled using the following steps:
Open Solution Explorer
Right click on your .cu file or project file
Execute the Properties command
In the left pane select the tree node Configuration Properties | CUDA C/C++ | Device
In the right pane change Generate Line Number Information to Yes
In CUDA 5.0 -lineinfo has several small impacts on code generation so it is not advisable to keep this enabled in your Release configuration.
Related
I'm searching for a way to get profiling data on cache misses for my Unity project.
I already searched for visual studio tools that do have these stats. I can see Visual studio has tools for .NET applications that shows cache misses (like what's described here https://learn.microsoft.com/en-us/visualstudio/profiling/cpu-and-windows-counters?view=vs-2017), like its Performance Wizard, but they are always grayed out for my Unity project.
I tried attaching Visual Studio's performance tools to my running Unity projects, but I can't seem to find the data I'm looking for.
Unfortunately, Unity's profiler doesn't seem to show the cache misses stats I'm looking for.
I’m using mono but am open to switching to IL2CPP if that can help, I’m mainly exploring unity performance at this point.
I would like to remove guess work from my optimisations. Is there anything I missed?
Edit 1:
Here's what I tested.
I created a build of my test project with IL2CPP selected in the player options
In visual studio, I went to Debug/Performance Profiler, I selected the "Executable" target and used the option "Performance Wizard".
After clicking "Start" I used the option "Instrumentation", clicked next, used "An executable" for the application I want to profile, clicked next, selected my created build's .exe, clicked next and finish.
I then get a failure saying:
Profiling started.
Instrumenting <my path to my exe> in place
Info VSP3049: Small functions will be excluded from instrumentation.
Microsoft (R) VSInstr Post-Link Instrumentation 15.8.18219.1 x86
Unable to obtain debug information. Link with the /PROFILE linker switch.
PRF0002: Instrumentation failed with these options: /u "<my path to exe> /excludesmallfuncs. Please check the output window for additional details.
Data written to <my path>200126(5).vsp.
Profiling finished.
Profiling complete.
I tried looking into Error VSP1011: Unable to obtain debug information. Link with the /Profile linker switch but I'm not sure it's relevant.
I installed VS2013 and tried the same steps and it gave me the same errors.
I finally found a good tool for this.
Looks like Intel's VTune is pretty easy to use and gives good info. For sure it's sampling and doesn't show the exact information, but it gives me hotspots of things to investigate.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Debug vs. release in .NET
Debug/Release difference
What is the difference between Release and Debug modes in Visual Studio while building a project?
Debug and Release are just labels for different solution configurations. You can add others if you want. A project I once worked on had one called "Debug Internal" which was used to turn on the in-house editing features of the application. You can see this if you go to Configuration Manager... (it's on the Build menu). You can find more information on MSDN Library under Configuration Manager Dialog Box.
Each solution configuration then consists of a bunch of project configurations. Again, these are just labels, this time for a collection of settings for your project. For example, our C++ library projects have project configurations called "Debug", "Debug_Unicode", "Debug_MT", etc.
The available settings depend on what type of project you're building. For a .NET project, it's a fairly small set: #defines and a few other things. For a C++ project, you get a much bigger variety of things to tweak.
In general, though, you'll use "Debug" when you want your project to be built with the optimiser turned off, and when you want full debugging/symbol information included in your build (in the .PDB file, usually). You'll use "Release" when you want the optimiser turned on, and when you don't want full debugging information included.
Well, it depends on what language you are using, but in general they are 2 separate configurations, each with its own settings. By default, Debug includes debug information in the compiled files (allowing easy debugging) while Release usually has optimizations enabled.
As far as conditional compilation goes, they each define different symbols that can be checked in your program, but they are language-specific macros.
The main difference is when compiled in debug mode, pdb files are also created which allow debugging (so you can step through the code when its running). This however means that the code isn't optimized as much.
I'm trying to debug my shaders in Directx 11 SDK application using graphics diagnostics tool in VS2012, however when I click Start Debugging on one of the shaders in Graphics Pixel History panel I'm getting Pixel Shader.pdb not loaded and I'm not able to find the pdb file anywhere.
I tried compiling shaders at runtime using D3DX11CompileFromFile with D3DCOMPILE_DEBUG flag as well as using the HLSL compiler with debugging information turned on (/Od /Zi) but none of these options is producing the pdb file I could use in graphics diagnostics tool.
How do I generate these files?
I think this "Pixel Shader.pdb not loaded" message is misleading. The is no any .pdb files generated by HLSL-compiler. All debug info are integrated into binary (either memory blob or .cso file).
Does your shader file named "Pixel Shader"? Maybe it says not about a shader, but some kind of Visual Studio's internal source files (shader debugger in VS2012 was somewhat unstable sometimes)
Some ideas that, probably, can help you to solve issue:
Make sure that your debug and release output binaries are not messed up. Check both debug and release configuration of project's properties and each shader's properties.
Make sure that you are loading right shader file. Check ten times all file paths.
Clean your project, eliminate all binaries by hand. Rebuild again.
IIRC, in graphics debugger you can only debug shaders, compiled offline (i.e. not by D3DX11CompileFromFile).
Try to compile using fxc.exe directly.
Use filenames that does not contains spaces and special characters.
Make sure your test shader is simple enough, so debugger will not crash. Thy to use default template.
If it's still doesn't works, write a minimal example project, check that it doesn't works, post it here so we can test it.
Try VS2013
Try your videocard vendor's debugging tool (such as NVIDIA nsight or AMD GPU PerfStudio), to see if it is problem with Microsoft tools or not.
Hope it helps somehow.
I have a code of a Plug In from an SDK.
The code is in Debug Mode.
I use Intel Compiler which only applies optimizations in Release Mode.
Under configuration manager of the project only "Debug" mode is defined.
How could I switch to "Release" mode and enable all Intel Compiler's optimizations?
If I enable them on debug mode nothing is applied (Empty Report).
I couldn't find the trick to do so.
Thank You.
P.S.
I do use the /MT switch yet still.
Project configurations are managed by the user, so you can create Release configuration by yourself if it's missing. In the insides, they can differ by compiler options and defines, mostly. When I had very slow PC, I sometimes used configuration I've created, obviously named Debug_Optimized.
For example, Debug configuration usually has DEBUG defined. It makes some lines of code comment out, to speed up the resulting program.
You can usually speed up creation of another configuration by basing it on existing one. Look for all "Perfomance" and "Optimizations" tabs and set them according to your needs. There usually isn't one best configuration (sometimes "optimize for size" is faster than "optimize for speed"). Try these options out.
Ok, here is the solution,
First of all using the /MD or /MD, which is trivial.
Then define NDEBUG.
Pay attention to do this in every file in the project.
In my case, some files were set to /MTd which sets the Debug mode.
I used Intel Compiler and this thread might help:
http://software.intel.com/en-us/forums/topic/328136
I am using Visual Studio 2010 to debug an application mostly written in C. Normally, I can attach the debugger just fine, but I am running in to some problems when I link in a library written in C++ / CLI.
If I compile the library with the /clr flag (which I will eventually have to do for this as of yet unwritten library) then I lose all ability to debug the entire C application, even the parts that have nothing to do with the library calls. I get the empty circle with the yellow triangle and exclamation mark where a red break point circle ought to be. Hovering over it gives me only a tool tip that says "The breakpoint will not currently be hit. No executable code is associated with this line. Possible causes include: conditional compilation or compiler optimizations."
Then if I link with the exact same library compiled without the /clr flag, I am again able to debug my application.
I understand that visual studio will not likely be able to debug the library written in C++ / CLI, and that is OK. I just want to keep the ability to debug the rest of the application and at least see the results of my calls to the external library.
Another complicating factor is that this project is not being built by visual studio. It is compiled using an external make system that uses cl, so I can customize any commands that need to be issued to the compiler that way.
Does anyone know why I can't currently debug the libraries the way I want to? Any advice for how I can?
You have to select the kind of debugger when you attach. Note the "Attach to" label in the dialog. Press the Select button and tick "Native" to get support for debugging native code. The DLL also needs to be loaded before any of your breakpoints can hit. If you are not sure whether or not that was done then look in the Debug > Windows > Modules debugger window to see loaded DLLs. The breakpoint indicator turns from hollow to solid red as soon as the debugger saw the DLL load and armed the breakpoint.
Debugging C++/CLI is otherwise supported, you can tick both the "Managed" and "Native" checkboxes. And set breakpoints in either kind of code. The only thing not supported is single-stepping from managed to native code and back. A mode-switch is required to activate the correct debugging engine, that requires code to hit a breakpoint.
And consider the Debug options in your native project, you can specify an EXE to start. So that you can simply press F5 to start debugging and skip the attach hassle.
It might also have to do with the Debugger Type!
(but that depends on your specific building configuration about which I do not know enough)
If any of your projects is complied with Common Language Runtime Support (/clr) you should set the Debugger Type in your startup project to "Mixed", since the default setting "Auto" might fail!
Imagine, you have two projects:
1) A non-CLR C++ project, which is your startup project that generates some .exe file.
2) A C++ project, that generates mylibrary.dll, which is compiled with Common Language Runtime Support, because it uses some managed code. The .exe from the first project calls mylibrary.dll.
If you start the first project with Debugger Type set to its default value "Auto", you'll be able to debug into the first project, but not into the second one. The debugger selector does not realize that you will be calling a CLR-library.
So set Project Properties -> Configuration Properties -> Debugging -> Debugger Type to "Mixed"!