Hi Ben: Thank you for your quick response. We will follow the direction to file bug. The reason we knew the GPU hangs on 0x64 is because the head of the render ring buffer is equal to the ox64 and never move again. That means the next data or instruction GPU CS fetches should be 0x64. We also agree with you that this is only an estimation and not very accurate because of GPU unsyn nature as you pointed out. The driver we use is 3.0 based driver but we merged it with 3.5 in Intel_ringbuffer.c file for ring buffer flush. If you let's know what is the state register we can use to detect why the GPU hangs there, it will be great help for us. In term of TLB INVALIDATE flags in PIPE_CONTROL command, you are right we did not get the latest patch. One question is even 3.0 driver works fin for IVB platform in the past, why we need so many workarounds now to make the IVB GPU to work? Hope you can help to explain. Regards, David -----Original Message----- From: Ben Widawsky [mailto:ben at bwidawsk.net] Sent: Monday, August 20, 2012 8:06 PM To: Liu, Ying2 Cc: intel-gfx at lists.freedesktop.org; Meng, David Subject: Re: glxdemo/glxpixmap doesn't work, please help On Tue, 21 Aug 2012 00:49:17 +0000 "Liu, Ying2" <ying2.liu at intel.com> wrote: > We are running mesademo on Ivybridge platform. Glxdemo/glxpixmap > doesn't work. > > If somebody could help us out, that would be great. Please do not send HTML e-mail to the mailing list. > > > > The followings are the command dump from ring buffer when glxdemo and > glxpixmap are runing: > > Address GPU commands Meaning > > 0x0 7a000003 PIPE_COTROL > > 0x4 0x100002 DWORD 1 > > 0x8 0x21084 DWORD 2 > > 0xc 0x0 DWORD 3 > > 0x10 0x0 DWORD 4 > > 0x14 0x0 DWORD 5 > > 0x18 0x7a000003 PIPE_COTROL > > 0x1c 0x4000 DWORD 1 > > 0x20 0x21084 DWORD 2 > > 0x24 0x0 DWORD 3 > > 0x28 0x0 DWORD 4 > > 0x2c 0x0 DWORD 5 > > 0x30 0x7a000003 PIPE_CONTROL > > 0x34 0x1c1d DWORD 1 > > 0x38 0x21084 DWORD 2 > > 0x3c 0x0 DWORD 3 > > 0x40 0x0 DWORD 4 > > 0x44 0x0 DWORD 5 > > 0x48 0x18800080 MI_BATCH_BUFFER_START > > 0x4c 0x768000 BATCH_BUFFER_OFFSET > > 0x50 0x7a000003 PIPE_CONTROL > > 0x54 0x100002 DWORD 1 > > 0x58 0x21084 DWORD 2 > > 0x5c 0x0 DWORD 3 > > 0x60 0x0 DWORD 4 > > 0x64 0x0 DWORD 5 > > 0x68 0x7a000003 PIPE_CONTROL > > 0x6c 0x4000 DWORD 1 > > 0x70 0x21084 DWORD 2 > > 0x74 0x0 DWORD 3 > > 0x78 0x0 DWORD 4 > > 0x7c 0x0 DWORD 5 > > > > The batch buffer contains 3D render commands and data from glxdemo (or > glxpixmap). The GPU hangs at address 0x64. That means all commands > in batch buffer are completed but GPU is waiting for some flushes to > finish in the pipe_control command. Could you help me figure out is > there any thing wrong in this command sequence from the ring buffer? > > > > Thank you so much > > > > Ying > > First, if you have a hang, there should be associated error state. Can you please submit the error state somewhere. Here are directions for filing bugs: http://intellinuxgraphics.org/how_to_report_bug.html I'm just eyeballing it, so this may be off, but I think you're running an old driver because I don't think you have the new TLB INVALIDATE flags in the right places. I'm not sure if the patches went into -fixes, or -queued. These are pretty recently added and fix some known issues. The following would be answered with the error state, but moving past that too for a moment... you say you hang at 0x64. You need to be more specific than that. How do you know you are hung there? At least the debug registers I am aware of only tell how far the Command Streamer has fetched, and parsed. The GPU does not execute the commands synchronously, and so PIPE_CONTROL is used to make sure the commands are executed and their side effects flushed. As an example of the above, if you invoke a shader in a batch which has an infinite loop, your program would hang at the PIPE_CONTROL. -- Ben Widawsky, Intel Open Source Technology Center
