<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 11/19/2011 11:54 PM, Jerome Glisse wrote:
<blockquote
cite="mid:CAH3drwZLuSgrdzP_Qa=uFQgutHik9aGpg6nm8p0p5LWaSSEiCg@mail.gmail.com"
type="cite"><br>
<blockquote type="cite">
<pre wrap="">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;
}
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<br>
I've iterated the pros of this approach at least two times before, but
for completeness let's do it again:<br>
<br>
8<----------------------------------------------------------------------------------------------------<br>
<pre wrap="">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.
</pre>
8<-----------------------------------------------------------------------------------------------------<br>
<br>
And some extra items like partially populated TTMs that were mentioned
elsewhere.<br>
<br>
<br>
<blockquote
cite="mid:CAH3drwZLuSgrdzP_Qa=uFQgutHik9aGpg6nm8p0p5LWaSSEiCg@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<br>
Yes for <big>Radeon</big> 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.<br>
<br>
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?<br>
<br>
/Thomas<br>
<br>
</body>
</html>