<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 3, 2019 at 9:06 AM Ilia Mirkin <<a href="mailto:imirkin@alum.mit.edu">imirkin@alum.mit.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Apr 3, 2019 at 8:38 AM Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> wrote:<br>
><br>
> On Tue, Apr 2, 2019 at 2:14 PM Eric Anholt <<a href="mailto:eric@anholt.net" target="_blank">eric@anholt.net</a>> wrote:<br>
>><br>
>> Ilia Mirkin <<a href="mailto:imirkin@alum.mit.edu" target="_blank">imirkin@alum.mit.edu</a>> writes:<br>
>><br>
>> > Shouldn't this sort of decision be left up to the driver? If the<br>
>> > driver would like to use CS for blits, fine, but why not let it blit<br>
>> > in the most optimal way possible and force it to use a compute shader?<br>
>><br>
>> Yeah, commit messages require an explanation of why a change is being<br>
>> made.<br>
><br>
><br>
> We plan to create vaapi contexts with PIPE_CONTEXT_COMPUTE_ONLY for better GPU multitasking.<br>
><br>
> RadeonSI uses async compute queues if PIPE_CONTEXT_COMPUTE_ONLY is set, so it can't do any graphics stuff, not even blit. (pipe_context::blit is NULL)<br>
<br>
Makes sense. Sounds like one of those would be a better condition than<br>
the mere existence of compute support then?<br></blockquote><div><br></div><div>Or we can add PIPE_CAP_PREFER_COMPUTE_BLIT as a performance hint.</div><div><br></div><div>Marek</div></div></div>