From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: drm/scheduler for vc5 Date: Fri, 30 Mar 2018 13:05:22 -0700 Message-ID: <87o9j572il.fsf@anholt.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1873450871==" Return-path: Received: from anholt.net (anholt.net [50.246.234.109]) by gabe.freedesktop.org (Postfix) with ESMTP id 62FDD6E11B for ; Fri, 30 Mar 2018 20:05:27 +0000 (UTC) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org Cc: Alex Deucher , Christian =?utf-8?Q?K=C3=B6nig?= List-Id: dri-devel@lists.freedesktop.org --===============1873450871== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain I've been keeping my eye on what's going on with drm/scheduler, and I'm definitely interested in using it. I've got some questions about how to fit it to this HW, though. For this HW, most rendering jobs have two phases: binning and rendering, and the HW has two small FIFOs for descriptions of each type of job to be submitted. The bin portion must be completed before emitting the render. Some jobs may be render only, skipping the bin phase. The render side is what takes most of the time. However, you can usually bin the next frame while rendering the current one, helping keep your shared shader cores busy when you're parsing command lists. The exception is if the next bin depends on your last render (think render-to-texture with texturing in a vertex shader). This makes me think that I should expose two entities for the HW's binner and the renderer. Each VC6 job would have two drm_sched_job: The render job would depend on the fence from the bin job, and bin may or may not depend on the previous render. However, as an extra complication, the MMU is shared between binner and renderer, so I can't schedule a new job with a page table change until the other side finishes up. Is there a good way to express this with drm/scheduler, or should I work around this by internally stalling my job submissions to the HW when a page table change is needed, and then trigger that page table swap and submit once a job completes? --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlq+mIIACgkQtdYpNtH8 nujYVw/+JKN3kr3Vv/CdeXbvP5zvtMtNw2smDt/US5yHCfuaoXgaYd6Rde9ML4KT zT3XAOI8vR0a++3p5MlxtqVpKmTzfy48UNWz5f7sKbeGNxd8FO3qimnB2vobDXzU LiL0kCYWbFQ+Tq/23f+m86cmKD08xbE6Ju4W3Ib65I8W1YwE/bnHkT3oPyH1bm6X Hboq5MGTTTmPTusuEXZ+LwVLmMfSP+zr8IhfMQ+UU5OzH3FfS6trMGPENWu8ruEs bgU9xCPKKVxf47qskrvYP1jLV2D77360roOfx4lliB0J8jVkfrgMocxPM2saiorL BmWSZHvx5jtdnmerTzR+5+S3CW7KUmyO15hAYHbhc/RNhacNhnSKnKs+bbMx+vLd 7v5CejA8iR9oWvMLBalz8yIdVetRThutK+DR0QhT5NfDQJLpbhQh8nuaHFb3bqQL nn3MpeIKO1Fw8rnmQGXQ7jYqG7e6R6+WSqJeD/ErZ5TOUgZOCAZZNZECTl03XuCv Oftgg/4qQBzDNuh8kFitAbR4XkCoGYrf85c6T30/+W95GjdnUqR2tTsopN6vBTX3 Jvw+sNia3VllG6a1xJffpedo6xP64tyPjHOXJiBx6GfvO8MK/GTTuuegkpzgF+EY ygzTve4VYLgAkiGX/lxkoZTiuT+Nb7U01f9s3pWwcWnMqT+dIk4= =dZqi -----END PGP SIGNATURE----- --=-=-=-- --===============1873450871== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1873450871==--