WDDM Driver Vidpn implementation.
in [Device Drivers]
|
From: Ivan Brugiolo [MSFT] on 28 Dec 2009 16:59 > But as soon as i enable Aero theme screen starts to flicker . so what > DxgkDDIXXXX calls need to be handled to overcome this situation? > please suggest the handling in brief. > > I am repeatedly getting call of updateActivevidpn in the miniport > driver as soon as i enable Aero theme. Any thing to do with the Vidpn > path source modes for aero? > 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. > I am repeatedly getting call of updateActivevidpn in the miniport > driver as soon as i enable Aero theme. Any thing to do with the Vidpn > path source modes for aero? 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. If you debug the 2-backbuffer-shapchain DX10 application going full-screen, you should have that code-path covered. > Yes i am getting calls of DxgkDdiGetStandardAllocationDriverData? any > specific handling need to be done for Aero in this?? You should not get a Standard-Allocation call for a user-mode owned shapchain. > One more query is How OS will be distinguishing between primary and > secondary display surfaces in the case of WDDM apart from source and > target ids ? specifically with respect to Memory? I'm not sure I understand the question. 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. > How this approach is feasible with respect to WDDM architeture. > exactly how can one get access to the memory where the Drawings > happen ? > 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. -- 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:49c20542-f35a-4f16-a367-24ce45ef79b8(a)n16g2000yqm.googlegroups.com... > > Hi Ivan, > >> You should try to get mode-change to work without desktop composition. >> Mode Change with DWM-on is one other of magnitude more complex >> (together with having full-screen DDraw, DX9 and DX10 full-screen >> application >> in a 6+ monitor configuration, orver 3 heterogenous adapters, for >> example). >> In SystemPropertiesPerformance.exe uncheck `enable desktop composition`. >> At that point, you should get only a worker-thread in CSRSS that drivers >> the >> whole thing. >> That thread does a lot of VidPn creation, followed by primary creation. > > > With your valuable suggestion i was able to make the Vidpn > cofunctional with the Windows Basic theme(with out Desktop > Composition) and extend desktop display settings is also working quiet > fine. > > But as soon as i enable Aero theme screen starts to flicker . so what > DxgkDDIXXXX calls need to be handled to overcome this situation? > please suggest the handling in brief. > > I am repeatedly getting call of updateActivevidpn in the miniport > driver as soon as i enable Aero theme. Any thing to do with the Vidpn > path source modes for aero? > >> Did you get your miniport called to create a standard >> allocation for the Shadow and the Primary ? > > Yes i am getting calls of DxgkDdiGetStandardAllocationDriverData? any > specific handling need to be done for Aero in this?? > > One more query is How OS will be distinguishing between primary and > secondary display surfaces in the case of WDDM apart from source and > target ids ? specifically with respect to Memory? > >> The filter driver approach (even if somewhat popular with a manufacturer >>of USB display extenders) is not viable. >>Basically, any port/mini-port pair cannot be filtered `in-between`, >>and, you would end-up having a bus-enumerated PnP driver that calls >>DxgkInitialize in DriverEntry, and, not much more than that. > > How this approach is feasible with respect to WDDM architeture. > exactly how can one get access to the memory where the Drawings > happen ? > > > Thanks & Regards, > krish
From: krish on 29 Dec 2009 10:09 Hi 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. > 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. > 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. > 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. > 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. > > 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. > 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? > 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.
From: Ivan Brugiolo [MSFT] on 29 Dec 2009 14:01 > > 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. > 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. > "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)); > 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. 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. > Is 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. > So 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. > 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. 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. > 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. 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. > How 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. > where to provide the segment descriptions? You do that in DXGKQAITYPE_QUERYSEGMENT > 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? 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. > 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. 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 "krish" <drvkrish99(a)gmail.com> wrote in message news:3fa7aa9f-1476-4f8e-9a2e-73cc16e3b825(a)d20g2000yqh.googlegroups.com... > Hi 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. > >> 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. > > >> 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. >> 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. > >> 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. >> > >> 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. >> 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? > > >> 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. >
From: krish on 21 Jan 2010 10:42 Hi Ivan, Sorry for replying late as i was going through the Book u suggested (it was pretty helpful) and going through the User Mode driver part of the WDDM. > 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. Regarding the User Mode Driver i am facing the problem of loading the USER MODE driver.can u plaese explain how to load my user Mode driver for the secondary in addition to the existing User mode driver(for primary) as i dont have a UserModeDriverName registry key in Display Class registry. can u suggest the ways how we can load the user mode driver so that i can support D3D calls for my secondary?? Thanks & Regards 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)); > > > 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. > > 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. > > > Is 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. > > > So 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. > > > 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. > > 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. > > > 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. > > 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. > > > How 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. > > > where to provide the segment descriptions? > > You do that in DXGKQAITYPE_QUERYSEGMENT > > > 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? > > 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. > > > 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. > > 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 athttp://www.microsoft.com/info/cpyright.htm > > "krish" <drvkris...(a)gmail.com> wrote in message > > news:3fa7aa9f-1476-4f8e-9a2e-73cc16e3b825(a)d20g2000yqh.googlegroups.com... > > > Hi 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. > > >> 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. > > >> 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. > >> 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. > > >> 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. > > >> 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. > >> 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? > > >> 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.
From: Ivan Brugiolo [MSFT] on 21 Jan 2010 15:10 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. -- -- 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:a56387d2-31e2-4e9e-bbb2-479094030b9e(a)c4g2000yqa.googlegroups.com... > Hi Ivan, > > Sorry for replying late as i was going through the Book u suggested > (it was pretty helpful) and going through the User Mode driver part of > the WDDM. >> 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. > > > Regarding the User Mode Driver i am facing the problem of loading the > USER MODE driver.can u plaese explain how to load my user Mode driver > for the secondary in addition to the existing User mode driver(for > primary) as i dont have a UserModeDriverName registry key in Display > Class registry. > > can u suggest the ways how we can load the user mode driver so that i > can support D3D calls for my secondary?? > > > Thanks & Regards > 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)); >> >> > 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. >> >> 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. >> >> > Is 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. >> >> > So 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. >> >> > 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. >> >> 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. >> >> > 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. >> >> 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. >> >> > How 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. >> >> > where to provide the segment descriptions? >> >> You do that in DXGKQAITYPE_QUERYSEGMENT >> >> > 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? >> >> 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. >> >> > 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. >> >> 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 >> athttp://www.microsoft.com/info/cpyright.htm >> >> "krish" <drvkris...(a)gmail.com> wrote in message >> >> news:3fa7aa9f-1476-4f8e-9a2e-73cc16e3b825(a)d20g2000yqh.googlegroups.com... >> >> > Hi 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. >> >> >> 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. >> >> >> 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. >> >> 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. >> >> >> 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. >> >> >> 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. >> >> 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? >> >> >> 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. >
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: A KeQuerySystemTime alternate function under x64 ? Next: Signing driver for virtual com port |