[Mesa-dev] [Mesa PATCH 2/3] i965: Use the new drm_intel_bo offset64 field.

[Eric Anholt]

Kenneth Graunke <kenneth at whitecape.org> writes:

> On 01/15/2014 12:47 PM, Eric Anholt wrote:
>> Kenneth Graunke <kenneth at 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 <eric at 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.
-------------- 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/20140116/f08a2432/attachment.pgp>