From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: drm/scheduler for vc5 Date: Mon, 02 Apr 2018 11:49:15 -0700 Message-ID: <87sh8dzbo4.fsf@anholt.net> References: <87o9j572il.fsf@anholt.net> <75063f31-e26d-54a8-ebc7-409b3978560d@amd.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1958845023==" Return-path: Received: from anholt.net (anholt.net [50.246.234.109]) by gabe.freedesktop.org (Postfix) with ESMTP id B1CA06E21E for ; Mon, 2 Apr 2018 18:49:23 +0000 (UTC) In-Reply-To: <75063f31-e26d-54a8-ebc7-409b3978560d@amd.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Christian =?utf-8?Q?K=C3=B6nig?= , dri-devel@lists.freedesktop.org Cc: Alex Deucher List-Id: dri-devel@lists.freedesktop.org --===============1958845023== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Christian K=C3=B6nig writes: > Hi Eric, > > nice to see that the scheduler gets used more and more. > > The feature your need to solve both your binning/rendering as well as=20 > your MMU problem is dependency handling. See the "dependency" callback=20 > of the backend operations. > > With this callback the driver can return dma_fences which need to signal= =20 > (or at least be scheduled if it targets the same ring buffer/fifo). > > Now you need dma_fences as result of your run_job callback for the=20 > binning step anyway. So when you return this fence from the binning step= =20 > as dependency for your rendering step the scheduler does exactly what=20 > you want, e.g. not start the rendering before the binning is finished. > > > The same idea can be used for the MMU switch. As an example on how to do= =20 > this see how the dependency callback is implemented in=20 > amdgpu_job_dependency(): >> =C2=A0=C2=A0 =C2=A0struct dma_fence *fence =3D amdgpu_sync_get_fence(&jo= b->sync,=20 >> &explicit); > > First we get the "normal" dependencies from our sync object (a storage=20 > for fences). > > ... >> =C2=A0=C2=A0=C2=A0 while (fence =3D=3D NULL && vm && !job->vmid) { >> =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0struct amdgpu_ring *ring =3D job->= ring; >> >> =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0r =3D amdgpu_vmid_grab(vm, ring, &= job->sync, >> =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &job->base.s_fence->finished, >> =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 job); >> =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0if (r) >> =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0DRM_ERROR("Erro= r getting VM ID (%d)\n", r); >> >> =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0fence =3D amdgpu_sync_get_fence(&j= ob->sync, NULL); >> =C2=A0=C2=A0 =C2=A0} > > If we don't have any more "normal" dependencies left we call into the=20 > VMID subsystem to allocate an MMU for that job (we have 16 of those). > > This call will pick a VMID and remember that the process of the job is=20 > now the owner of this VMID. If the VMID previously didn't belonged to=20 > the process of the current job all fences of the old process are added=20 > to the job->sync object again. This makes some sense when you have many VMIDs and reuse won't happen very often. I'm concerned that when I effectively have one VMID that I need to keep swapping, then we're creating a specific serialization of the jobs at the time they're submitted to the kernel (dependency() callback) rather than when the scheduler decides it would like to submit to the HW (run_job() callback after deciding on a job based on priority). --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlrCeywACgkQtdYpNtH8 nuiKexAAn14lj3BerPq7f1T1lfEkx4s83nXustTL59gh3STt9rLRUDOmD4vh101i qnQmF/7p2vYVVFEpv0hl3PathaC7zUIk62Al8I4dFyyIp5hQVVGJoFqpqhj6Klpa j4htvRg12FGFVMTCkLajvneSz9gCsUoOH7q2eMrQ2lXHVbsuD3J+HpOqrkWLw/SK +iMxTUqjNak9YAmxVugRfuiTYpClXcUoXmAm9od1BiyvCzPCUH+eaNOGsen82sp1 ZPVgXXzf4ROGYBTEoWD3eyem0x0wNofEQ/Kd/TNhwkTtvliUv18/QK7VNDI7ZBZ1 548yriyFlHgEPsjdHAZ/wle79SPb6vJWV7zJKEchsPy25tCAwnU+c70Hqqv9EAEg qK7UKc0NPBNFaCyhF/EGLtPLQ8KUtuuMHwTaNRv+xfZryPMEWDjhuduj5EmR2AG7 MJY5vALVBL86u1NFZsWWdEdX4TcoePH3rA6xr33vYivPQ3mNhFHVJ6p5yF7mgaJC 4jNKKyINHIcrIFMUMtKCr7LAIKSEEyKKZlq5Ryie8MyJmnxeiED3SwE6CjSVPRa8 tGMC5NcwaOy6ZFzha1ViTTR1jo5hvP+NthAE+7z1m7JSIpnDhFJDdeuduoreEkNK z+zOBa+RYdozYpf+NH0+n2+/rzpSpWgAonUvMZFQ3XvqUCEuOIY= =AdXY -----END PGP SIGNATURE----- --=-=-=-- --===============1958845023== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1958845023==--