Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

Adept I

This is what I get while using CodeXL for GPU profiling...

Unable to gather profile data. This error can occur for one of several reasons:

  • The active project is not an OpenCL or a DirectCompute program.
  • The active project is an OpenCL program, but it did not make any "enqueue" calls.
  • The active project does not compile or run properly (try running it manually).
  • You do not have write access to the profile output directory.

1. It is an OpenCL program.

2. It does make "enqueue" calls.

3. It perfectly runs manually.

4. I do have write access to the profile output directory.

8 Replies

Hi pbcpbt,

Can you please share some information about your program and environment:

  • Which APU/GPU are you using?
  • Which driver version are you using?
  • Which OS are you using?
  • What profile session type did you attempt to run (Performance Counters/Application Trace)?
  • Can you share your program binary file so we can investigate this issue with it?



It wanted a couple of shared libs in its working directory.

It says my limiting factor is VGPR (8 out of 248) - what does it mean?


The number of active wavefronts is affected by the number of 'vector general purpose registers' (VGPRs) used by the dispatched kernel. As the number of VGPRs used increases, the number of active wavefronts decreases in steps. You may benefit from modifying your kernel code to use less VGPRs.

See the following subjects in CodeXL help:

'GPU Profiler Kernel Occupancy Viewer' and 'GPU Profiler Kernel Occupancy' under CodeXL Modules -> CodeXL GPU Profiler User Guide -> Using the GPU Profiler.

Is there any practical guide how to use less VGPRs available?


After several runs CodeXL started to hang with the following message:

*** glibc detected *** /home//////my_program.x: corrupted double-linked list: 0x0000000001386370 ***

after reloading a couple of times it works again.

It hung again while doing GPU Performance counters


Could you please provide the callstack when CodeXL crashed.


When I run my code on Turks, CodeXL shows kernel occupancy 87.5% and limiting factor VGPRs. Number of VGPRs is 8.

On Tahiti its 100% occupancy and no limiting factors. Number of VGPRs is 13, SGPRs is 28.

Could you please comment on that.


The compiler may optimize the kernel differently based on device info, that explains the VGPR and SGPR usage difference. To be more specific, Turks is from northern island family and it doesn't have SGPR, however, it's VGPR is 128 bit wide. Tahiti is from southern island family with the GCN architecture, it's VGPR is 32 bit wide, what's why it uses more VGPRS.

The occupancy is determined by number of active waves that can fit into a compute unit. 100% occupancy on Tahiti means more waves can be in-flight.