From: krish on
Hi ivan,

Thanks for ur prompt reply.You are absolutely right in specifying
that only one user mode driver is required to drive all the extended
monitors, provided u have only one miniport driver driving all the
extended surfaces.

But in my case it is a special scenario where i am creating the
extended surface through my own miniport driver ( a virtual kind of
thing), so how to provide the D3D support through a usermode driver
for my extended surface.

Thanks & Regards,
krish.

> You do not need a user mode driver per monitor.
> The very fact that you ask the question raises the doubt if you have
> minimally understood the model for which you are asked to provide a driver.
>
> The user mode driver is loaded by a runtime
> (DDraw/D3D9/DXGI/D3d10Level9, etc, etc).
> It is loaded once per process per runtime instance.
> The user mode driver coordinate with the runtime (through a callback
> interface) things such as mode-change, present, render, resource creation
> and the such.
>
> You can have one user-mode driver piloting 6 monitors (for example),
> all from the same application. This is what dwm.exe normally does,
> and other multi-mon DX applications as well.
>
From: Ivan Brugiolo [MSFT] on
There is nothing that you are extending in this case.
If you have a Virtual WDDM miniport, then your machine is in the
heterogeneous adapter scenario (assuming you have already
a physical adapter, otherwise it will be homogeneous adater).
The appropriate runtime will first create a user-mode adapter
logically matching each miniport, and, each adapter will create a device,
and then your user-mode driver will be asked
for private data that will be passed DxgkDdiCreateAllocation.
Natually there can be multiple adapters handles per process,
multiple devices per process, and multiple allocations per adapter.
One of multiple allocations can be elected to become the current
scanout surface (one at the time, off course, assuming the VidPn
configuration
and the device ownership is correct).
The mechanism used to express a miniport qualifier
for the other user mode constructs depends on the runtime:
DDraw/DX8/DX9c will use HMONITOR.
D3D9l/DXGI/D3D10/D3D11 will use Adapter-LUIDs.
At the user-mode driver level, that is not transparent to you
and you will deal with adapter handles, device handles,
resource/allocation handles and the such.
The user-mode runtimes and DxgKrnl.sys will do the mapping,
and will call your miniport appropriately.

--

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"krish" <drvkrish99(a)gmail.com> wrote in message
news:bba811b0-5e7f-4d60-9957-af91b2b9bd74(a)k35g2000yqb.googlegroups.com...
> Hi ivan,
>
> Thanks for ur prompt reply.You are absolutely right in specifying
> that only one user mode driver is required to drive all the extended
> monitors, provided u have only one miniport driver driving all the
> extended surfaces.
>
> But in my case it is a special scenario where i am creating the
> extended surface through my own miniport driver ( a virtual kind of
> thing), so how to provide the D3D support through a usermode driver
> for my extended surface.
>
> Thanks & Regards,
> krish.
>
>> You do not need a user mode driver per monitor.
>> The very fact that you ask the question raises the doubt if you have
>> minimally understood the model for which you are asked to provide a
>> driver.
>>
>> The user mode driver is loaded by a runtime
>> (DDraw/D3D9/DXGI/D3d10Level9, etc, etc).
>> It is loaded once per process per runtime instance.
>> The user mode driver coordinate with the runtime (through a callback
>> interface) things such as mode-change, present, render, resource creation
>> and the such.
>>
>> You can have one user-mode driver piloting 6 monitors (for example),
>> all from the same application. This is what dwm.exe normally does,
>> and other multi-mon DX applications as well.
>>