* glxdemo/glxpixmap doesn't work, please help
@ 2012-08-21 0:49 Liu, Ying2
2012-08-21 3:05 ` Ben Widawsky
0 siblings, 1 reply; 5+ messages in thread
From: Liu, Ying2 @ 2012-08-21 0:49 UTC (permalink / raw)
To: intel-gfx@lists.freedesktop.org; +Cc: Liu, Ying2, Meng, David
[-- Attachment #1.1: Type: text/plain, Size: 2233 bytes --]
We are running mesademo on Ivybridge platform. Glxdemo/glxpixmap doesn't work.
If somebody could help us out, that would be great.
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
[-- Attachment #1.2: Type: text/html, Size: 9737 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: glxdemo/glxpixmap doesn't work, please help 2012-08-21 0:49 glxdemo/glxpixmap doesn't work, please help Liu, Ying2 @ 2012-08-21 3:05 ` Ben Widawsky 2012-08-21 5:54 ` Meng, David 0 siblings, 1 reply; 5+ messages in thread From: Ben Widawsky @ 2012-08-21 3:05 UTC (permalink / raw) To: Liu, Ying2; +Cc: intel-gfx, Meng, David On Tue, 21 Aug 2012 00:49:17 +0000 "Liu, Ying2" <ying2.liu@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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: glxdemo/glxpixmap doesn't work, please help 2012-08-21 3:05 ` Ben Widawsky @ 2012-08-21 5:54 ` Meng, David 2012-08-23 2:55 ` Ben Widawsky 0 siblings, 1 reply; 5+ messages in thread From: Meng, David @ 2012-08-21 5:54 UTC (permalink / raw) To: Ben Widawsky, Liu, Ying2; +Cc: intel-gfx@lists.freedesktop.org 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@bwidawsk.net] Sent: Monday, August 20, 2012 8:06 PM To: Liu, Ying2 Cc: intel-gfx@lists.freedesktop.org; Meng, David Subject: Re: [Intel-gfx] glxdemo/glxpixmap doesn't work, please help On Tue, 21 Aug 2012 00:49:17 +0000 "Liu, Ying2" <ying2.liu@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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: glxdemo/glxpixmap doesn't work, please help 2012-08-21 5:54 ` Meng, David @ 2012-08-23 2:55 ` Ben Widawsky 2012-08-23 5:04 ` Meng, David 0 siblings, 1 reply; 5+ messages in thread From: Ben Widawsky @ 2012-08-23 2:55 UTC (permalink / raw) To: Meng, David; +Cc: Liu, Ying2, intel-gfx@lists.freedesktop.org On Tue, 21 Aug 2012 05:54:42 +0000 "Meng, David" <david.meng@intel.com> wrote: > 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. There are too many variables to even try to guess. The delta between 3.0 and 3.5 is HUGE as I'm sure you know. Timing related issues are the generic, we don't know, response... so it must be a timing issue ;-) > > Regards, > > David > > > > -----Original Message----- > From: Ben Widawsky [mailto:ben@bwidawsk.net] > Sent: Monday, August 20, 2012 8:06 PM > To: Liu, Ying2 > Cc: intel-gfx@lists.freedesktop.org; Meng, David > Subject: Re: [Intel-gfx] glxdemo/glxpixmap doesn't work, please help > > On Tue, 21 Aug 2012 00:49:17 +0000 > "Liu, Ying2" <ying2.liu@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 > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: glxdemo/glxpixmap doesn't work, please help 2012-08-23 2:55 ` Ben Widawsky @ 2012-08-23 5:04 ` Meng, David 0 siblings, 0 replies; 5+ messages in thread From: Meng, David @ 2012-08-23 5:04 UTC (permalink / raw) To: Ben Widawsky; +Cc: Liu, Ying2, intel-gfx@lists.freedesktop.org Hi Ben: Thanks for the further response. Could you explain what type timing issue will be? Any clue will be great help. We are not using Linux kernel. But I doubt this is kernel related issue. It looks like a GPU issue. Regards, David -----Original Message----- From: Ben Widawsky [mailto:ben@bwidawsk.net] Sent: Wednesday, August 22, 2012 7:55 PM To: Meng, David Cc: Liu, Ying2; intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] glxdemo/glxpixmap doesn't work, please help On Tue, 21 Aug 2012 05:54:42 +0000 "Meng, David" <david.meng@intel.com> wrote: > 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. There are too many variables to even try to guess. The delta between 3.0 and 3.5 is HUGE as I'm sure you know. Timing related issues are the generic, we don't know, response... so it must be a timing issue ;-) > > Regards, > > David > > > > -----Original Message----- > From: Ben Widawsky [mailto:ben@bwidawsk.net] > Sent: Monday, August 20, 2012 8:06 PM > To: Liu, Ying2 > Cc: intel-gfx@lists.freedesktop.org; Meng, David > Subject: Re: [Intel-gfx] glxdemo/glxpixmap doesn't work, please help > > On Tue, 21 Aug 2012 00:49:17 +0000 > "Liu, Ying2" <ying2.liu@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 > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-08-23 5:04 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-08-21 0:49 glxdemo/glxpixmap doesn't work, please help Liu, Ying2 2012-08-21 3:05 ` Ben Widawsky 2012-08-21 5:54 ` Meng, David 2012-08-23 2:55 ` Ben Widawsky 2012-08-23 5:04 ` Meng, David
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.