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
