From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zhi Wang Subject: Re: [PATCH 1/2] drm/i915: Pre-calculate engine context size Date: Thu, 27 Apr 2017 10:11:50 +0800 Message-ID: <59015366.7010301@intel.com> References: <1493197914-12383-1-git-send-email-joonas.lahtinen@linux.intel.com> <59006402.2000804@intel.com> <1493200345.4179.7.camel@linux.intel.com> <59006F16.9030702@intel.com> <4e27a0bc-c09b-0b8e-73c3-00c6ba9802c6@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0262477956==" Return-path: In-Reply-To: <4e27a0bc-c09b-0b8e-73c3-00c6ba9802c6@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniele Ceraolo Spurio , Joonas Lahtinen , Intel graphics driver community testing & development Cc: Paulo Zanoni , Rodrigo Vivi , intel-gvt-dev@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org This is a multi-part message in MIME format. --===============0262477956== Content-Type: multipart/alternative; boundary="------------020001050401070209010301" This is a multi-part message in MIME format. --------------020001050401070209010301 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Daniele: Thanks for the reply! Joonas and I did some researches in irc after the email. We found B-spec did say the context image for render engine consist 20 pages in context layout section. It looks like a mistake in b-spec. Another interesting we found is the context image size for KBL halo is weird, not the same with other KBL SKUs. Thanks, Zhi. 于 04/27/17 00:20, Daniele Ceraolo Spurio 写道: > > > On 26/04/17 02:57, Zhi Wang wrote: >> Uh...sorry for not mentioning that before:), and stolen memory is not my >> business. :( >> >> Actually we root-caused it. >> >> This is how we found this case: >> >> The story is W driver directly allocated the ring buffer after the >> context image, and the context image size in W driver is 19 pages. GVT-g >> will do shadow context during submission, we copy 20 pages from guest >> context image, so you can see, an extra page is copied here as the >> context image size is actual 19 pages. The extra page belows to ring >> buffer. When guest updates that page with new commands during GVT-g >> executing the workload, the extra page ( which is ring buffer page) will >> be over-written with old content, since GVT-g will copy the shadow >> context (20 pages) back to guest at this time. >> >> That's the full story. I send another email to Harsh. He should know if >> the context image size of CHV is also 19 pages. >> >> Thanks, >> Zhi. >> > > I did a quick check and according to the specs both the BDW and the > CHV lrcs are formed by 18096 dwords plus the per-context HWSP, which > converts to 19 pages for both platforms. > > Regards, > Daniele > >> 于 04/26/17 17:52, Joonas Lahtinen 写道: >>> On ke, 2017-04-26 at 17:10 +0800, Zhi Wang wrote: >>>> Hi Joonas: >>>> Can you change GEN8_LR_CONTEXT_RENDER_SIZE = (19 * PAGE_SIZE)? >>>> Then we don't need the hack in GVT-g. :P Actually it's 19 pages not >>>> 20 pages on BDW. >>> The exception is only made for BDW, not Gen8 overall. Has the change >>> been verified for CHV too? >>> >>> Why hasn't a patch to fix above been sent for i915 in the past? Just >>> like in the stolen memory disabling case, bugs should be root caused >>> and then fixed, not just worked around quickly. >>> >>> Regards, Joonas >> > _______________________________________________ > intel-gvt-dev mailing list > intel-gvt-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev --------------020001050401070209010301 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Daniele:
    Thanks for the reply! Joonas and I did some researches in irc after the email. We found B-spec did say the context image for render engine consist 20 pages in context layout section. It looks like a mistake in b-spec. Another interesting we found is the context image size for KBL halo is weird, not the same with other KBL SKUs.

Thanks,
Zhi.

于 04/27/17 00:20, Daniele Ceraolo Spurio 写道:


On 26/04/17 02:57, Zhi Wang wrote:
Uh...sorry for not mentioning that before:), and stolen memory is not my
business. :(

Actually we root-caused it.

This is how we found this case:

The story is W driver directly allocated the ring buffer after the
context image, and the context image size in W driver is 19 pages. GVT-g
will do shadow context during submission, we copy 20 pages from guest
context image, so you can see, an extra page is copied here as the
context image size is actual 19 pages. The extra page belows to ring
buffer. When guest updates that page with new commands during GVT-g
executing the workload, the extra page ( which is ring buffer page) will
be over-written with old content, since GVT-g will copy the shadow
context (20 pages) back to guest at this time.

That's the full story. I send another email to Harsh. He should know if
the context image size of CHV is also 19 pages.

Thanks,
Zhi.


I did a quick check and according to the specs both the BDW and the CHV lrcs are formed by 18096 dwords plus the per-context HWSP, which converts to 19 pages for both platforms.

Regards,
Daniele

于 04/26/17 17:52, Joonas Lahtinen 写道:
On ke, 2017-04-26 at 17:10 +0800, Zhi Wang wrote:
Hi Joonas:
      Can you change GEN8_LR_CONTEXT_RENDER_SIZE = (19 * PAGE_SIZE)?
Then we don't need the hack in GVT-g. :P Actually it's 19 pages not
20 pages on BDW.
The exception is only made for BDW, not Gen8 overall. Has the change
been verified for CHV too?

Why hasn't a patch to fix above been sent for i915 in the past? Just
like in the stolen memory disabling case, bugs should be root caused
and then fixed, not just worked around quickly.

Regards, Joonas

_______________________________________________
intel-gvt-dev mailing list
intel-gvt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

--------------020001050401070209010301-- --===============0262477956== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg== --===============0262477956==--