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

Eric Anholt eric at anholt.net
Mon Jan 13 23:41:11 PST 2014


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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140113/857e5ad7/attachment.pgp>


More information about the mesa-dev mailing list