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