DirectX data

NTDEV
1

Can somebody explain how the graphics data travels, starting from a DirectX call in user-mode right up to the framebuffer in the kernel?

Is there a particular kernel-mode DLL that DirectX uses?

-rup

2

xxxxx@gmail.com wrote:

Can somebody explain how the graphics data travels, starting from a DirectX call in user-mode right up to the framebuffer in the kernel?

The answer to this varies considerably depending on the DirectX version
and the display driver model (XPDM vs WDDM). Most of the Direct3D calls
map rather directly to entry points in the display driver. After all,
that’s the design goal of DirectX.

Is there a particular kernel-mode DLL that DirectX uses?

It starts with win32k.sys, but dxapi.sys and dxg.sys play a role as well.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

Hi Tim,

I would like to intercept the Direct X data. It appears, there is no documented way of doing that inside the kernel. Could a filter driver fit the purpose?

Please put these things in perspective for me:
(I’m new to driver programming)

Display driver kernel-mode miniport filter driver.
Dx API calls gdi32.dll d3d9.dll the Direct3D DDI
win32k.sys dxapi.sys dxg.sys dxgkrnl.sys

Is there a way to arrange them?

I learnt, “the kernel-mode miniport is non-filterable because the private contract with dxgkrnl.sys doesn’t go through the IO stack”. In that case, does the DirectX graphics information travel in IRPs at all? (If IRPs are ruled out, then is it worth looking at a filter driver to solve my problem?)

4

xxxxx@gmail.com wrote:

I would like to intercept the Direct X data. It appears, there is no documented way of doing that inside the kernel. Could a filter driver fit the purpose?

If you struck the word “documented” from that paragraph, I think you
would have a more accurate assessment of the situation. The DirectX
APIs were designed to be a direct pipeline from application to graphics
hardware. No convenient frameworks, no stacks, no filter mechanism.
Whatever you do is going to violate the “spirit” of the interface.

Please put these things in perspective for me:
(I’m new to driver programming)

Display driver kernel-mode miniport filter driver.
Dx API calls gdi32.dll d3d9.dll the Direct3D DDI
win32k.sys dxapi.sys dxg.sys dxgkrnl.sys

Is there a way to arrange them?

Probably, but I’m not sure it’s really going to help you.

application -> gdi32.dll -> win32k.sys -> display driver
<—/
|
-> miniport
|
V
dxgkrnl.sys

Dxapi.sys and dxg.sys allow other kernel drivers to use DirectX services.

I learnt, “the kernel-mode miniport is non-filterable because the private contract with dxgkrnl.sys doesn’t go through the IO stack”. In that case, does the DirectX graphics information travel in IRPs at all? (If IRPs are ruled out, then is it worth looking at a filter driver to solve my problem?)

When the display driver wants to call into the miniport, it calls back
into win32k.sys, which does generate an IRP to send to the miniport.
Those are the only IRPs that are involved in that whole driver graph.
The DirectX interface doesn’t use that.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

5

Two questions:

I found this line in an old NT Insider article on video driver: “…GDI does have a notion of “hooking” in DDI…”
Here’s the link to the article: http://www.osronline.com/article.cfm?article=66
(search for “hook” in the text)
Could you explain what ‘hooking’ means in this context ?

win32k.sys is the graphics rendering engine (GRE, also called the GDI, not to be confused with gdi32.dll which resides in user-mode.) of Windows. The DDI is inside the ‘display driver’(in the above diagram that you’ve drawn). The DDI calls back into win32k.sys.
If that’s true, then does the Direct3D DDI do the same thing - i.e. exposes a set of interfaces to win32k.sys?

6

  1. Hook in DDI means exposing a list of DDI functions, like DrvCopyBits and DrvTextOut in the function table pdrvfn (a member of DRVENABLEDATA, used in DrvEnableDriver), and specifying the appropriate hook flags when calling EngAssociateSurface. The DDK sample mirror driver shows how to do this. Some of these functions are mandatory.

  2. Your graphics driver needs export the DirectX interface functions too, if you want to support them. First you need functions like DrvGetDirectDrawInfo(), which is called when the display subsystem wants you to setup your DirectDraw / DirectX support data and functions.

Hope this helps!
Tim Green.

-----Original Message-----
From: xxxxx@lists.osr.com on behalf of xxxxx@gmail.com
Sent: Thu 04/10/2007 05:56
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DirectX data

Two questions:

I found this line in an old NT Insider article on video driver: “…GDI does have a notion of “hooking” in DDI…”
Here’s the link to the article: http://www.osronline.com/article.cfm?article=66
(search for “hook” in the text)
Could you explain what ‘hooking’ means in this context ?

win32k.sys is the graphics rendering engine (GRE, also called the GDI, not to be confused with gdi32.dll which resides in user-mode.) of Windows. The DDI is inside the ‘display driver’(in the above diagram that you’ve drawn). The DDI calls back into win32k.sys.
If that’s true, then does the Direct3D DDI do the same thing - i.e. exposes a set of interfaces to win32k.sys?