Re: [Beignet] Preventing zero GPU virtual address allocation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux