Kenneth Graunke <kenn...@whitecape.org> writes: > 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?
I've got a patch laying around, but I wrote it without your patch and I need to rebase. I also got distracted by the "busy" performance fix. Of course, it doesn't let us get rid of the mesa presumed offset code yet, but if we can get rid of the subdata-upload path of batches now that CACHED_BATCH is going away, that would be the next step.
pgppDLWoUCTJo.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
