From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kenneth Graunke Subject: Re: [PATCH 2/3] iris: Create a composite context for both compute and render pipelines Date: Mon, 25 Mar 2019 22:52:10 -0700 Message-ID: <2324673.Bn3h3PiK9P@kirito> References: <20190325105900.16346-1-chris@chris-wilson.co.uk> <20190325105900.16346-2-chris@chris-wilson.co.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2060353810==" Return-path: In-Reply-To: <20190325105900.16346-2-chris@chris-wilson.co.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mesa-dev-bounces@lists.freedesktop.org Sender: "mesa-dev" To: Chris Wilson Cc: mesa-dev@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, Joonas Lahtinen List-Id: intel-gfx@lists.freedesktop.org --===============2060353810== Content-Type: multipart/signed; boundary="nextPart3462520.p2OPHlj955"; micalg="pgp-sha256"; protocol="application/pgp-signature" --nextPart3462520.p2OPHlj955 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Monday, March 25, 2019 3:58:59 AM PDT Chris Wilson wrote: > iris currently uses two distinct GEM contexts to have distinct logical > HW contexts for the compute and render pipelines. However, using two > distinct GEM contexts implies that they are distinct timelines, yet as > they are a single GL context that implies they belong to a single > timeline from the client perspective. Currently, fences are occasionally > inserted to order the two timelines. Using 2 GEM contexts, also implies > that we keep 2 ppGTT for identical buffer state. If we can create a > single GEM context, with the right capabilities, we can have a single > VM, a single timeline, but 2 logical HW contexts for the 2 pipelines. > > This is allowed through the new context interface that allows VM to be > shared, timelines to be specified, and for the logical contexts to be > constructed as the user desires. > > Cc: Joonas Lahtinen > Cc: Kenneth Graunke > --- > src/gallium/drivers/iris/iris_batch.c | 16 ++----- > src/gallium/drivers/iris/iris_batch.h | 5 +-- > src/gallium/drivers/iris/iris_context.c | 56 ++++++++++++++++++++++++- > 3 files changed, 60 insertions(+), 17 deletions(-) Hi Chris, I don't think that I want the single timeline option. It seems like we've been moving away from implicit sync for a long time, and the explicit sync code we have is pretty straightforward and seems to do the trick. Jason and I also chatted briefly, and we don't necessarily want to a strict submission-order between render/compute. Separating the VMA from the context state image seems like absolutely the right thing to do - as you said, they're separate in hardware, and no real reason to tie it together. I would be in favor of new uABI for that. I don't think there will be much overhead reduction from sharing the VMA here though. It's very plausible that the compositor might want to run between render and compute batches, at which point we end up doing page directory loads anyway. I have also heard rumors about bit 47 becoming magical at some point which may prohibit us from sharing... Context cloning seems OK, but I'm always pretty hesitant to add new uABI unless it's strictly necessary. In this case, we can do the same thing with a little bit of userspace code, so I'm not sure it's worth adding that... I would love to see an iris patch to use the new I915_CONTEXT_PARAM_RECOVERABLE option without the other dependencies. --Ken --nextPart3462520.p2OPHlj955 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE6OtbNAgc4e6ibv4ZW1vaBx1JzDgFAlyZvgoACgkQW1vaBx1J zDiZmA//ST+8LRgZjvUtNKi8bFIk3GSZ2Bq/qpk9fhIFSO5ZQPvuCyioiWsvJB8A wByLjYGYrtmbOqJnOGXLvbjTCJ3n2qwv0D+iWS1LiqL1SjoKjZUQV9lc4odSu7bM SzepFxMWTM0QkoCL/de7YuYbJYXsd83g5ym3y68ix6nEsGTyoKFLY4hLRsE9W3qq J759QxIS3aem6NOAZiNaJjCCO9re5BE3Q+R3UZ9WuaBHKKYPHBvp1qSAShFovmiU 6CDcoFE0b+Z8emZ2iwet3njWvKfcP+pJcLh4pPMoi6jX5/mZDOOOYdapiG8EMKD5 r3Wqxyu1yH2Lr4vn5dQWruCmQThwrJO1N8ISK5BZeqSlmzlWHKgNORc2/0jzCt37 fRDV91M1455b5GUbOKseXC57KDxGJbSqWohBtcEwEKwcjUFT1CRgzxk0vbvmMsPU egs0M58gs3VFmI8+Hk/ySKctb+vj9rTrQvzExdLaK2NVkvAeANm7N77yYQMj6s28 necN/YoACSc5tUtcD5eWhPvx3ozXAiMByC0Ad9WBueoLMDRn2WgdQO7ts7/yibtb 5ZfL7vxcfbbPjiD/mRBCPw+TJkutGfERkGGlRd097SArWjU8T7dOrZAhawwoRF+c 4INMt7+fmFmrabVq8b3CRGn7eCyVKUbydcv7RtUFUW03F/nQ6Gk= =uMVr -----END PGP SIGNATURE----- --nextPart3462520.p2OPHlj955-- --===============2060353810== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbWVzYS1kZXYg bWFpbGluZyBsaXN0Cm1lc2EtZGV2QGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3Rz LmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21lc2EtZGV2 --===============2060353810==--