[PATCH 00/13] drm/amdgpu: Add virtual display feature.
Bridgman, John
John.Bridgman at amd.com
Thu Aug 4 17:31:49 UTC 2016
>-----Original Message-----
>From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] 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 at ffwll.ch> 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 at amd.com>
>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 at lists.freedesktop.org
>> >> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>> >> _______________________________________________
>> >> dri-devel mailing list
>> >> dri-devel at lists.freedesktop.org
>> >> 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 at lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
More information about the dri-devel
mailing list