On Wed, Apr 3, 2019 at 9:57 AM Ilia Mirkin <imir...@alum.mit.edu> wrote:
> On Wed, Apr 3, 2019 at 9:36 AM Marek Olšák <mar...@gmail.com> wrote: > > > > On Wed, Apr 3, 2019 at 9:06 AM Ilia Mirkin <imir...@alum.mit.edu> wrote: > >> > >> On Wed, Apr 3, 2019 at 8:38 AM Marek Olšák <mar...@gmail.com> wrote: > >> > > >> > On Tue, Apr 2, 2019 at 2:14 PM Eric Anholt <e...@anholt.net> wrote: > >> >> > >> >> Ilia Mirkin <imir...@alum.mit.edu> writes: > >> >> > >> >> > Shouldn't this sort of decision be left up to the driver? If the > >> >> > driver would like to use CS for blits, fine, but why not let it > blit > >> >> > in the most optimal way possible and force it to use a compute > shader? > >> >> > >> >> Yeah, commit messages require an explanation of why a change is being > >> >> made. > >> > > >> > > >> > We plan to create vaapi contexts with PIPE_CONTEXT_COMPUTE_ONLY for > better GPU multitasking. > >> > > >> > 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) > >> > >> Makes sense. Sounds like one of those would be a better condition than > >> the mere existence of compute support then? > > > > > > Or we can add PIPE_CAP_PREFER_COMPUTE_BLIT as a performance hint. > > When would a driver set that, and when would a state tracker respect it? > > As I see it, if the driver prefers compute blits, it can just do that > in its ->blit impl. If the state tracker created a > PIPE_CONTEXT_COMPUTE_ONLY context, then it can also decide to not use > ->blit(). I don't see what the CAP adds, but perhaps I'm missing > something. > 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. Marek
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
