public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Ben Widawsky <benjamin.widawsky@intel.com>,
	Intel GFX <intel-gfx@lists.freedesktop.org>,
	Rafael Barbalho <rafael.barbalho@intel.com>
Subject: Re: [PATCH] drm/i915: Support 64b relocations
Date: Mon, 5 May 2014 16:06:21 +0200	[thread overview]
Message-ID: <20140505140621.GL20800@phenom.ffwll.local> (raw)
In-Reply-To: <20140501080450.GF3438@nuc-i3427.alporthouse.com>

On Thu, May 01, 2014 at 09:04:50AM +0100, Chris Wilson wrote:
> On Mon, Apr 28, 2014 at 05:18:28PM -0700, Ben Widawsky wrote:
> > All the rest of the code to enable this is in my branch. Without my
> > branch, hitting > 32b offsets is impossible. The code has always
> > "supported" 64b, but it's never actually been run of tested. This change
> > doesn't actually fix anything. [1] I am not sure why X won't work yet. I
> > do not get hangs or obvious errors.
> > 
> > There are 3 fixes grouped together here. First is to remove the
> > hardcoded 0 for the upper dword of the relocation. The next fix is to
> > use a 64b value for target_offset. The final fix is to not directly
> > apply target_offset to reloc->delta. reloc->delta is part of ABI, and so
> > we cannot change it. As it stands, 32b is enough to represent everything
> > we're interested in representing anyway. The main problem is, we cannot
> > add greater than 32b values to it directly.

Imo if you have a target_offset > 32b in a valid use-case we can bother to
look at this. But not before, since I expect that hw advances will make
this obsolete anyway.

> > [1] Almost all of intel-gpu-tools is not yet ready to test 64b
> > relocations. There are a few places that expect 32b values for offsets
> > and these all won't work.
> > 
> > Cc: Rafael Barbalho <rafael.barbalho@intel.com>
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
> 
> Seriously, we did this? I am ashamed. I was annoyed by the original
> assertion that no userspace was ready in the first place, and to see
> that the code was a complete farce anyway...

Well my idea was that we try to prep userspace to avoid a needless abi
rev, but it was always clear to me that the kernel side (and igt) is
hopelessly broken for 64b relocs.

> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

      reply	other threads:[~2014-05-05 14:06 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-29  0:18 [PATCH] drm/i915: Support 64b relocations Ben Widawsky
2014-04-29  1:11 ` [PATCH] drm/i915: Expand error state's address width to 64b Ben Widawsky
2014-04-29  1:43   ` [PATCH] [v2] " Ben Widawsky
2014-04-29  1:45     ` [PATCH] intel_error_decode: use 64b gtt_offset Ben Widawsky
2014-04-29  8:52       ` Daniel Vetter
2014-04-29  9:01         ` Daniel Vetter
2014-04-29 10:48           ` Chris Wilson
2014-04-29 11:05             ` Daniel Vetter
2014-04-30  0:54           ` Ben Widawsky
2014-05-01  8:06     ` [PATCH] [v2] drm/i915: Expand error state's address width to 64b Chris Wilson
2014-04-29  2:21   ` [PATCH] [v3] " Ben Widawsky
2014-04-29  2:29   ` [PATCH] drm/i915: Support 64b execbuf Ben Widawsky
2014-05-01  8:12     ` Chris Wilson
2014-05-01 10:18       ` Barbalho, Rafael
2014-05-05 14:02         ` Daniel Vetter
2014-05-01  8:04 ` [PATCH] drm/i915: Support 64b relocations Chris Wilson
2014-05-05 14:06   ` Daniel Vetter [this message]

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=20140505140621.GL20800@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=benjamin.widawsky@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=rafael.barbalho@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