Hi Zhenyu, and Zhiyuan Thanks a lot for your comments. and glad to know it is in the TODO list. We really need this feature to make our released image workable on both GVT-g and GVT-d/native. Multiple plane/overlay are important to us for meeting the Graphics performance target. Do you have an estimate when the feature will be available? and what version of this kernel will provide it, or do you have a back-porting plan for Kernel 5.4? BR, Shaofeng -----Original Message----- From: Zhenyu Wang <zhenyuw@xxxxxxxxxxxxxxx> Sent: Tuesday, June 23, 2020 11:45 AM To: Tang, Shaofeng <shaofeng.tang@xxxxxxxxx> Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>; intel-gfx@xxxxxxxxxxxxxxxxxxxxx; Lv, Zhiyuan <zhiyuan.lv@xxxxxxxxx> Subject: Re: [PATCH] drm/i915/gvt: query if vgpu is active via GETPARAM IOCTL On 2020.06.23 03:46:55 +0000, Tang, Shaofeng wrote: > Hi Zhenyu and Chris, > > Yes, I agree with you. > It must be better if only the workable planes/overlays are returned from KMS. > but currently, KMS still return all planes. and User did not know if > it is a virtual GPU or a native GPU. Do you know if there is a plan to fix or implement it? or any roadmap for sharing. We should expose this info via PV to let guest expose correct config from KMS. I've asked Zhiyuan to add todo for the fix. Better include you to be clear on the issue and requirement. > If KMS does not work in this way, we have to customized our image for this issue. > 2 possible solutions, > first, provide 2 customized image, 1 for VM, and 1 for Native or bare-metal. > and hard-code to only use 1 plane in the VM image. > Second, only provide 1 image, and hard-code to only use 1 plane for both VM and native. > None of them looks good to us. > We don't hope to hardcode the plane usage in user-space either, so this API is really helpful before KMS work as expected. > > As you mentioned there is a potentially good reason to let the user > know if it is a virtual GPU or not. it is not a hardcoding api limits. > I suppose it is a ability to support developer for optimizing the > performance on VM Including choose an appropriate renderer for better performance on VM. > But simply expose virtual GPU flag doesn't give you reliable indicator for performance e.g it doesn't tell you what's rendering is preferred. Or either you do some runtime profiling or try to detect either it's passthrough or mediated device e.g from gpu resource size, etc. That's your guest application's choice. > BR, Shaofeng > > -----Original Message----- > From: Zhenyu Wang <zhenyuw@xxxxxxxxxxxxxxx> > Sent: Monday, June 22, 2020 4:23 PM > To: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > Cc: Tang, Shaofeng <shaofeng.tang@xxxxxxxxx>; > intel-gfx@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: [PATCH] drm/i915/gvt: query if vgpu is active > via GETPARAM IOCTL > > On 2020.06.16 19:47:20 +0100, Chris Wilson wrote: > > Quoting Shaofeng Tang (2020-06-16 09:29:20) > > > [Why] > > > Query if vgpu is active, it is useful to the user. > > > Currently, only the primary plane is usable when vgpu is active. > > > The value of vgpu active is useful for user to determine how many > > > planes can be used. also useful for user to determine different > > > behaviors according to vgpu is active or not. > > > > The number of planes must be queried via kms, and all such kernel > > capabilities should be declared via the appropriate interface. > > > > I am not saying that there is not potentially good reason to let the > > user to know it's a virtual gpu, but hardcoding api limits in the > > client based on the parameter is a bad idea. > > Yeah, as I replied for internal before, guest shouldn't detect via this kind of interface, which also doesn't reflect any gvt host capability change. For any current gap, let's fix gvt or vgpu handling instead. > > Thanks. -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
