[Beignet] [Intel-gfx] Preventing zero GPU virtual address allocation

[Jesse Barnes]

On 03/16/2015 01:52 AM, Daniel Vetter wrote:
> On Mon, Mar 16, 2015 at 02:29:24AM +0000, Song, Ruiling wrote:
>>
>>
>>> -----Original Message-----
>>> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
>>> Vetter
>>> Sent: Saturday, March 14, 2015 1:14 AM
>>> To: Chris Wilson; Daniel Vetter; Weinehall, David; Zou, Nanhai; Song, Ruiling;
>>> Vetter, Daniel; intel-gfx at lists.freedesktop.org; Yang, Rong R;
>>> beignet at lists.freedesktop.org
>>> Subject: Re: [Beignet] [Intel-gfx] Preventing zero GPU virtual address
>>> allocation
>>>
>>> On Fri, Mar 13, 2015 at 04:58:47PM +0000, Chris Wilson wrote:
>>>> On Fri, Mar 13, 2015 at 10:27:38AM +0100, Daniel Vetter wrote:
>>>>> If supporting systems without full ppgtt is a requirement for you
>>>>> (still wonky on gen8 a bit, so might be a good strategy) then imo
>>>>> it's the PIN_BIAS idea I've laid out earlier in this thread. That
>>>>> one will work everywhere. softpin can unexpectedly fail without full
>>>>> ppgtt if the kernel decides to put something at a given spot, which
>>>>> imo means we should only expose it on full ppgtt systems.
>>>>>
>>>>> And PIN_BIAS should be fairly easy to wire up since the internal
>>>>> logic is all there already. So "just" needs an execbuf flag, igt
>>>>> test and appropriate userspace to set that new bit.
>>>>
>>>> It doesn't though. To provide the guarantee userspace is asking for
>>>> (which is that address 0 goes to a special, preferrably inaccessible,
>>>> page), you have to evict the first N pages in the GGTT. That is just
>>>> as likely to fail with an execbuffer flag as it would with an execobject flag.
>>>
>>> Afaiui userspace only needs the guarantee that NULL is never a valid address.
>>> Which means it's never a valid address for its own buffer objects. I don't
>>> think it cares one bit what's actually there, it's not mandatory to fault
>>> apparently. And faulting is what's not possible.
>> Yes, This is what exactly what we need, that is make NULL as an invalid address. It's just like C language.
>> But I have some more comment. The buffer object used in opencl may be allocated in libva/opengl and shared for opencl usage through some opencl extension.
>> Afaiui, this would implicitly require libva/mesa also avoid zero-address buffer object allocation.
>> Will libdrm re-bind such kind of shared buffer object to a new graphics virtual address?
>> So that PIN_BIAS is also effective on the shared buffer, right?
> 
> Yeah we'll rebind if needed. We can make this an execbuf or context flag,
> in either case anything that gets executed by ocl will be moved around if
> it accidentally ended up at the wrong place. The only exception is if a
> buffer is pinned already, i.e. if you're doing direct rendering to the
> frontbuffer. That will give you an EBUSY, but otoh that also shouldn't
> ever happen really.

Oh and we may need to re-introduce the ppgtt zero page reservation
anyway due to bugs, but that's another topic...