[Intel-gfx] [PATCH 1/2] drm/i915: Pre-calculate engine context size

Daniele Ceraolo Spurio daniele.ceraolospurio at intel.com
Wed Apr 26 16:20:21 UTC 2017



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
>


More information about the Intel-gfx mailing list