<html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> 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. <span style="color: rgb(0, 0, 0); font-family: 'Segoe UI', 'Arial Unicode MS', 'Lucida Grande', Helvetica, 'Ubuntu Light', 'DejaVu Sans', FreeSans, sans-serif; font-size: 15px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;"> <div class="moz-cite-prefix">于 04/27/17 00:20, Daniele Ceraolo Spurio 写道: </div> <blockquote cite="mid:4e27a0bc-c09b-0b8e-73c3-00c6ba9802c6@intel.com" type="cite"> On 26/04/17 02:57, Zhi Wang wrote: <blockquote type="cite">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. </blockquote> 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 <blockquote type="cite">于 04/26/17 17:52, Joonas Lahtinen 写道: <blockquote type="cite">On ke, 2017-04-26 at 17:10 +0800, Zhi Wang wrote: <blockquote type="cite">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. </blockquote> 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 </blockquote> </blockquote> _______________________________________________ intel-gvt-dev mailing list <a class="moz-txt-link-abbreviated" href="mailto:intel-gvt-dev@lists.freedesktop.org">intel-gvt-dev@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev">https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev</a> </blockquote> </body> </html>