views:

143

answers:

3

In error reports from some I have quite often seen following behaviour: IDirect3DVertexBuffer9::Lock fails, returned error code is D3DERR_NOTAVAILABLE.

Once this happens, quite frequently (but not always) it is followed by CreateTexture or CreateVertexBuffer failing with error D3DERR_OUTOFVIDEOMEMORY.

What are possible reasons for vertex buffer lock failure? Could virtual memory address space exhausted, or what?

A: 

This is what I posted to DirectXDev: ;)

Have you checked how much memory your application is using? (Be sure to select the Virtual Memory column in Task Manager!). My guess would be memory fragmentation based issues causing you to, as you suggest, run out of address space.

It could, however, be a driver bug ...

Does the debug runtime provide any useful information?

Edit: The only other thing I can think of is that the aperture memory has run out. I don't know how this works with PCIExpress but on AGP you can set the aperture size. I've no idea how to check if it is full however. I suspect the error you are seeing is reporting that its full. Are you doing lots of locks with the Discard flag? If so its possible that these are creating tonnes of new allocations in the aperture and is causing you to run out of memory there. This is pure guess work however.

I'd guess that if this is happening with only some of your users it is those on the lower end machines. If things run slowly then you can end up with a lot of data buffered in the command buffer. This will make control laggy and "could", at a guess, lead to the problem you are seeing. You may want to try making sure the command buffer never gets too long. If you make sure the first lock of every frame is done without the discard flag (ie flag set to 0) then this will cause the pipeline to stall until the vertex buffer has been rendered and bring the command buffer back in sync with you. This will cause a slow down as the command buffering will not be able to smooth out frame rate spikes as easily ...

Anyway ... thats just a guess!

Goz
Yes, I did. There seems to be a plenty of virtual memory. I have even tested one more think, and I have traversed and queried whole VM range to checker if perhaps the free VM space is heavily fragmented. The largest available free space was 255 MB, therefore VM address should not be problem in this case.
Suma
As for the driver bug, I have experienced it with both nVidia and AMD cards.
Suma
> Does the debug runtime provide any useful information?I do not know. I have never seen it on my system, I get it only from users.
Suma
Ahh ... thats a problem. Have you confirmed they have up-to-date drivers? Failing that without getting hold of a machine that displays the error and provides information it could be quite difficult.
Goz
A: 

The raised issue about out of memory is valid. We need some details on the Lock() call to be sure, but for example if it is in the DEFAULT pool and if it's dynamic (D3DLOCK_DISCARD flag passed), it's very well possible that your driver tries to find an unused piece of memory to return (because it double or triple buffers internally) and fails because, as you discover yourself soon after, video memory is exhausted.

nj
A: 

Based on the DIRECTXDEV response by Chuck Walbourn from Microsoft, besides of "out of address space" another cause could be "out of page pool".

Alternatively, on Windows XP this could indicate you have hit the limits of paged pool kernel memory. Typically this happens when you create a lot of Direct3D resources (textures, etc.)

We DO create a lot of Direct3D resources.

Suma