On 17/12/2018 21:42, Henri Verbeet wrote:
On Thu, 13 Dec 2018 at 21:00, Axel Davy davyaxel0@gmail.com wrote:
Why not always allocate SYSTEMMEM buffers into GPU memory ? For example, GTT memory (without WC, thus fast cpu read), with persistent flags, which means you don't need to unlock. Then no upload is needed.
What Matteo said, but also because the documentation claims that pretty much the only reason for drawing from D3DPOOL_SYSTEMMEM buffers (as opposed to DEFAULT+DYNAMIC) is to limit GTT memory usage.
Henri
I couldn't find the results of the tests we ran for locking flags and behaviors when doing double lock, or lock write draw write unlock, though I have the patch if you are interested to run it.
In the code I see the following comments which should be interesting for your implementation (I don't remember if the comments are true for all vendors or only on one):
(Test drawing with data write outside of locked area - after a first draw)
* Test shows that buffers start dirty: * The whole buffer is uploaded before first draw call. * Test shows that D3DPOOL_DEFAULT and D3DPOOL_SYSTEMMEM are always * locked RW and the whole buffer is uploaded. * Test shows that D3DPOOL_MANAGED is always locked RW and only the region * locked is marked dirty and uploaded (except after creation).
(Test drawing while locked) * Test shows that it is possible to draw using a locked buffer and no error is generated. * For D3DPOOL_SYSTEMMEM the content of the buffer at draw call is used, for other * pools it is possible that the upload takes longer than the draw call. (race condition)
To me using GTT looks good for SYSTEMMEM. You can also do an upload, but you must be careful.
Axel