You are here:

Release Notes

Nsight Tegra, Visual Studio Edition, version 3.5

New Features:

Linux for Tegra

Initial support

Android

Support for Android NDK64 r14
Support for API 24
Various performance improvements and bug fixes

Fixed Issues:

General

Nsight Tegra no longer intermittently fails to detect process architecture.

Android

Debugging will no longer fail if class.dex is too big.
Gradle build no longer fails if the <sdk>\build-tools folder contains an android-X.Y subfolder.
Users no longer get an error that AndroidLogView failed to load settings.

Other Changes

Android

Support for multiple Java sources/classes paths for debugging.

Known Issues:

Android

Java Out of Memory

On some systems, ANT will report a memory error when building inside of Visual Studio. You may encounter the following error:

Could not create the Java virtual machine.
Error occurred during initialization of VM
Could not reserve enough space for object heap

In this case, try restarting your web browser; it has been known to help in some cases.

Other Known Issues:

Nsight Tegra is incompatible with an official Helix plug-in for Visual Studio-Perforce integration.
For very large libraries, timeouts may start to occur; if you encounter this, try adjusting your global timeout options. This is accessed via the NVIDIA logo icon on the Nsight Tegra toolbar, or through the menu Tools > Options. We are striving to continue to reduce the need to adjust these values.
Inserting breakpoints in a header file may result in long delays because a breakpoint may be inserted into each object file section within the library and could easily results in hundreds or thousands of actual breakpoints.
For new projects, the NDK Target API Level will now be set to the Java Minimum API Level. This is because users who have their Java Target API Level set to 21 (Android 5.0) — to match Google’s compatibility guarantee — are finding that their apps will not function properly on Android 4.x, due to library incompatibilities. This will only affect new projects, as we have also introduced an NDK target API level override property, to guarantee the same behavior for upgraded projects.
If a file does not affect the project up-to-dateness, open its Property Pages, go to the General section and set the Item Type to Android Build System. Alternatively, if you are using a project generator (such as CMake), make it generate items in an AndroidBuild tag instead of None, for example:
<AndroidBuild Include="res\values\strings.xml" />
instead of
<None Include="res\values\strings.xml" />
Projects compiled with GCC that use PCH files great than 150MB may fail to build. This is a known GCC issue.
Debugging doesn't work if External Build System project type (Tegra-Android platform) is added to VC++ Makefile project (Win32 platform). Closing and reopening the solution fixes this issue. (27747)
There is a project property General > Toolchain Version, which allows the user to select the toolchain with which to build the project. Ideally, values in the dropdown list should be shown for the currently selected NDK only; however, toolchains for NDKs r9b - r10e are currently displayed, regardless of the actual NDK. If the selected toolchain is missing from the selected NDK, then an error message will be displayed during the build stage. (26298)
If you are using a library compiled with thumb and receive a SIGSEGV fault, it may be due to a bug in GDB when handling the transitions between arm and thumb modes. To work around this issue, compile in thumb mode. (23930)
Projects upgraded by the Nsight Tegra project upgrader sometimes won’t load due to internal caching in Visual Studio. Restarting Visual Studio will fix this problem.
If you are seeing compiler error messages that seem to imply the properties do not match the ones that you have set, be sure that if you were using .prop files, that those values are up to date. For instance, in later releases of Nsight Tegra. we have removed support for certain SDKs and NDKs that were previously supported.
Nsight Tegra does not assist in gdb.setup directory command generation when the project is built using an *.mk file. You must modify the *.mk file manually to establish the correct directory command arguments. Please consult the Google NDK documentation at <ndk-path>/docs/ANDROID-MK.HTML or APPLICATION-MK.HTML for more assistance. (19518)
Under Project Properties > Debugging, there may be incorrect "Browse..." dialogs. For example, the Override APK dialog may accept *.exe files rather than *.apk files. (19867)
Note that this issue only occurs in Visual Studio 2010, it does not occur in Visual Studio 2012.
A project that is imported with a Java code source path that is different than the path to src will not build. To work around this, you can modify the Java Source Directory property in the Ant Build section. (19489)
Using the Threads window, the Step Over function may not work. (18786)
If you are using ndk-build.cmd, there is an extra "/" in the command line which is sent to the compiler and prevents breakpoints from being hit. To work around this issue, modify your Android.mk file from:
LOCAL_PATH := $(call my-dir)
to:
LOCAL_PATH := $(subst //,/,$(call my-dir)

FAQ

Android

Correcting a broken Ant build

Recent releases of Nsight Tegra have made the following changes:

build.xml and *.properties files are no longer required for a project to build. These files can be safely removed if their customization is not needed.
Existing *.properties, AndroidManifest.xml, or build.xml are no longer modified. This is because it was a frequent issue for people using source control systems.
Support for different ANT setup files based on configuration (debug/release) has been added.
In addition, support for proper output directories based on configuration (debug/release), just as one would normally have with a regular win32/64 project, has been added. This means that the output now goes to Tegra-Android\<config>.

Nsight Tegra has its own proprietary build.xml — named nsight_tegra_build.xml — that runs before the build.xml, and sets properties from within Visual Studio’s project properties. There are two reasons for doing this:

With ANT, the first variable set is the one that is used in both .properties and build.xml files.
Most users' default files come from samples, and already have set properties. This works around options the user may have changed.

To work around this issue and get your forced overrides back in, you would take advantage of these lines that we auto-generate:

<import file="<path>\nsight_tegra_build_overrides_<config>.xml" optional="true" />
<import file="<path>\nsight_tegra_build_overrides.xml" optional="true" />

The first line allows you to do config-specific overrides; the second line contains shared overrides.

From here, you would set your properties, making sure to get the paths you set up in Visual Studio.

You would copy your manifest.xml, making a minor edit to fix the SDK target/min/max numbers.
You would then update all of the output paths, so that an APK per config can be made.
Finally, your normal build.xml will be imported to pick up the rest.

For reference, here is a snip of the actual properties that are overridden.

REGION-BEGIN: The following properties prevent Nsight Tegra from needing to modify user property files. 
Setting them here will ensure they always match Visual Studio and allows users to build without needing to check out version controlled files.-->
<property name="sdk.dir" value="C:\NVPACK\android-sdk-windows" />
<property name="target" value="android-15" />
<property name="source.dir" value="src" />
<!--REGION-END-->
<!--
REGION-BEGIN: The following properties prevent Nsight Tegra from needing to modify user manifest files.
Setting them here will ensure they always match Visual Studio and allows users to build without needing to check out version controlled files.-->
<property name="manifest.file" value="C:\<path>\nsight_tegra_manifest.xml" />
<property name="manifest.abs.file" value="C:\<path>\nsight_tegra_manifest.xml" />
<!--REGION-END-->
<!--
REGION-BEGIN: The following properties allow Nsight Tegra to maintain build results per-configuration (debug, release, etc).-->
<property name="gen.absolute.dir" value="C:\<path>\Tegra-Android\Debug\gen" />
<property name="out.dir" value="C:\<path>\Tegra-Android\Debug\bin" />
<property name="jar.libs.dir" value="C:\<path>\Tegra-Android\Debug\libs" />
<property name="native.libs.absolute.dir" value="C:\<path>\Tegra-Android\Debug\libs" />
<target name="-pre-compile">
<path id="project.all.jars.path">
<path path="${toString:project.all.jars.path}">
<fileset dir="${jar.libs.dir}">
<include name="*.jar" />
</fileset>
</path>
</path>
</target>
<!--REGION-END-->
<!--
Reference in original document.-->
<import file="C:\<path>\build.xml" /> 
</project>