On Wed, Jan 28, 2015 at 10:59:28AM +0100, Daniel Vetter wrote: > On Mon, Jan 26, 2015 at 04:43:18AM -0800, Rodrigo Vivi wrote: > > When constructing a batchbuffer, it is sometimes crucial to know the > > largest hole into which we can fit a fenceable buffer (for example when > > handling very large objects on gen2 and gen3). This depends on the > > fragmentation of pinned buffers inside the aperture, a question only the > > kernel can easily answer. > > > > This patch extends the current DRM_I915_GEM_GET_APERTURE ioctl to > > include a couple of new fields in its reply to userspace - the total > > amount of space available in the mappable region of the aperture and > > also the single largest block available. > > > > This is not quite what userspace wants to answer the question of whether > > this batch will fit as fences are also required to meet severe alignment > > constraints within the batch. For this purpose, a third conservative > > estimate of largest fence available is also provided. For when userspace > > needs more than one batch, we also provide the culmulative space > > available for fences such that it has some additional guidance to how > > much space it could allocate to fences. Conservatism still wins. > > > > The patch also adds a debugfs file for convenient testing and reporting. > > > > v2: The first object cannot end at offset 0, so we can use last==0 to > > detect the empty list. > > > > v3: Expand all values to 64bit, just in case. > > Report total mappable aperture size for userspace that cannot easily > > determine it by inspecting the PCI device. > > > > v4: (Rodrigo) Fixed rebase conflicts. > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> > > Do we have the libdrm patch for this too? Imo there's not much use in this > if mesa remains broken, especially since this is for gen2/3 ... most DE > use gl nowadays. Mesa on gen2/3 is broken full stop as it cannot handle the full desktop size anyway. Just like Broadwell. There was a user ready to go and waiting. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
