public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Dave Airlie <airlied@linux.ie>,
	linux-kernel@vger.kernel.org, dri-devel@lists.sf.net
Subject: Re: [git pull] drm: previous pull req + 1.
Date: Sun, 21 Jun 2009 22:24:16 +0100	[thread overview]
Message-ID: <1245619456.4937.35.camel@tiger> (raw)
In-Reply-To: <1245595658.4805.17.camel@localhost>

On Sun, 2009-06-21 at 17:47 +0300, Maxim Levitsky wrote:
> > 52dc7d32b88156248167864f77a9026abe27b432 is first bad commit
> > commit 52dc7d32b88156248167864f77a9026abe27b432
> > Author: Chris Wilson <chris@chris-wilson.co.uk>
> > Date:   Sat Jun 6 09:46:01 2009 +0100

The error here seems to be my presumption that only the i915 was using
fences for GPU access. (In hindsight, it seems obvious that we do not
know why the fence was allocated for the object and so if it has
outstanding rendering, we must assume that it is using a fence for a
rendering op.)

To confirm, please can you try:

diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index fd2b8bd..0735518 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2347,7 +2347,7 @@ i915_gem_object_put_fence_reg(struct
drm_gem_object *obj)
         * therefore we must wait for any outstanding access to complete
         * before clearing the fence.
         */
-       if (!IS_I965G(dev)) {
+       if (1) {
                int ret;
 
                i915_gem_object_flush_gpu_write_domain(obj);

(I'm travelling tomorrow, so if this does turn out to be the fault, I'd
appreciate it if someone wrote it up as a complete patch.)

> However I can't reproduce the situation I have earlier, maybe I have changed some settings, don't know.
> Now, the bad behavior (and I reproduced it many times, is that GE shows incorrect textures 
> (like they are divided in tiny interlaced rows, one row ok, other contain image from other part of world), only few textures are such
> it seems logical that this is related to tiling.

What you describe is exactly the artefact you would see when you access
a tiled texture using linear addressing. Pretty conclusive evidence that
we do need to flush outstanding GPU access.

> Also, if I maximize it, it hangs. This seems to be a separate bug introduced by these series.

It does seem like a separate bug. Hopefully, we can get a better handle
on it after we fix this obnoxious tiling issue.
-ickle


  reply	other threads:[~2009-06-21 21:39 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-20  5:23 [git pull] drm: previous pull req + 1 Dave Airlie
2009-06-21  0:04 ` Maxim Levitsky
2009-06-21  0:42   ` Linus Torvalds
2009-06-21 14:47     ` Maxim Levitsky
2009-06-21 21:24       ` Chris Wilson [this message]
2009-06-22 18:09         ` Maxim Levitsky
2009-06-29  7:57           ` Chris Wilson
2009-06-30  9:49             ` Chris Wilson
2009-07-09 23:11             ` Eric Anholt
2009-06-21  1:33   ` Dave Airlie
2009-06-21  3:41 ` Andy Lutomirski
2009-06-21  5:16   ` Dave Airlie
2009-06-21 12:06     ` Andrew Lutomirski
2009-06-21 16:46     ` Linus Torvalds
2009-06-21 17:13       ` Linus Torvalds
2009-06-21 18:50         ` Andrew Lutomirski
2009-06-21 19:47           ` Linus Torvalds
2009-06-21 21:14             ` Andrew Lutomirski
2009-06-22  0:05               ` Andrew Lutomirski
2009-06-22 19:20                 ` Arnaldo Carvalho de Melo
2009-06-21 22:40             ` Dave Airlie
2009-06-22  8:18               ` Thomas Hellström
2009-06-22  8:30                 ` Dave Airlie
2009-06-22 18:22                 ` Linus Torvalds
2009-06-22 18:59                   ` Andrew Lutomirski
2009-06-22 19:43                     ` Linus Torvalds
2009-06-23  0:01                   ` Benjamin Herrenschmidt
2009-06-23  0:00                 ` Benjamin Herrenschmidt
2009-06-23  0:24                   ` Linus Torvalds
2009-06-23  1:04                     ` Benjamin Herrenschmidt
2009-06-23  1:18                       ` Jesse Barnes
2009-06-23  1:58                         ` Benjamin Herrenschmidt
2009-06-23  2:07                           ` Jesse Barnes
2009-06-23  2:26                             ` Benjamin Herrenschmidt
2009-06-23 15:40                               ` Jesse Barnes
2009-06-23  7:48                         ` Michel Dänzer
2009-06-23 15:39                           ` Jesse Barnes
2009-06-23 16:28                             ` Jesse Barnes
2009-06-22 23:57             ` Benjamin Herrenschmidt
2009-06-21 22:41       ` Dave Airlie

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=1245619456.4937.35.camel@tiger \
    --to=chris@chris-wilson.co.uk \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.sf.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maximlevitsky@gmail.com \
    --cc=torvalds@linux-foundation.org \
    /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