locked
Direct3DTexture9 causing page faults RRS feed

  • Question

  • Hi

    I am working on an application that uses DirectShow and Direct3D textures to process video with graphics on top. It captures the video frame using a grabber filter in my input graph. The frame is then placed in a Direct3DTexture9 for futher manipulation before passed on to the output graph.

    The application works, however after some hours (exactly how many differs) it starts running slower. Memory usage seems constant, however when running, the application creates about 20.000 page faults for each update in the process view of the Windows task manager. You can imagine this comes to a lot of page faults!

    After reading a bit about it, I got the impression that creating this amount of page faults could cause processes to slow down, so I would like to get rid of or at least minimize the number of them.

    I narrowed it down to that the page faults are caused by a call to D3DXCreateTexture, which creates the texture that I am copying the video frame to. Here is a code example:

    IDirect3DTexture *VideoCallback::CreateTexture(IMediaSample *p_pSample)
    {
         IDirect3DTexture9 *pTexture = NULL;
         HRESULT hr = D3DXCreateTexture(m_pD3DDevice, g_nWidth, g_nHeight, 1, 0, D3DFMT_X8R8G8B8, D3DPOOL_MANAGAGED, &pTexture);

    ...
    }

    If I skip these lines the number of page faults are reduced.

    So the questions are; Am I creating the texture in a wrong way and can it be done without causing page faults? And can the page faults cause the application to run slower after a while?

    Hope someone knows something about this!

    Best regards

    Rasmus

    Friday, May 7, 2010 8:20 AM

All replies

  • After more investigation, what slows down the application after a while is a call to GetDIBits, which copies a final bitmap of the 3D scene to an unsigned char buffer:

    ...

    unsigned char *pBuffer = new unsigned char[g_nWidth * g_nHeight * 4];
    BitBlt(m_hDstDC, 0, 0, g_nWidth, g_nHeight, m_hSrcDC, 0, 0, SRCCOPY);
    GetDIBits(m_hDstDC, m_hDstBitmap, 0, g_nHeight, g_nWidth, pBuffer, &m_biData, DIB_RGB_COLORS);

    ...

    Testing how long time calls take to each of those lines, shows me that the GetDIBits call suddently starts using about 30-40 milliseconds for each call, where it started out with well below 20 ms.

    Does anyone know what could cause GetDIBits to suddently run slower? I have been keeping an eye on memory usage and virtual memory usage through the task manager, and both seems to be stabile. Is there something else that could be leaking, and how can I figure out what it is?

    Thanks in advance!

    Rasmus

    Friday, May 7, 2010 2:40 PM