[Intel-gfx] glxdemo/glxpixmap doesn't work, please help

[Meng, David]

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: [Intel-gfx] 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