On 01/13/2014 03:56 PM, Kenneth Graunke wrote:
> 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 BO
Kenneth Graunke writes:
> On 01/15/2014 12:47 PM, Eric Anholt wrote:
>> Kenneth Graunke 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 b
On 01/15/2014 12:47 PM, Eric Anholt wrote:
> Kenneth Graunke 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
Kenneth Graunke 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) add
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 user
