Re: [PATCH v3 16/17] drm/i915: Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset

[Michel Thierry <michel.thierry@intel.com>]

On 7/1/2015 4:43 PM, Chris Wilson wrote:
> On Wed, Jul 01, 2015 at 04:27:32PM +0100, Michel Thierry wrote:
>>
>> +	flags |= PIN_ZONE_4G;
>> +	if (entry->flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS)
>> +		flags &= ~PIN_ZONE_4G;
>> +
>>   	if (!drm_mm_node_allocated(&vma->node)) {
>>   		if (entry->flags & __EXEC_OBJECT_NEEDS_MAP)
>>   			flags |= PIN_GLOBAL | PIN_MAPPABLE;
>>   		if (entry->flags & __EXEC_OBJECT_NEEDS_BIAS)
>>   			flags |= BATCH_OFFSET_BIAS | PIN_OFFSET_BIAS;
>> +		if ((flags & PIN_MAPPABLE) == 0)
>> +			flags |= PIN_HIGH;
>
> I'm still debating the right semantics to use, but I'm happy with this
> until I can find something better. (The biggest issue is that drm_mm is
> not indexed for fast top-down searching. The current search code I put
> into drm_mm is unfortunately broken, the idea I have in mind to fix it is
> to add a hole_list into drm_mm/drm_mm_node, so that we can just walk
> holes in up/down, recent/old order. And with that allocating top-down
> will not be any more expensive than the current reuse recent hole -
> though perhaps given a fragment drm_mm the hole stack probably requires
> fewer steps to find a large hole.)
>
> Other than don't touch PIN_OFFSET_MASK and move the w/a note next to
> where we tweak the PIN_ZONE_4G, it lgtm, so with those changes,

Also the comment should be "limit address to the first 4GBs for 
_unflagged_ objects". I didn't update it after changing the logic.

I'll resend with these changes.

Thanks,
>
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> -Chris
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx