>-----Original Message----- >From: dri-devel [mailto:dri-devel-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf >Of Daniel Vetter >Sent: Thursday, August 04, 2016 1:23 PM >To: Alex Deucher >Cc: Deng, Emily; amd-gfx list; Maling list - DRI developers >Subject: Re: [PATCH 00/13] drm/amdgpu: Add virtual display feature. > >On Thu, Aug 04, 2016 at 12:53:04PM -0400, Alex Deucher wrote: >> On Thu, Aug 4, 2016 at 12:24 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: >> > On Thu, Aug 04, 2016 at 10:59:38AM -0400, Alex Deucher wrote: >> >> Adding dri-devel. >> >> >> >> This patch set basically adds a driver option to enable virtual >> >> display hw if the user needs it (e.g., virtualization environments, >> >> headless cards, pre-silicon environments, etc.). It looks like a >> >> regular KMS crtc/encoder/connector and works with existing >> >> userspace unchanged. >> > >> > We autodetect this already for virtualized envirnments and pre-silicon. >> >> What do you mean? What do you do in those cases? > >So virtualized (xengt) I think just fakes one display/connector, I didn't really >check the details tbh. We had code floating around (but not merged) for the >management console on servers, which injected a special config into iirc the >VGA port. So a mix of kernel driver and hw/firmware tricks. > >Pre-silicon just has a bunch of things to fake enough of a display since not all >environments have the full display block simulated. > >Anyway just wanted to say that we have piles of precendence for faking semi- >virtual outputs. > >> > Not so sure about headless cards, on those we don't bother to expose >> > anything if there's nothing connected (i.e. no crtc/encoder/plane or >> > connector objects at all). Why do you want fake outputs in that case? >> >> We have some customers that want to run X or other desktops on >> hardware without display connectors or even chips without display hw >> at all. > >Hm, for that I'd say virtual output/screen in X. Adding a fake output in the >kernel where there really is nothing at all feels a bit wrong. All the examples >above mean that the output is actually connected to something on the other >side (screen on the management console, host OS for xengt or pre-silicon >simulations). > >> > Anyway, if this is just a modparam and disabled by default I don't >> > see any issue really at all. >> >> Yes, this is controlled by a module option and is intended to only be >> enabled by the user for specific use cases. > >Another option for entirely fake outputs would be vkms.ko, similar to >vgem.ko. With the simple display driver it should be fairly easy to a simple >fake kms driver with just 1 crtc/encoder/connector/plane, all virtual, >up&running. Needs a few lines to implement dumb mmap on top of shmem >(but nothing else, since the driver never reads the buffer), plus prime >import/export scaffolding. One module option (could even adjust at >runtime) to configure how many drm_device instance there should be. >Output configuration could be done by injecting a suitable EDID plus forcing >the connector state (we have interfaces for that already, and iirc even patches >to expose them all in sysfs). > >I'd say if you really want entirely fake/virtual outputs that go exactly nowhere >at all, vkms.ko would be the cleanest approach. And that would have lots of >use-cases outputs of just what you need, for e.g. testing kms helpers/ioctls >and other nice things. FWIW I don't think we ever plan to have virtual outputs that go nowhere - the display content just might go out via VNC or a compressed streaming interface rather than through a local display controller. >-Daniel > >> >> Alex >> >> > -Daniel >> > >> >> >> >> Alex >> >> >> >> On Thu, Aug 4, 2016 at 3:04 AM, Emily Deng <Emily.Deng@xxxxxxx> >wrote: >> >> > The Virtual Display feature is to fake a display engine in amdgpu kernel >driver, which allows any other kernel modules or user mode components to >work as expected even without real display HW. User can get the >desktop/primary surface through remote desktop tools instead of displaying >HW associated with the GPU. >> >> > The virtual display feature is designed for following cases: >> >> > 1)Headless GPU, which has no display engine, while for some >> >> > reason the X server is required to initialize in this GPU; 2)GPU >> >> > with head (display engine) but Video BIOS disables display capability for >some reason. For example, SR-IOV virtualization enabled Video BIOS often >disables display connector. Some S-series Pro-Graphics designed for headless >computer also disable display capability in Video BIOS; 3)For whatever reason, >end user wants to enable a virtual display (don’t need HW display capability). >> >> > >> >> > Emily Deng (13): >> >> > drm/amdgpu: Add virtual connector and encoder macros. >> >> > drm/amdgpu: Initialize dce_virtual_ip_funcs >> >> > drm/amdgpu: Initialize dce_virtual_display_funcs. >> >> > drm/amdgpu: Initialize crtc, pageflip irq funcs >> >> > drm/amdgpu: Initialize dce_virtual_crtc_helper_funcs >> >> > drm/amdgpu: Initialize dce_virtual_crtc_funcs. >> >> > drm/amdgpu: Disable VGA render and crtc when init GMC. >> >> > drm/amdgpu: Use software timer to generate vsync interrupt. >> >> > drm/amdgpu: Call pageflip irq funtion when receiced vsync interrupt. >> >> > drm/amdgpu: Add DRM_MODE_CONNECTOR_VIRTUAL connector in >> >> > amdgpu_connector_add. >> >> > drm/amdgpu: Define vitual display ip blocks. >> >> > drm/amdgpu: Define one variable for virtual display. >> >> > drm/amdgpu: Set ip_blocks according variable >amdgpu_virtual_display. >> >> > >> >> > drivers/gpu/drm/amd/amdgpu/Makefile | 3 +- >> >> > drivers/gpu/drm/amd/amdgpu/ObjectID.h | 7 + >> >> > drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 + >> >> > drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 27 + >> >> > drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.h | 2 + >> >> > drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 95 +++ >> >> > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 + >> >> > drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 5 +- >> >> > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 + >> >> > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 9 +- >> >> > drivers/gpu/drm/amd/amdgpu/cik.c | 445 +++++++++++-- >> >> > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 75 +++ >> >> > drivers/gpu/drm/amd/amdgpu/dce_v10_0.h | 2 + >> >> > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 83 +++ >> >> > drivers/gpu/drm/amd/amdgpu/dce_v11_0.h | 2 + >> >> > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 82 +++ >> >> > drivers/gpu/drm/amd/amdgpu/dce_v8_0.h | 2 + >> >> > drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 855 >+++++++++++++++++++++++++ >> >> > drivers/gpu/drm/amd/amdgpu/dce_virtual.h | 31 + >> >> > drivers/gpu/drm/amd/amdgpu/vi.c | 416 ++++++++++-- >> >> > 20 files changed, 2062 insertions(+), 91 deletions(-) create >> >> > mode 100644 drivers/gpu/drm/amd/amdgpu/dce_virtual.c >> >> > create mode 100644 drivers/gpu/drm/amd/amdgpu/dce_virtual.h >> >> > >> >> > -- >> >> > 1.9.1 >> >> > >> >> > _______________________________________________ >> >> > amd-gfx mailing list >> >> > amd-gfx@xxxxxxxxxxxxxxxxxxxxx >> >> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx >> >> _______________________________________________ >> >> dri-devel mailing list >> >> dri-devel@xxxxxxxxxxxxxxxxxxxxx >> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel >> > >> > -- >> > Daniel Vetter >> > Software Engineer, Intel Corporation http://blog.ffwll.ch > >-- >Daniel Vetter >Software Engineer, Intel Corporation >http://blog.ffwll.ch >_______________________________________________ >dri-devel mailing list >dri-devel@xxxxxxxxxxxxxxxxxxxxx >https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
