All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/915: Pad GTT views of exec objects up to user specified size
Date: Thu, 22 Oct 2015 15:15:55 +0100	[thread overview]
Message-ID: <5628EF9B.1000307@linux.intel.com> (raw)
In-Reply-To: <1445441098-12528-1-git-send-email-chris@chris-wilson.co.uk>


Hi,

On 21/10/15 16:24, Chris Wilson wrote:
> Our GPUs impose certain requirements upon buffers that depend upon how
> exactly they are used. Typically this is expressed as that they require
> a larger surface than would be naively computed by pitch * height.
> Normally such requirements are hidden away in the userspace driver, but
> when we accept pointers from strangers and later impose extra conditions
> on them, the original client allocator has no idea about the
> monstrosities in the GPU and we require the userspace driver to inform
> the kernel how many padding pages are required beyond the client
> allocation.
>
> v2: Long time, no see

[snip]

> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index 08e047cba76a..678f7d5320ae 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -691,10 +691,11 @@ struct drm_i915_gem_exec_object2 {
>   #define EXEC_OBJECT_NEEDS_GTT	(1<<1)
>   #define EXEC_OBJECT_WRITE	(1<<2)
>   #define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1<<3)
> -#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_SUPPORTS_48B_ADDRESS<<1)
> +#define EXEC_OBJECT_PAD_TO_SIZE	(1<<4)
> +#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_PAD_TO_SIZE<<1)
>   	__u64 flags;
>
> -	__u64 rsvd1;
> +	__u64 rsvd1; /* pad_to_size */
>   	__u64 rsvd2;
>   };

What do you think about:

union {
	__u64 pad_to_size;
	__u64 rsvd1;
} ?

Kind of like a migration path for userspace?

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2015-10-22 14:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-21 15:24 [PATCH] drm/915: Pad GTT views of exec objects up to user specified size Chris Wilson
2015-10-22  8:04 ` Daniel Vetter
2015-10-22  8:40   ` Chris Wilson
2015-10-22  9:00 ` Tvrtko Ursulin
2015-10-22  9:09   ` Daniel Vetter
2015-10-22 14:15 ` Tvrtko Ursulin [this message]
2015-10-22 16:07   ` Chris Wilson
2015-10-23  9:50     ` Tvrtko Ursulin
2015-10-26 16:00       ` Tvrtko Ursulin
2015-10-26 17:05         ` Chris Wilson
2015-11-03 10:57           ` Tvrtko Ursulin

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=5628EF9B.1000307@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.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 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.