On 01/15/2014 12:47 PM, Eric Anholt wrote: > Kenneth Graunke <kenn...@whitecape.org> writes: > >> libdrm 2.4.52 introduces a new 'uint64_t offset64' field, intended to >> replace the old 'unsigned long offset' field. To preserve ABI, libdrm >> continues to store the presumed offset in both locations. >> >> On Broadwell, a 64-bit kernel may place BOs at "high" (> 4G) addresses. >> However, with a 32-bit userspace, the 'unsigned long offset' field will >> only be 32-bit, which is not large enough to hold this value. We need >> to use a proper uint64_t (like the kernel does). >> >> Technically, a lot of this code doesn't affect Broadwell, so we could >> leave it using the old field. But it makes sense to just switch to the >> new, properly typed field. > > This series is: > > Reviewed-by: Eric Anholt <e...@anholt.net> > > I was concerned about brw_program_reloc returning uint32_t still, except > that on gen5+ it's always just returning the incoming prog_offset from > the state base address.
>From our conversation on IRC, it sounded like you had some ideas for creating a newer/better libdrm API for doing relocations, which would replace this. Did you give up on that? --Ken _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
