From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: intel-gfx@lists.freedesktop.org, Mika Kuoppala <mika.kuoppala@intel.com>
Subject: Re: [PATCH] lib/rendercopy_gen9: Setup Push constant pointer before sending BTP commands
Date: Thu, 13 Aug 2015 10:33:00 +0300 [thread overview]
Message-ID: <1439451180.4312.12.camel@linux.intel.com> (raw)
In-Reply-To: <20150813013537.GA10075@intel.com>
Hi,
On ke, 2015-08-12 at 18:35 -0700, Ben Widawsky wrote:
> On Wed, Aug 12, 2015 at 03:10:18PM +0300, Joonas Lahtinen wrote:
> > On ke, 2015-08-12 at 12:26 +0100, Arun Siluvery wrote:
> > > From Gen9, by default push constant command is not committed to
> > > the
> > > shader unit
> > > untill the corresponding shader's BTP_* command is parsed. This
> > > is
> > > the
> > > behaviour when set shader is enabled. This patch updates the
> > > batch to
> > > follow
> > > this requirement otherwise it results in gpu hang.
> > >
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89959
> > >
> > > Set shader need to be disabled if legacy behaviour is required.
> > >
> > > Cc: Ben Widawsky <benjamin.widawsky@intel.com>
> > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > > Cc: Mika Kuoppala <mika.kuoppala@intel.com>
> > > Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
> >
> > Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> >
>
> Repeating what I said on the mesa thread:
> Does anyone understand why this actually causes a hang on the IGT
> test? I
> certainly don't. The docs are pretty clear that the constant command
> is not
> committed until the BTP command, but I can't make any sense of how it
> related to
> a GPU hang.
>
Changing the order makes the hang go away and come back for sure, we've
all been experiencing that. System validation said it is a programming
restriction, so I'm not sure how relevant it is what goes wrong if it's
not followed. And the legacy mode bits were added to support the old
behavior of having the order like it has been previously, so I do not
see why question it without visibility to the actual RTL. And enabling
the legacy bits makes the hang go away, too.
If I had the RTL sources, then it would be more relevant to take
educated guesses as to why a set of hundreds of thousands of
transistors doesn't work as it should :) Without that, if it gets
stuck, it gets stuck.
Regards, Joonas
> [snip]
>
> ---
> Ben Widawsky, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-08-13 7:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-12 11:26 [PATCH] lib/rendercopy_gen9: Setup Push constant pointer before sending BTP commands Arun Siluvery
2015-08-12 12:10 ` Joonas Lahtinen
2015-08-13 1:35 ` Ben Widawsky
2015-08-13 7:33 ` Joonas Lahtinen [this message]
2015-08-13 22:49 ` Ben Widawsky
2015-08-14 8:58 ` Daniel Vetter
2015-08-18 14:25 ` Joonas Lahtinen
2015-08-19 1:44 ` Ben Widawsky
2015-08-13 10:06 ` Mika Kuoppala
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1439451180.4312.12.camel@linux.intel.com \
--to=joonas.lahtinen@linux.intel.com \
--cc=benjamin.widawsky@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=mika.kuoppala@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox