<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:DengXian;
        panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:"\@DengXian";
        panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0cm;
        margin-right:0cm;
        margin-bottom:0cm;
        margin-left:36.0pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle20
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:785545619;
        mso-list-template-ids:-1229917000;}
@list l0:level1
        {mso-level-start-at:2;
        mso-level-tab-stop:36.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l1
        {mso-list-id:1060176832;
        mso-list-template-ids:260495024;}
@list l2
        {mso-list-id:1520854713;
        mso-list-type:hybrid;
        mso-list-template-ids:-1783088106 269025297 269025305 269025307 269025295 269025305 269025307 269025295 269025305 269025307;}
@list l2:level1
        {mso-level-text:"%1\)";
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l2:level2
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l2:level3
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l2:level4
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l2:level5
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l2:level6
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l2:level7
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l2:level8
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l2:level9
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l3
        {mso-list-id:1794131315;
        mso-list-template-ids:912432556;}
@list l3:level1
        {mso-level-start-at:4;
        mso-level-tab-stop:36.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l4
        {mso-list-id:2144037335;
        mso-list-template-ids:1697430470;}
@list l4:level1
        {mso-level-start-at:3;
        mso-level-tab-stop:36.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
ol
        {margin-bottom:0cm;}
ul
        {margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-CA" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Also + Christian<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal">Oak<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Intel-xe <intel-xe-bounces@lists.freedesktop.org>
<b>On Behalf Of </b>Zeng, Oak<br>
<b>Sent:</b> August 14, 2023 11:38 PM<br>
<b>To:</b> Thomas Hellström <thomas.hellstrom@linux.intel.com>; Brost, Matthew <matthew.brost@intel.com>; Vishwanathapura, Niranjana <niranjana.vishwanathapura@intel.com>; Welty, Brian <brian.welty@intel.com>; Felix Kuehling <felix.kuehling@amd.com>; Philip
 Yang <Philip.Yang@amd.com>; intel-xe@lists.freedesktop.org; dri-devel@lists.freedesktop.org<br>
<b>Subject:</b> [Intel-xe] Implement svm without BO concept in xe driver<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hi Thomas, Matt and all,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This came up when I port i915 svm codes to xe driver. In i915 implementation, we have i915_buddy manage gpu vram and svm codes directly call i915_buddy layer to allocate/free vram. There is no gem_bo/ttm bo concept involved in the svm implementation.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In xe driver,  we have drm_buddy, xe_ttm_vram_mgr and ttm layer to manage vram. Drm_buddy is initialized during xe_ttm_vram_mgr initialization. Vram allocation/free is done through xe_ttm_vram_mgr functions which call into drm_buddy layer
 to allocate vram blocks.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I plan to implement xe svm driver the same way as we did in i915, which means there will not be bo concept in the svm implementation. Drm_buddy will be passed to svm layer during vram initialization and svm will allocate/free memory directly
 from drm_buddy, bypassing ttm/xee vram manager. Here are a few considerations/things we are aware of:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top:0cm" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l2 level1 lfo3">This approach seems match hmm design better than bo concept. Our svm implementation will be based on hmm. In hmm design, each vram page is backed by a struct page. It is very easy
 to perform page granularity migrations (b/t vram and system memory). If BO concept is involved, we will have to split/remerge BOs during page granularity migrations.<o:p></o:p></li></ol>
<p class="MsoListParagraph"><o:p> </o:p></p>
<ol style="margin-top:0cm" start="2" type="1">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l2 level1 lfo3">We have a prove of concept of this approach in i915, originally implemented by Niranjana. It seems work but it only has basic functionalities for now. We don’t have advanced features
 such as memory eviction etc.<o:p></o:p></li></ol>
<p class="MsoListParagraph"><o:p> </o:p></p>
<ol style="margin-top:0cm" start="3" type="1">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l2 level1 lfo3">With this approach, vram will divided into two separate pools: one for xe_gem_created BOs and one for vram used by svm. Those two pools are not connected: memory pressure from one
 pool won’t be able to evict vram from another pool. At this point, we don’t whether this aspect is good or not.<o:p></o:p></li></ol>
<p class="MsoListParagraph"><o:p> </o:p></p>
<ol style="margin-top:0cm" start="4" type="1">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l2 level1 lfo3">Amdkfd svm went different approach which is BO based. The benefit of this approach is a lot of existing driver facilities (such as memory eviction/cgroup/accounting) can be reused<o:p></o:p></li></ol>
<p class="MsoListParagraph"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Do you have any comment to this approach? Should I come back with a RFC of some POC codes?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal">Oak<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>