[Mesa-dev] [libdrm PATCH] intel: Create a new drm_intel_bo offset64 field.

Ben Widawsky ben at bwidawsk.net
Tue Jan 14 10:29:54 PST 2014


On Mon, Jan 13, 2014 at 11:41:11PM -0800, Eric Anholt wrote:
> Kenneth Graunke <kenneth at whitecape.org> writes:
> 
> > The existing 'offset' field is unfortunately typed as 'unsigned long',
> > which is unfortunately only 4 bytes with a 32-bit userspace.
> >
> > Traditionally, the hardware has only supported 32-bit virtual addresses,
> > so even though the kernel uses a __u64, the value would always fit.
> >
> > However, Broadwell supports 48-bit addressing.  So with a 64-bit kernel,
> > the card virtual address may be too large to fit in the 'offset' field.
> >
> > Ideally, we would change the type of 'offset' to be a uint64_t---but
> > this would break the libdrm ABI.  Instead, we create a new 'offset64'
> > field to hold the full 64-bit value from the kernel, and store the
> > 32-bit truncation in the existing 'offset' field, for compatibility.
> >
> > Cc: Eric Anholt <eric at anholt.net>
> > Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
> > Cc: Ben Widawsky <ben at bwidawsk.net>
> > Signed-off-by: Kenneth Graunke <kenneth at whitecape.org>
> > ---
> >  intel/intel_bufmgr.h     | 12 +++++++++---
> >  intel/intel_bufmgr_gem.c | 16 ++++++++++------
> >  2 files changed, 19 insertions(+), 9 deletions(-)
> >
> > I didn't update the bufmgr_fake stuff.  Do I need to...?
> 
> Nope.  Also, this was less patch than I was originally imagining it
> would be.  Sweet.
> 
> Reviewed-by: Eric Anholt <eric at anholt.net>
> 
> Maybe some day we'll do a symbol-versioned fork of the code without all
> the compatibility insanity, and with other 4G limits fixed.  I don't
> think we have any instances of sharing drm_intel_bos across build-system
> boundaries.  Anyone want to correct me on that?

libva?

As a small correction to all the current mails - the current limit is
2G, not 4. There is a 4G patch series which won't be merged until PPGTT
is merged.

Anyway, patch is also:
Reviewed-by: Ben Widawsky <ben at bwidawsk.net>

I can review the mesa patch as well if needed - but I am not the best
person for that.

-- 
Ben Widawsky, Intel Open Source Technology Center


More information about the mesa-dev mailing list