Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging

The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.

Check out The OSR Learning Library at:

DisplayOnly Driver and Memory Reporting

Martin_DrábMartin_Dráb Member - All Emails Posts: 87


I am maintaining a display only driver (DOD) responsible for providing certain graphic services from the host into virtual machine(s). The driver is based on Microsoft's KMDOD sample. My question is: is it possible to report "GPU RAM/VRAM" used by the adapter represented by the driver (so you can see the values in the display adapter settings windows)?

My (current) understanting of this problem is that Windows reports GPU RAM and VRAM based on the information provided by the driver through the DxgkDdiQueryAdapterInfo callback. The driver reports this information by specifying memory segments used by GPU through DXGKQAITYPE_QUERYSEGMENT (or DXGKQAITYPE_QUERYSEGMENT3) type. This seems to work fine for the Display Miniport drivers, however, not for DODs -- I never get DxgkDdiQueryAdapterInfo called for these information types, thus, nothing can be reported. So, it seems that DODs are abstracted from this thing by WDDM/miniport driver.

Does anyone have more experience with this? Basically, I just need to report the GRU memory and VRAM sizes, that's all.

Thank you!

Martin Dráb


  • dbarriedbarrie Member Posts: 27

    From discussions with the owners of the DirectX Kernel (regarding different things, but still KMDOD-related), I don't believe this is possible with the KMDOD interface. The whole point of the KMDOD setup is that the device in question is not and can not be considered a full GPU by the OS, and therefor a vast majority of the "GPU" aspects that a full WDDM driver provides are skipped entirely. For example, there is no requirement that the hardware being driven by a KMDOD even have its own memory - as long as it can perform a DMA, it could be configured to scan out the rendered image directly from the location provided by the DXGKARG_PRESENT_DISPLAYONLY structure in its DdiPresentDisplayOnly callback.

    The KMDOD interface works very well for the very limited use case it supports, but for everything else... you need a full WDDM stack.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 13-17 May 2024 Live, Online
Developing Minifilters 1-5 Apr 2024 Live, Online
Internals & Software Drivers 11-15 Mar 2024 Live, Online
Writing WDF Drivers 26 Feb - 1 Mar 2024 Live, Online