Hi folks,
Iam trying to hardware accelerate DrvTransparentBlt call in graphics driver.
But as a performance requirement DrvtransParentBlt shall try accelerating
only when source mem and dest mem bothe are video mem. In general I didn’t
see any scenario including the general benchmark tools are crystal mark and
winbench using video mem as source. Is someone aware of any tool which will
help get a scenario where the accelerated part of the code will get hit,
i.e. which will use source mem as video mem?
Please let me know.
Thanks,
Namrta
Namrta Salonie wrote:
Hi folks,
Iam trying to hardware accelerate DrvTransparentBlt call in graphics
driver. But as a performance requirement DrvtransParentBlt shall try
accelerating only when source mem and dest mem bothe are video mem. In
general I didn’t see any scenario including the general benchmark
tools are crystal mark and winbench using video mem as source. Is
someone aware of any tool which will help get a scenario where the
accelerated part of the code will get hit, i.e. which will use source
mem as video mem?
If your hardware can only accelerate screen-to-screen transparent blits,
then you probably have a useless hardware feature. Transparency is
almost always used to compose things from bitmaps onto the screen, not
from screen to screen.
You could certainly write your own test case for this.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
This is an excerpt from the DDK, where transparency has been defined as
giving max performance thrust when is used from screen to screen and in all
other cases it has been advised to punt the call to GDI engine. Am I missing
something?
“Bit-block transfer with transparency is supported between two
device-managed surfaces or between a device-managed surface and a
GDI-managed standard format bitmap. *Driver writers are encouraged to
support the case of blting from off-screen device bitmaps in video memory to
other surfaces in video memory;* all other cases can be punted to
EngTransparentBlt with little performance penalty. The driver can punt calls
involving device-managed surfaces to *EngTransparentBlt*.”
I just followed this guideline, as such do not have any hardware limitation
of not being able to accelerate bitmap to screen blit.
Thanks,
Namrta
On 8/7/08, Tim Roberts wrote:
>
> Namrta Salonie wrote:
>
>> Hi folks,
>> Iam trying to hardware accelerate DrvTransparentBlt call in graphics
>> driver. But as a performance requirement DrvtransParentBlt shall try
>> accelerating only when source mem and dest mem bothe are video mem. In
>> general I didn’t see any scenario including the general benchmark tools are
>> crystal mark and winbench using video mem as source. Is someone aware of any
>> tool which will help get a scenario where the accelerated part of the code
>> will get hit, i.e. which will use source mem as video mem?
>>
>
> If your hardware can only accelerate screen-to-screen transparent blits,
> then you probably have a useless hardware feature. Transparency is almost
> always used to compose things from bitmaps onto the screen, not from screen
> to screen.
>
> You could certainly write your own test case for this.
>
> –
> 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
>