Re: [PATCH] drm/ttm: pass buffer object for bind/unbind callback

[Thomas Hellstrom <thellstrom@vmware.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3131 bytes --]

On 11/19/2011 11:54 PM, Jerome Glisse wrote:
>
>> As mentioned previously, and in the discussion with Ben, the page tables
>> would not need to be rebuilt on each CS. They would be rebuilt only on the
>> first CS following a move_notify that caused a page table invalidation.
>>
>> move_notify:
>> if (is_incompatible(new_mem_type)) {
>>   bo->page_tables_invalid = true;
>>   invalidate_page_tables(bo);
>> }
>>
>> command_submission:
>> if (bo->page_tables_invalid) {
>>    set_up_page_tables(bo);
>>    bo->page_tables_invalid = false;
>> }
>>      
> Why is it different from updating page table in move notify ? I don't
> see any bonus here, all the information we need are already available
> in move_notify.
>
>    

I've iterated the pros of this approach at least two times before, but 
for completeness let's do it again:

8<----------------------------------------------------------------------------------------------------

1) TTM doesn't need to care about the driver re-populating its GPU page
tables.
Since swapin is handled from the tt layer not the bo layer, this makes it a
bit easier on us.
2) Transition to page-faulted GPU virtual maps is straightforward and
consistent. A non-page-faulting driver sets up the maps at CS time, A
pagefaulting driver can set them up directly from an irq handler without
reserving, since the bo is properly fenced or pinned when the pagefault
happens.
3) A non-page-faulting driver knows at CS time exactly which
page-table-entries really do need populating, and can do this more
efficiently.

8<-----------------------------------------------------------------------------------------------------

And some extra items like partially populated TTMs that were mentioned 
elsewhere.


>> Memory types in TTM are completely orthogonal to allowed GPU usage. The GPU
>> may access a bo if it's reserved, fenced or pinned, regardless of its
>> placement.
>>
>> A TT memory type is a *single* GPU aperture that may be mapped from the
>> aperture side by the CPU (AGP). It may also be used by a single unmappable
>> aperture that wants to use TTM's range management and eviction (vmwgfx GMR).
>> The driver can define more than one such memory type (psb), but a bo can
>> only be placed in one of those at a time, so this approach is unsuitable for
>> multiple apertures pointing to the same pages.
>>      
> radeon virtual memory have a special address space, the system address
> space, it's managed by ttm through a TTM_TT (exact same code as
> current one). All the other address space are not managed by ttm but
> we require a bo to be bound to ttm_tt to be use, thought we can relax
> that. That's the reason why i consider system placement as different.
>
>    

Yes for Radeon system memory may be different, and that's fine. But as 
also previously mentioned we're trying to design a generic interface 
here, in which we need to consider GPU- mappable system memory.

I think the pros of this interface design compared to populating in 
bo_move are pretty well established, so can you please explain why you 
keep arguing against it? What is it that I have missed?

/Thomas


[-- Attachment #1.2: Type: text/html, Size: 3797 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel