cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

merlion
Journeyman III

CodeXL problem: [xcb] Unknown sequence number while processing reply

Hello, I use CodeXL to analyze Rodinia Benchmark Suite. I find that CodeXL can analyze most of the programs, but some programs will get corruption. I do not know why.

This is my running bash script:

  1 program_dir="/home/z/rodinia/"

  2 result_dir="/home/z/rodinia/codexlresult/"

  3 cd $program_dir/nw

  4 make clean

  5 make

  6 /opt/AMD/CodeXL_1.6-7247/x86_64/sprofile -o "$result_dir/7nw.csv" -p -w "$program_dir/nw/" "$program_dir/nw/nw"  4096 10 ./nw.cl 0

This is the error message. Would you tell me what to do? NW is also a simple OpenCL program.

                                                                                                           ^

AMD CodeXL GPU Profiler V3.1.7247 is Enabled

Specified output file /home/pacman/zf/rodinia_1thdparal/codexlresult_cpu0percent//7nw.csv already exists, It will be overwritten.

[xcb] Unknown sequence number while processing reply

[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called

[xcb] Aborting, sorry about that.

nw: ../../src/xcb_io.c:635: _XReply: Assertion `!xcb_xlib_threads_sequence_lost' failed.

Session output path : /home/z/rodinia/codexlresult//7nw.csv

0 Likes
4 Replies
chesik
Staff

Hi merlion,

This is likely caused because the application you are profiling is calling XOpenDisplay.  When collecting performance counters, the driver is also calling XOpenDisplay, and it may be doing so on a different thread.  The CodeXL team has an ongoing discussion about this issue with the driver team, and we are converging on a possible solution.  Until this is solved by either the driver or by CodeXL, the best workaround is to modify the application you are profiling to call XInitThreads before it calls XOpenDisplay (if you have access to the source).

If you take a look at the source code for the Teapot sample that comes with CodeXL, you will see that it has a call to XInitThreads in order to prevent this error from occurring.

Also, can you let me know what hardware you are running on?  As far as I know, the driver code that calls XOpenDisplay when collecting perf counters is only executed when running on the integrated GPU on an APU. Can you confirm that you are using an APU when you see this?

Thanks,

Chris

0 Likes

Thanks Chris, thank you for your timely reply.

The code is very simple and does not call XOpenDisplay or XInitThreads. The program is just do computation.

After initialization, there is a for loop to launch the kernel.

469         for( int blk = 1 ; blk <= worksize/BLOCK_SIZE ; blk++){

470

471                 global_work[0] = BLOCK_SIZE * blk;

472                 local_work[0]  = BLOCK_SIZE;

473                 clSetKernelArg(kernel1, 7, sizeof(cl_int), (void*) &blk);

474                 err = clEnqueueNDRangeKernel(cmd_queue, kernel1, 2, NULL, global_work, local_work, 0, 0, 0);

475                 if(err != CL_SUCCESS) { printf("ERROR: 1  clEnqueueNDRangeKernel()=>%d failed\n", err); return -1; }

476         }

I read the generated csv file. I find that for the first few times, CodeXL can generate data (as follows). Then it corrupt. The times also varied, sometimes 3 times, sometimes 5 times.

My  OS is Linux version 3.13.0-32-generic (buildd@kissel) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ). Does it matters with the OS?

My device is APU A10-7850K.

22 Method, ExecutionOrder, ThreadID, CallIndex, GlobalWorkSize, WorkGroupSize, Time, LocalMemSize, VGPRs, SGPRs, ScratchRegs, FCStacks, Wavefronts, VALUInsts, SALUInsts, VFetchInsts, SFetchInsts, VWriteIn    sts, LDSInsts, GDSInsts, VALUUtilization, VALUBusy, SALUBusy, FetchSize, WriteSize, CacheHit, MemUnitBusy, MemUnitStalled, WriteUnitStalled, LDSBankConflict

23 lud_diagonal__k1_Spectre1, 1, 2439, 22, {     16       1       1}, {   16     1     1},         0.00024, 1024, 42, 26, 0, NA,         1.00,      2736.00,      1047.00,        16.00,         4.00,            15.00,       766.00,         0.00,        10.76,         0.59,         0.11,         9.62,         0.94,         8.88,         1.05,         0.04,         0.00,         0.01

24 lud_perimeter__k2_Spectre1, 2, 2439, 29, {   4064       1       1}, {   32     1     1},         0.17493, 3072, 49, 32, 0, NA,       127.00,      3355.00,      1157.00,        48.00,         8.00,            31.00,       862.00,         0.00,        25.17,        55.55,         9.83,       267.69,       246.06,        28.08,        18.43,         0.28,        16.80,         3.92

25 lud_internal__k3_Spectre1, 3, 2439, 39, {   2032    2032       1}, {   16    16     1},         7.53441, 0, 53, 26, 0, NA,     64516.00,       258.00,        12.00,        23.00,        13.00,             3.00,         0.00,         0.00,       100.00,        56.65,         1.41,     24684.25,     48387.00,        31.31,        71.98,         1.65,         0.52,         0.00

~                         

0 Likes

Hello, Chris,

I add the "XInitThreads();" in the main function and the flags "-lpthread  -std=c++0x -pthread -lX11" , but I still got the same error.

This is the simple OpenCL code.

119 int main(int argc, char* argv[]) {

120   XInitThreads();

[xcb] Unknown request in queue while dequeuing

[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called

[xcb] Aborting, sorry about that.

histo: ../../src/xcb_io.c:179: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.

Session output path: /parboil_codexl/codexl_res//histo.csv

0 Likes

Hi merlion,

Can you try adding --xinitthreads to the sprofile command line:

/opt/AMD/CodeXL_1.6-7247/x86_64/sprofile -o "$result_dir/7nw.csv" -p -w "$program_dir/nw/" --xinitthreads "$program_dir/nw/nw"  4096 10 ./nw.cl 0

You will need CodeXL 1.8 for this to work.  Does that switch make any difference in what you're seeing?

Thanks,

Chris

0 Likes