On to, 2017-04-13 at 01:01 +0000, Li, Weinan Z wrote: > > > > -----Original Message----- > > From: Joonas Lahtinen [mailto:joonas.lahtinen@xxxxxxxxxxxxxxx] > > Sent: Wednesday, April 12, 2017 6:19 PM > > To: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>; Li, Weinan Z > > <weinan.z.li@xxxxxxxxx> > > Cc: intel-gfx@xxxxxxxxxxxxxxxxxxxxx; intel-gvt-dev@xxxxxxxxxxxxxxxxxxxxx > > Subject: Re: [PATCH] drm/i915/gvt: return the actual aperture size > > under gvt environment > > > > On ke, 2017-04-12 at 09:53 +0100, Chris Wilson wrote: > > > > > > On Wed, Apr 12, 2017 at 04:36:57PM +0800, Weinan Li wrote: > > > > > > > > > > > > I915_GEM_GET_APERTURE ioctl is used to probe aperture size from > > userspace. > > > > > > > > > > > Some applications like OpenCL use this information to know how much > > > > GM resource can it use. > > > > > > That's a userspace bug. > > > > Yes, a new property might be in place. I don't think we can go and change the > > meaning of a parameter just like that. > > > > <SNIP> > > > Here I don’t want to change the meaning of I915_GEM_GET_APERTURE, but for the ioctl, > We need to return the actual available aperture size exclude the reserved space by GVT balloon. IOCTLs represent the ABI contract we have with userspace. It has previously returned size of the aperture, so we can't change it to be something else (like the usable size of aperture as proposed here). Somebody might be doing an assert that any address in aperture is below I915_GEM_GET_APERTURE returned value, which has previously been correct, but would be broken after this change. There are also potentially other things consuming the aperture than VGT ballooning, so the UMDs would still be misbehaving. Shouldn't they rather be doing these decisions based on aper_available_size? Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
