Does the presense of mirror driver slows down the native system?
I got this doubt because i was able to extend the mirror driver wdk sample to implement the hooked Drv functions. The implementation right now is punting back to GDI through Eng calls.
what i noticed is with mirror driver one of my application is giving 50% less fps compared to without mirror driver.
I read somewhere in this forum that GDI hold a lock for all Drv calls. so, with mirror driver there will be almost double Drv calls. Is it the reason? (or) Implementations better than Eng… will improve the performance?
Thanks in advance.
> Does the presense of mirror driver slows down the native system?
Yes.
I got this doubt because i was able to extend the mirror driver wdk sample
to implement the hooked Drv functions. The implementation right now is
punting back to GDI through Eng calls.
what i noticed is with mirror driver one of my application is giving 50%
less fps compared to without mirror driver.
I read somewhere in this forum that GDI hold a lock for all Drv calls. so,
with mirror driver there will be almost double Drv calls. Is it the reason?
(or) Implementations better than Eng… will improve the performance?
The frame rate will be dependent on the amount of CPU/GPU required to render everything twice. How big are your frames? Are most of the Drv calls for BitBlt?
Good luck!
Tim.
xxxxx@gmail.com wrote:
Does the presense of mirror driver slows down the native system?
I got this doubt because i was able to extend the mirror driver wdk sample to implement the hooked Drv functions. The implementation right now is punting back to GDI through Eng calls.
what i noticed is with mirror driver one of my application is giving 50% less fps compared to without mirror driver.
Of course it does. I would have hoped this was obvious. Every drawing
command is now being done twice – once by your graphics card for the
visible desktop display, and once entirely in software for your mirror
driver’s surface.
I read somewhere in this forum that GDI hold a lock for all Drv calls. so, with mirror driver there will be almost double Drv calls. Is it the reason?
It doesn’t have anything to do with locking. You have doubled the
number of Drv calls, because they’re all being done twice. The main
driver takes almost no CPU time at all, because the work is done by the
graphics chip. Your mirror driver’s drawing is being done entirely by
the CPU. A mirror driver is always going to hurt a graphics-intensive
application.
(or) Implementations better than Eng… will improve the performance?
You will not be able to create an implementation better than the Eng
calls. The GDI drawing code in NT has more than 20 years of tuning
behind it, and it was pretty darned good to begin with. Chuck Weiss was
a Microsoft genius.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi Tim. Thanks for your reply.
My resolution is 1900 X 1200 and my application is running full screen. Yes,
most of the calls are DrvBitBlt and DrvCopyBits.
Thanks.
On Fri, Dec 17, 2010 at 6:44 PM, Tim Green wrote:
> > Does the presense of mirror driver slows down the native system?
>
> Yes.
>
> > I got this doubt because i was able to extend the mirror driver wdk
> sample
> > to implement the hooked Drv functions. The implementation right now is
> > punting back to GDI through Eng calls.
> > what i noticed is with mirror driver one of my application is giving 50%
> > less fps compared to without mirror driver.
> >
> > I read somewhere in this forum that GDI hold a lock for all Drv calls.
> so,
> > with mirror driver there will be almost double Drv calls. Is it the
> reason?
> > (or) Implementations better than Eng… will improve the performance?
>
> The frame rate will be dependent on the amount of CPU/GPU required to
> render everything twice. How big are your frames? Are most of the Drv calls
> for BitBlt?
>
> Good luck!
> Tim.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Tim Roberts,
Does that mean any mirror driver(however optimized the function implementations are ) will definitely affect the performance of graphics intensive applications?
You mentioned before that the main driver takes almost no cpu time at all. Then Why can’t main driver and mirror driver run parallely?
Thanks.
Vishnu wrote …
Does that mean any mirror driver(however optimized the function implementations are ) will definitely affect the performance of graphics intensive applications? You mentioned before that the main driver takes almost no cpu time at all. Then Why can’t main driver and mirror driver run parallely?
… to which I reply …
They can and do, but recall that all video cards [produced after 2004 or so] contain a GPU which is a completely separate CPU with it’s own memory, programming language and interface to the video display. The sequence for the a “main driver” is …
Application – call –> Display Driver – call –> GPU – graphic processing –> Chipset –> Pixels
… so the vast majority of the work to draw pixels is being done by the GPU on video card. The “main driver” is literally passing [the equivalent of] an IRP to the GPU and waiting for that to complete which takes almost zero CPU time … it’s just like an overlapped IOCTL call from userland to kernel, just from display driver to GPU …
Now here’s the mirror driver [simplified quite a bit] …
Application – call –> Mirror Driver –> OS Eng calls –> graphic processing –> Output
… so the “graphic processing” which used to be done by the GPU is now being done by the CPU as it draws pixels on the mirror driver frame buffer [or equivalent]. The more intensive the graphics the harder the CPU has to work and the less it can work on other things (like the application) …
Mirror drivers are best suited for things that don’t move many pixels (GDI calls), don’t do too well for things that move lot’s of pixels (CopyBlt’s) and really have trouble with moving lot’s of pixels quickly (DirectX, video’s) …
Cheers!
xxxxx@gmail.com wrote:
Does that mean any mirror driver(however optimized the function implementations are ) will definitely affect the performance of graphics intensive applications?
Assuming you are maintaining second copy of the desktop, absolutely,
yes. How could it possibly be any different? With a 1920x1200 full
color desktop, when you fill the screen with a solid color, you’re
writing 10 megabytes of data. That takes time, and the application
can’t move forward until you are through.
You mentioned before that the main driver takes almost no cpu time at all. Then Why can’t main driver and mirror driver run parallely?
They can – and they do – but your mirror driver is using the CPU. The
main driver starts the graphics chip and then returns to let the user do
other things. When your mirror driver is running, your mirror driver is
consuming that CPU time.
I guess I’m not sure why this would be a surprise. Every graphics
command will involve a call into your mirror driver, and that call might
take a lot of time, depending on the type of call. In a
graphics-intensive application, that’s going to represent a significant
load.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim,
As Ponaka mentioned most the calls are for DrvBitBlt and DrvCopyBits, my
doubt is there any possibility of removing/minimizing some calls? So that we
can reduce CPU load.
/sarbojit
On Thu, Dec 23, 2010 at 12:24 AM, Tim Roberts wrote:
> xxxxx@gmail.com wrote:
> > Does that mean any mirror driver(however optimized the function
> implementations are ) will definitely affect the performance of graphics
> intensive applications?
>
> Assuming you are maintaining second copy of the desktop, absolutely,
> yes. How could it possibly be any different? With a 1920x1200 full
> color desktop, when you fill the screen with a solid color, you’re
> writing 10 megabytes of data. That takes time, and the application
> can’t move forward until you are through.
>
> > You mentioned before that the main driver takes almost no cpu time at
> all. Then Why can’t main driver and mirror driver run parallely?
>
> They can – and they do – but your mirror driver is using the CPU. The
> main driver starts the graphics chip and then returns to let the user do
> other things. When your mirror driver is running, your mirror driver is
> consuming that CPU time.
>
> I guess I’m not sure why this would be a surprise. Every graphics
> command will involve a call into your mirror driver, and that call might
> take a lot of time, depending on the type of call. In a
> graphics-intensive application, that’s going to represent a significant
> load.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Sarbojit Sarkar wrote:
As Ponaka mentioned most the calls are for DrvBitBlt and
DrvCopyBits, my doubt is there any possibility of removing/minimizing
some calls? So that we can reduce CPU load.
I’m not sure what you are trying to say here. Unless you have the
ability to rewrite all of your applications, you can’t change the way
they do their graphics. As a driver, that’s simply not under your
control. If the app calls BitBlt 1,000 times a second, you’re going to
get 1,000 calls to DrvBitBlt.
Now, your driver might decide it’s only interested in tracking part of
the screen. You could then reject calls that do not touch that part.
However, if you plan to maintain a real copy of the entire desktop, then
you have no choice.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.