<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div class="moz-cite-prefix">On 01/11/2023 17:33, Dani Liberman wrote:<br>
</div>
<blockquote type="cite" cite="mid:PR1PR02MB4761814952E677B0354DDF0BAFA7A@PR1PR02MB4761.eurprd02.prod.outlook.com">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-ligatures:standardcontextual;
mso-fareast-language:EN-US;}span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}div.WordSection1
{page:WordSection1;}</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]-->
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Hi,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">As part of the upstream review of the Xe driver, I reviewed the XE code which relates to the DRM scheduler. Here are the issues/questions:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="en-IL">guc exec queue states:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="en-IL">1. Please elaborate on the states as they are very fundamental part of the guc submission (banned, destroyed, etc..).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="en-IL">2. guc state is an atomic variable but there is no locking in the sched
</span><span lang="EN-US">related </span><span lang="en-IL">code and the state can be changed right after getting it. Why not change it to non atomic variable?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="en-IL"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="en-IL">guc_exec_queue_run_job():<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="en-IL">1. if (!exec_queue_killed_or_banned(q) && !xe_sched_job_is_error(job))</span><span lang="EN-US">: in case this condition is false, and the job is not submitted. Why still returning fence instead of NULL?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="en-IL">2. I think that register_engine() shouldn't be part of run_job:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="en-IL"> - It is part of the init procedure so I think it is more appropriate to put it in guc_exec_queue_init().<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="en-IL"> - Not sure if it's possible but the guc status updates
</span><span lang="EN-US">a</span><span lang="en-IL">synchronously and if exec_queue got unregistered (after g2h XE_GUC_ACTION_DEREGISTER_CONTEXT_DONE) while in the middle of run_job, we might register it again.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="en-IL">3. </span><span lang="EN-US">LR</span><span lang="en-IL">: AFAIU LR exec_queue will use the drm sched only once and we don't care about the result (from drm POV). Maybe in LR mode, it's better to move the submit_exec_queue()
right after emit_job() in xe_exec_ioctl() and<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="en-IL"> not using drm sched at all.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="en-IL"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="en-IL">guc_exec_queue_start(): using deprecated function drm_sched_resubmit_jobs().<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="en-IL"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Dani<o:p></o:p></span></p>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>