On 7 August 2015 at 20:57, Ilia Mirkin <imirkin@xxxxxxxxxxxx> wrote: > On Fri, Aug 7, 2015 at 5:45 AM, Michel Thierry <michel.thierry@xxxxxxxxx> wrote: >> Gen8+ supports 48-bit virtual addresses, but some objects must always be >> allocated inside the 32-bit address range. >> >> In specific, any resource used with flat/heapless (0x00000000-0xfffff000) >> General State Heap or Intruction State Heap must be in a 32-bit range >> (GSH / ISH), because the General State Offset and Instruction State Offset >> are limited to 32-bits. >> >> Use drm_intel_bo_emit_reloc_48bit when the 4GB limit is not necessary, and >> the bo can be in the full address space. >> >> This commit introduces a dependency of libdrm 2.4.63, which introduces the >> drm_intel_bo_emit_reloc_48bit function. >> >> v2: s/48baddress/48b_address/, >> Only use in OUT_RELOC64 cases, OUT_RELOC implies a 32-bit address offset >> is needed (Ben) >> v3: Added OUT_RELOC64_INSIDE_4G, so it stands out when a 64-bit relocation >> needs the 32-bit workaround (Chris) >> >> References: http://lists.freedesktop.org/archives/intel-gfx/2015-July/072612.html >> Cc: Ben Widawsky <ben@xxxxxxxxxxxx> >> Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> >> Signed-off-by: Michel Thierry <michel.thierry@xxxxxxxxx> >> --- >> configure.ac | 2 +- >> src/mesa/drivers/dri/i965/gen8_misc_state.c | 19 +++++++++++-------- >> src/mesa/drivers/dri/i965/intel_batchbuffer.c | 20 ++++++++++++++++---- >> src/mesa/drivers/dri/i965/intel_batchbuffer.h | 10 ++++++++-- >> 4 files changed, 36 insertions(+), 15 deletions(-) >> >> diff --git a/configure.ac b/configure.ac >> index af61aa2..c92ca44 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -68,7 +68,7 @@ AC_SUBST([OSMESA_VERSION]) >> dnl Versions for external dependencies >> LIBDRM_REQUIRED=2.4.38 >> LIBDRM_RADEON_REQUIRED=2.4.56 >> -LIBDRM_INTEL_REQUIRED=2.4.60 >> +LIBDRM_INTEL_REQUIRED=2.4.63 > > There is no such version. I think you need a release before you can > commit this. Otherwise you'll cause pain for a whole lot of people. > Afaics Michel explicitly covered the way things will/should be merged in the cover letter. -Emil _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
