[PATCH 1/5] d3d9: Support drawing from D3DPOOL_SYSTEMMEM vertex buffers.

Axel Davy davyaxel0 at gmail.com
Mon Dec 17 16:12:57 CST 2018


On 17/12/2018 21:42, Henri Verbeet wrote:
> On Thu, 13 Dec 2018 at 21:00, Axel Davy <davyaxel0 at 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




More information about the wine-devel mailing list