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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev
|
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
