All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Weinehall <david.weinehall@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	"Zou, Nanhai" <nanhai.zou@intel.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	"Song, Ruiling" <ruiling.song@intel.com>,
	"Vetter, Daniel" <daniel.vetter@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"Yang, Rong R" <rong.r.yang@intel.com>,
	"beignet@lists.freedesktop.org" <beignet@lists.freedesktop.org>
Subject: Re: [Beignet] Preventing zero GPU virtual address allocation
Date: Fri, 13 Mar 2015 11:10:56 +0200	[thread overview]
Message-ID: <5502A9A0.1000209@intel.com> (raw)
In-Reply-To: <20150309120218.GD23680@nuc-i3427.alporthouse.com>

On 2015-03-09 14:02, Chris Wilson wrote:
> On Mon, Mar 09, 2015 at 02:34:46AM +0000, Zou, Nanhai wrote:
>> We don't need MAP_FIXED, we just want to avoid address 0 to be allocated.
>>
>> Though I think using MAP_FIXED is overkill, will bring much unnecessary complexity on both kernel and beignet side.
>> I don't mind if people can provide stable MAP_FIXED patches to resolve this problem a few months or years later.
>>
>> At that time, kernel driver can revert the reserve page 0 patch.
>> Before that reserve page 0 can benefit all the Beignet user without breaking anything.
>
> The point is that is becomes ABI. So no the kernel can't just revert it.
> There is nothing special about address 0 in ether GTT or virtual memory.
> If you require a special object allocated at address 0, allocate a
> special object at address 0.

I've explained the ABI issue in a separate e-mail discussion, and I 
believe that they now fully understand what you meant.

That said, their main chain of reasoning makes some sense -- there is a
race condition if we rely on using MAP_FIXED, at least on systems that
do not support ppgtt. Ending up in a situation where opencl applications 
work on other hw, but fails when run on an i915-system would, at least 
in my opinion, not be ideal, no matter if it's due to an unfortunate design.

*If* a MAP_FIXED solution is decided upon, how can userland be sure that 
the GTT page mapped to 0 is indeed usable as the NULL pointer?
ON a PPGTT system that would be easy enough -- it's per process, so 
we'll be the only process allocating a page at 0, but if allocations
use a global address space that won't be possible to guarantee.

I realise that the first submitted patch didn't cover the GTT case, 
since the first indication I got was that not only was there a special 
case for GTT to need page 0 for other things, but also that this was 
"good enough" for opencl, but it seems that a full solution would be needed.

Since this is a memory area we're talking about it's not uncommon to 
have the 0th page represent the NULL pointer and impossible for 
applications to reserve, so it would hardly be an unusual and 
inexplicable solution.

All this said, how do "the other two" (NVidia, ATI) deal with this?
Implicit NULL-page, explicit MAP_FIXED allocation, or something else?


Kind regards, David
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

  parent reply	other threads:[~2015-03-13  9:10 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-05  2:56 Preventing zero GPU virtual address allocation Song, Ruiling
2015-03-05 12:52 ` [Intel-gfx] " Daniel Vetter
2015-03-05 13:01   ` Chris Wilson
2015-03-05 15:27     ` [Intel-gfx] " Daniel Vetter
2015-03-05 21:07       ` Chris Wilson
2015-03-09 15:46         ` Jesse Barnes
2015-03-09 15:49           ` Jesse Barnes
2015-03-06  2:11       ` [Intel-gfx] " Zou, Nanhai
2015-03-06  8:39         ` [Beignet] " Chris Wilson
2015-03-09  2:34           ` Zou, Nanhai
2015-03-09 12:02             ` [Intel-gfx] " Chris Wilson
2015-03-10  1:57               ` Zou, Nanhai
2015-03-13  9:10               ` David Weinehall [this message]
2015-03-13  9:18                 ` Chris Wilson
2015-03-13  9:27                 ` Daniel Vetter
2015-03-13 16:58                   ` [Beignet] " Chris Wilson
2015-03-13 17:13                     ` [Intel-gfx] " Daniel Vetter
2015-03-13 17:34                       ` [Beignet] " Chris Wilson
2015-03-13 17:49                         ` [Intel-gfx] " Daniel Vetter
2015-03-16  2:29                       ` [Beignet] " Song, Ruiling
2015-03-16  8:52                         ` Daniel Vetter
2015-03-16 20:10                           ` Jesse Barnes
2015-03-17  1:19                             ` [Intel-gfx] " Zhigang Gong
2015-03-17  2:29                             ` Zou, Nanhai
2015-03-17 15:13                               ` [Beignet] " Jesse Barnes
2015-03-19  3:22                                 ` [Intel-gfx] " Song, Ruiling
2015-03-19 10:09                                   ` [Beignet] " David Weinehall
2015-03-19 14:58                                     ` Daniel Vetter
2015-03-20  3:01                                       ` Song, Ruiling
2015-03-17 10:01                             ` Daniel Vetter
2015-03-16 20:11                           ` Jesse Barnes

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=5502A9A0.1000209@intel.com \
    --to=david.weinehall@intel.com \
    --cc=beignet@lists.freedesktop.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=nanhai.zou@intel.com \
    --cc=rong.r.yang@intel.com \
    --cc=ruiling.song@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 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.