Post by krishDo mean to say that i need to check the driver calls when DX10
application is running in full screen mode.can u suggest any simple
DX10 application other than the heavy 3D games? I am trying with
Cascades demo application but it seems to work only on NVIDIA cards.
You really need to start from something really simple, because
you are interested to develop the user-mode part of WDDM,
and, you want to start from one application going full-screen
and clearing the back-buffer with a solid color.
Check this book for something really simple ISBN-10: 1598633619.
Post by krish"2-backbuffer-shapchain"- what is this? is this an DX10 application,
if so i googled for the same but couldnt find ? can u elaborate more
on this.
DXGI_SWAP_CHAIN_DESC DescSC;
ZeroMemory(&DescSC, sizeof(DescSC));
DescSC.BufferDesc.Width = 1024;
DescSC.BufferDesc.Height = 768;
DescSC.BufferDesc.Format = DXGI_FORMAT_R8G8B8A8_UNORM;
DescSC.SampleDesc.Count = 1;
DescSC.SampleDesc.Quality = 0;
DescSC.BufferUsage = DXGI_USAGE_RENDER_TARGET_OUTPUT;
DescSC.BufferCount = 2;
DescSC.OutputWindow = hWnd;
DescSC.Windowed = TRUE;
DescSC.SwapEffect = DXGI_SWAP_EFFECT_DISCARD;
DescSC.Flags = 0;
HRET(Factory->MakeWindowAssociation(hWnd, 0));
HRET(Factory->CreateSwapChain(m_Device, &DescSC, m_SwapChain));
Post by krishMy query was in the filter driver approach for WDDM u mentioned how
come the filter driver distinguishes primary and secondary( created by
the Filter). for the secondary how it allocates the memory and
accesess the same secondary sutrface memory.
I speculate that the `WDDM-filter` adds a couple of VipPn-Sources.
Sources are sequential from 0 to the number reported by the MiniPort,
so, that number assignment is well-knonw.
Then, the VidPn-Source is passed down to
DxgkDdiGetStandardAllocationDriverData,
where you can store-in in the private data for your allocation.
Post by krishIs there any way to provide memory to the OS to draw in WDDM as it
was done earlier in xddm in DrvEnableSurface.
No, no way. That is one of the fundamental differences XPDM / WDDM.
WDDM has a full-fledge video-memory-manager.
You describe the segments to it in DXGKQAITYPE_QUERYSEGMENT.
Then, it will require you to perform
page-in / page-out operations, from Memory-Space to Aperture,
by building DMA-paging command-buffers.
Post by krishSo the two standard allocations will be allocated in
GetStandardAllocation call- as per my understanding.
No, they will be create in DxgkDdiCreateAllocation.
Actually, you will be required to describe the allocation
requirements, and then VidMM will carve them out from the segments.
Post by krishso as per ur explanation shadow surface will be identical ( same
contents) to the shared primary except that shadow is visible in
system memory of CPU.
They may have the same `pixel content`, but, they will likely not
have the same physical content (because of swizzling and other Ram-Dac
constrains),
they will not have the same content at the same time (because of DxgkPresent
is a trigger for an Async-DMA) and they will not be equally accessible
from the CPU and/or the bus.
Post by krishwhat abt the STANDARDALLOCATION_GDISURFACE which is used for for GDI
hardware acceleration and Desktop Windows Manager (DWM) redirection.is
this the memory used During desktop composition.
This is really a trick to create a non-standard allocation from kernel-mode
so that it can be shared across processes. You can skip this for now,
since it will become relevant after you've solved other issues.
Post by krishHow the Non-standard allocations created by DWM and other DX
application visible to driver? any call in specific?
The user-mode driver provide private data to describe them.
Then, the data is passed to kernel-mode as part of Allocation-Creation.
Post by krishwhere to provide the segment descriptions?
You do that in DXGKQAITYPE_QUERYSEGMENT
Post by krishOk what are the hardships in Bus-Enumerated devices approach, as u
mentioned earlier can u share ur Virtual Bus enumerated WDDM driver
for reference?
The difficulties of the bus approach are to simulate a functional
PCI/AGP/PCIex bus,
including interrupt.
I cannot share a piece of work that was only in week 3 of a
potentially 3/6 month project to get to a meaningful completion level.
Also, I'm not sure that is aligned with current or future thinking
with regard of the WDDM driver development support,
because I'm not involved with Desktop-Graphics anymore.
Post by krishI am quiet confused regarding the memory mapping in WDDM, can u please
direct me to some links where i can clarify myself ? r u can give an
insight on the same.
If you are confused, then I think you started the wrong point.
To me understanding the VidMM model interaction with the segments
you describe is more important than the VidPn management.
At the end-of-the-day, the user will pick a mode and stay with it for the
day,
while it will perform operations that will create and destroy allocations.
--
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
Post by krishHi ivan,
I was able to understand ur post in bits and pieces but
not entirely, may be as i am not familiar with the DX10 stuff.
Post by Ivan Brugiolo [MSFT]Now that the basic part works, you should try
with a DX10 application going full-screen on one monitor.
First the monitor not owned by your WDDM driver,
then to the monitor owned by your driver.
Do mean to say that i need to check the driver calls when DX10
application is running in full screen mode.can u suggest any simple
DX10 application other than the heavy 3D games? I am trying with
Cascades demo application but it seems to work only on NVIDIA cards.
Post by Ivan Brugiolo [MSFT]You should do nothing. In Windows7, dwm.exe is designed to
'inherit' or 'fully-match' the GDI-mode that was set by CDD.
That is, the VidPn should not functionally change, even if there
will be different kind of primary pair that you will be asked to create
and scan-out.
Yeah i understood so i need not medle with currently functional vidpn.
Post by Ivan Brugiolo [MSFT]If you debug the 2-backbuffer-shapchain DX10 application going
full-screen, you should have that code-path covered.
"2-backbuffer-shapchain"- what is this? is this an DX10 application,
if so i googled for the same but couldnt find ? can u elaborate more
on this.
Post by Ivan Brugiolo [MSFT]You should not get a Standard-Allocation call for a user-mode owned
shapchain.
u mean to say for shapchain application i shouldnt get the Standard-
Allocation call? once i explore that application i will let u know.
Post by Ivan Brugiolo [MSFT]I'm not sure I understand the question.
My query was in the filter driver approach for WDDM u mentioned how
come the filter driver distinguishes primary and secondary( created by
the Filter). for the secondary how it allocates the memory and
accesess the same secondary sutrface memory.
Is there any way to provide memory to the OS to draw in WDDM as it
was done earlier in xddm in DrvEnableSurface.
Post by Ivan Brugiolo [MSFT]CDD creates two Standard Allocations per VidPn-source.
One `sharedprimary` and one `shadow`.
Dwm.exe (and any DX10/DX9/DDraw application) creates non-standard
allocations.
The idea of the `shadow` is that is is always CPU visible. That's why it
should
be created in an Aperture segment. That depends on how you described
your segments when you were asked to.
So the two standard allocations will be allocated in
GetStandardAllocation call- as per my understanding.
so as per ur explanation shadow surface will be identical ( same
contents) to the shared primary except that shadow is visible in
system memory of CPU.
what abt the STANDARDALLOCATION_GDISURFACE which is used for for GDI
hardware acceleration and Desktop Windows Manager (DWM) redirection.is
this the memory used During desktop composition.
How the Non-standard allocations created by DWM and other DX
application visible to driver? any call in specific?
where to provide the segment descriptions?
Post by Ivan Brugiolo [MSFT]If you are wishing to go the bus-enumerated devices approach, then
the approach is viable, but, you will have some difficulty in simulating
the PCI-bus features (Interrupt and memory-mapping being some).
What is not viable is piggy-backing on
an existing WDDM driver by call interception means.
Ok what are the hardships in Bus-Enumerated devices approach, as u
mentioned earlier can u share ur Virtual Bus enumerated WDDM driver
for reference?
I am quiet confused regarding the memory mapping in WDDM, can u please
direct me to some links where i can clarify myself ? r u can give an
insight on the same.
Thanks & Regards,
Krish.