<div dir="ltr">
<div>Hi!</div><div>I use GPUVis and now Intel Vtune Profiler. These 
tools don't work out-of-the-box on all Linux based systems for Intel 
integrated graphics.</div><div>It is needed to rebuild at least i915 
module. And each time when the kernel is updated it is needed to rebuild
 i915 module again.</div><div><br></div><div>> No numbers from (micro-)bechmarks showing how small the impact of doing<br></div><div>> this is? I thought John was compiling this data. It will be just a no-op<br></div><div>> on the fast path, but a bit more generated code.</div><div>Have you collected the results? If not, I've done it for you:</div><div>
Benchmark

for Metro 2033 Last Light Redux:</div><div>w/o events:</div><div>1st run aver. fps: 36.06</div><div>2nd run aver. fps: 35.87</div><div>w events:</div><div>
<div>1st run aver. fps: 36.05</div><div>2nd run aver. fps: 35.92</div><div><br></div><div>There is no difference. It was run on Intel Core i9-9900K CPU @ 3.60GHz on integrated graphics.</div><div><br></div><div>> Assuming that will be fine, the only potentially problematic aspect that <br></div><div>> comes to mind is the fact meaning of these tracepoints is a bit <br></div><div>> different between execlists and guc. But maybe that is thinking to low <br></div><div>> level (!) - in fact they are in both cases at points where i915 is <br></div><div>>passing/receiving requests to/from hardware so not an issue?</div><div>In my view, it is not an issue. The real issue now that you cannot collect performance results for Intel GPU<br></div><div>on Linux systems without rebuilding the i915 module. You cannot debug performance problems</div><div> on the system even if you use tools from Intel. Do you have ETA to accept this patch?<br></div><div><br></div><div>Thanks,</div><div>Egor</div></div>

</div>