XNA Creators Club Online
Page 1 of 1 (5 items)
Sort Posts: Previous Next

Fastest way to update CPU generated textures

Last post 7/10/2009 6:49 AM by GregDude. 4 replies.
  • 7/7/2009 1:24 AM

    Fastest way to update CPU generated textures

    I was wondering what the fastest way to update textures generated via the CPU was.
    In the past, I only updated textures infrequently, or at low rates, but now I want to update every frame.
    I used to write to a system allocated block of memory then lock a D3D texture surface and memcpy the bits.

    Looking at the D3D docs, I see...

    " For dynamic textures, it is sometimes desirable to use a pair of video memory and system memory textures,
      allocating the video memory using D3DPOOL_DEFAULT and the system memory using D3DPOOL_SYSTEMMEM.
      You can lock and modify the bits of the system memory texture using a locking method. Then you can update
      the video memory texture using IDirect3DDevice9::UpdateTexture. "

    My app does this:
    Writes 32bit RGBA color bits to a texture.
    Writes are somewhat random (not just sequential spans or block copies)
    That generated texture is rendered by D3D on the same frame.
    Although the 'same frame' does CPU updating and GPU rendering, they are not explicitly locked in sync.
    The CPU does not need to read back or modify an older version of the texture.
    The whole CPU process is relatively slow, so I would need to lock a surface for some milliseconds if I output directly to a D3D surface instead of locking just to memcpy.

    I presume it might be useful to not only create system and video memory textures, but create at least 2 sets to effectively double buffer, preventing buffered frames from waiting for me to release my lock.

    I was wondering if anyone using dynamic textures has a recommendation here to save me trialing every possible way to accomplish this.
  • 7/7/2009 5:13 AM In reply to

    Re: Fastest way to update CPU generated textures

    What you're describing is why the dynamic usage flag was created, so I would try that. If its too slow, then take a look at what PIX says about how you're using resources. If you're spin-waiting on locks a lot, its resource contention that could be relieved by a simple double or triple buffering scheme.

  • 7/8/2009 12:37 PM In reply to

    Re: Fastest way to update CPU generated textures

    Fair enough.  I just tried locking the texture directly and writing instead of locking a surface to copy from system memory.  I gained a few FPS.  I also tried multi buffering but got no benefit from this, in fact tripple buffering the texture benched slightly slower.  It is possible the D3D implementation does internal buffering, it certainly does for VBs and IBs.  I am testing Windows platform here.  Not sure if the same would be true for Xbox 360 which tends to do less automatic management.  I did not try the UpdateTexture() method.
  • 7/8/2009 4:43 PM In reply to

    Re: Fastest way to update CPU generated textures

    If you use dynamic textures Direct3D/the driver will create shadow copies by it’s own. Beside of this the driver can do additional things. They often contain workarounds for bad application behaviors.

    Therefore you should always test with different cards from different manufacture.
  • 7/10/2009 6:49 AM In reply to

    Re: Fastest way to update CPU generated textures

    Thanks for the info Ralf. I'll keep the platform testing in mind when this is no longer experimental code.
Page 1 of 1 (5 items) Previous Next