<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 3, 2019 at 9:57 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 9:36 AM Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> wrote:<br>
><br>
> On Wed, Apr 3, 2019 at 9:06 AM Ilia Mirkin <<a href="mailto:imirkin@alum.mit.edu" target="_blank">imirkin@alum.mit.edu</a>> wrote:<br>
>><br>
>> 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>
><br>
><br>
> Or we can add PIPE_CAP_PREFER_COMPUTE_BLIT as a performance hint.<br>
<br>
When would a driver set that, and when would a state tracker respect it?<br>
<br>
As I see it, if the driver prefers compute blits, it can just do that<br>
in its ->blit impl. If the state tracker created a<br>
PIPE_CONTEXT_COMPUTE_ONLY context, then it can also decide to not use<br>
->blit(). I don't see what the CAP adds, but perhaps I'm missing<br>
something.<br></blockquote><div><br></div><div>util_compute_blit was only validated for vaapi. Using it in the driver is risky. PIPE_CAP_PREFER_COMPUTE_BLIT would be the hint for vaapi.</div><div><br></div><div>Marek</div></div></div>