This is ideal and had been discussed in the beginning of upstream.
Mostly people didn't like this approach because it needs to modify i915
ppgtt code a lot and have to introduce a lot gvt-only code in i915 ppgtt.
The idea of the series of Joonas patch is to make PPGTT selection
per-platform. I guess that's the reason why he removed that check.
From his idea, there shouldn't be any platform which has execlist
support, but is still using aliasing PPGTT.
So it looks like there two approaches.
One is following the idea of this patch series: Platform with execlist
shouldn't touch aliasing PPGTT anymore, which needs GVT-g to create a
dummy PPGTT instance. (One dummy PPGTT instance for the architectural
design)
Another one is keeping the check as workaround like before.
I would like to choose a but b is also reasonable to me.
Thanks,
Zhi.
On 10/08/18 22:15, Zhenyu Wang wrote:
On 2018.10.08 13:58:25 +0000, Wang, Zhi A wrote:
Thanks for pointing this. My bad.
I take a look on the code and it looks like the GVT-g context is now quite similar with the kernel context except the force single submission and ring buffer size. (When we upstream the code, there was no kernel context at that time. :/) Now there is already one API for single submission. If we can introduce another one to configure the ring buffer size. Then maybe we can remove the *create_gvt() in i915_gem_context.c and used kernel context instead.
Feel free to drop comments. :)
For ppgtt, you'd better change to use i915 ppgtt interface to handle
shadow pages, then gvt context would be much like normal one.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
