Trying to debug issues on Intel® Integrated Graphics can be simple provided you understand some very fundamental principles and some of the tools available to the software development community. All methods described in this document are easy to use and can make porting, debugging and developing code for Integrated Graphics as simple as doing so for any graphics hardware out in the market.

First, it must be understood that Intel provides two types of Integrated Graphics solutions, the 3000 series and the X3000 series. As with Intel’s older GMA 900 line the 3000 series still performs Transform and Lighting (TnL) in software (on the CPU) through the Processor Specific Graphics Pipeline (PSGP) in Direct3D’s HAL. The X3000 series performs hardware TnL selectively based on the workload requirements. Some workloads like those based on DirectX8 or earlier versions, are well suited to the CPU-PSGP path in comparison to the DirectX9 pipeline in the X3000 series engine.

One of the most valuable tools for a number of years now is a third party tool call 3dAnalyze (see figure 1).

Figure 1. 3DAnalyze Tool

One of the first things that Intel engineers look for when testing an application that would not run on the 3000 series of graphics is to check if the application has support for software TnL. The application might be assuming hardware TnL support while the 3000 series does not support hardware TnL. The 3DAnalyze* tool provides many useful functions one of which is the ability to “Spoof” an application into believing that the graphics card is capable of Hardware Transform and Lighting. Developers can easily select the emulate HW TnL caps option in the tool (see the top of figure 1) and execute the application directly from 3dAnalyze, to test whether the problem is because the application does not recognize software TnL. If it runs well on the “emulated” HW TnL caps setting, then we can easily narrow the problem as a game issue related to Software TnL support.

Another test is to force Software TnL in 3DAnalyze while having an equivalent midrange graphics card installed. If the application still crashes then the issue is not related to the Intel graphics card or driver, it is a game issue related to supporting Software TnL. If the application does run however, the issue could be a potential Intel driver bug and should be reported on the Intel Integrated Graphics software development forum (located here) and through Intel’s graphics support site.

3dAnalyze* also allows you to select “debug logging” which will create a log file in the directory/folder of the application under test. If either of these appear in the debug file : D3DCREATE_PUREDEVICE or D3DCREATE_HARDWARE_VERTEXPR OCESSING without the ordinal D3DCREATE_SOFTWARE_VERTEXPROCESSING declared along with them, the app will fail on 3000 series graphics. This means the application developer of the Direct3D* application is not supporting software vertex processing.

Another method to detect if the application is selectively choosing not to run on Intel graphics is to use 3dAnalyze* to selectively force the Vendor and Device IDs to that of a graphics card which is known to work. The tool has special edit box fields for this purpose. The whitepaper on the Intel Software Network titled “Common misconceptions of Intel Integrated Graphics” should help remove any apprehensions in the minds of the developer on the capabilities of the Intel Integrated Graphics.

If you suspect that the application might be fill-rate bound the option to disable textures is also available in the tool. This happens more in benchmarks than in games but its available if it is a suspect. This effectively removes textures from the scene, reducing the fill-rate overhead.

If you think that the application is suffering from a Pixel Shader throughput issue, 3dAnalyze* can be used to force the application to default to an older version (i.e. 1.1).

This is a useful technique when debugging pixel shaders on Intel Integrated Graphics.

You need to understand first what the integrated graphics part you are analyzing supports. To do this, use the DX Caps viewer which is included with the Direct X SDK (in the Utilities folder). This will make understanding debug output messages easier. The caps for the part will be located in <Device>->D3D Device Types->HAL->Caps. To further understand a particular cap refer to the Direct X SDK documentation.

One of the most useful techniques for debugging Direct3D* related issues is to first enable the Direct3D* debug runtime. First ensuring that you have the latest DirectX 9.0 SDK* installed on your system (download free from Microsoft). This typically comes out in a bi-monthly refresh. To enable the debug runtime you will need to access the Direct X control panel which is located in the Utilities folder of the SDK.

Remembering to set the runtime back to retail after you’re done testing, you can use a tool like DebugView* or DebugMon* to log error messages to get an understanding for while a particular application may be failing. Do not use 3dAnalyze* or FRAPS* with the debug runtime enabled or change runtime version while these tools are running as doing so will conflict with the working operation of them (they hook into the debug runtime).

Note that PIX only works for Direct3D based applications. For OpenGL* applications, you can use glIntercept. For the purposes of this article, we would concentrate on PIX*. It is a great tool for looking into performance issues as it lets you scope down to individual frames or frame streams. Being the de facto DirectX shader debugger moving forward, getting used to understanding its ins and outs can help any developer.

Figure 2 captures the initial setup screen for debugging an applica tion using PIX

Figure 2. Microsoft PIX

Selecting the advanced view provides additional options. Shader constants and locks on shader constants are a good indicator at performance limiters. In addition, looking at the number of SetRenderTarget calls per frame can help. There might be a huge performance impact if it is called more than once per frame and if you have more than 10 calls per frame it would have a serious effect on performance on Intel integrated graphics.

The most useful method of getting information is to have Single or full frame drops encrypted and sent to http://software.intel.com/en-us/forums/. Preferably, single or full frame PIX samples are preferred for post mortem debug. The extension for Single frames or Full Streams PIX results is the same - .PIXRun. Forwarding them in an encrypted format is the most optimal way to communicate issues from PIX to Intel’s development community. Remember that full stream samples from PIX can be exceptionally large so selectively choosing portions from the stream that are relevant and saving that would have a huge impact in the overall footprint.

It is always advisable to use the latest version of PIX. It is updated on a regular basis. Another feature it provides is single frame capture (on the render stage). Selecting the tool itself (PIXWIN*) is a trick that many developers use to get non-rendering processing removed from the sample. To do so, use the command line option :  “–playstandalone <name>.pixrun”. This is far more suitable for large workloads (i.e. benchmarks and games) but works just fine for smaller ones as well.

Providing a stream file is very useful in trying to debug why your application may not be working, but single frame captures are useful as well. If the recorded stream runs on a non-Intel GPU, there might be an Intel driver bug, which will get immediate attention by the graphics driver team and would be resolved in a future driver release. To provide a stream capture simply select “Call replayable stream” in your experiment.

Another optimization technique is to use triangle strips instead of triangle lists to reduce the VB overhead. This is typically done with the content generation tools like Maya or 3D studio max. This is a general optimization tip that will help your code on all graphics parts.

Careful use of the aforementioned tools can be of great benefit to the developer when trying to debug or develop on any integrated graphics platform. Moreover, knowing the intricacies of Intel integrated graphics will help you expand your customer base to a larger audience than just the highest end graphics solutions.

Mr. DeSylva is a Software Applications Engineering Manager in the Intel Software and Solutions Group. He and his team are responsible for the performance optimization of cutting edge consumer software titles running on Intel Desktop systems. Prior to working on application software optimization, Chuck worked as a driver developer for Intel Corporation. He was involved i n developing/deploying the first device drivers for USB, AGP (GART) and Intel’s first graphics devices (i740/810(e)).