On Mon, May 08, 2017 at 01:18:38PM +0300, Joonas Lahtinen wrote: > On ma, 2017-05-08 at 02:49 +0000, Li, Weinan Z wrote: > > Hi Joonas/Chris, do you have any comments? > > I've asked OCL team for this patch, they also agree to use available aperture size > > for max allocation buffer definition, code confirmation ongoing. > > The patch title should be corrected to refer to usable aperture size. > > > > -----Original Message----- > > > From: Li, Weinan Z > > > Sent: Wednesday, May 3, 2017 8:51 AM > > > > > To: intel-gfx@xxxxxxxxxxxxxxxxxxxxx; intel-gvt-dev@xxxxxxxxxxxxxxxxxxxxx > > > > > Cc: Li, Weinan Z <weinan.z.li@xxxxxxxxx> > > > Subject: [PATCH v3] drm/i915/gvt: return the actual aperture size under gvt > > > environment > > > > > > I915_GEM_GET_APERTURE ioctl is used to probe aperture size from userspace. > > > In gvt environment, each vm only use the ballooned part of aperture, so we > > > should return the actual available aperture size exclude the reserved part by > > > balloon. > > > > > > v2: add 'reserved' in struct i915_address_space to record the reserved size in > > > ggtt by balloon. > > > > > > v3: remain aper_size as total, adjust aper_available_size exclude reserved and > > > pinned. UMD driver need to adjust the max allocation size according to the > > > available aperture size but not total size. Only adjusting aper_available_size prevents the immediate breakage wrt to libdrm_intel, but I'm worried about the fragility of userspace using this. What is it being used for? I doubt this is the right information for them, and generally whether it's a correct assumption by userspace. What happened to reporting the correct size via CONTEXT_PARAM_GTT_SIZE which doesn't have the same issues with userspace incorrectly using GGTT for PPGTT? -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
