4 ms·

This is an excellent question. The current wine implementation using OpenGL should mirror the behaviour of D3D, since it is using glMapBufferRange and passing G

by twtw 9y ago

This is an excellent question. The current wine implementation using OpenGL should mirror the behaviour of D3D, since it is using glMapBufferRange and passing GL_MAP_UNSYNCHRONIZED_BIT when possible. I am also wondering what is actually going on that is hurting performance. EDIT: After further research and more thought, I suspect that the "pipeline stall" doesn't involve waiting for the GPU to complete work using the buffer, just waiting for the driver. The map/unmap with overwrite or discard is working as intended, but the persistent buffer heap he implemented outperforms it because it reduces the number of calls into the driver required. I initially had the impression that the existing wine implementation was somehow deficient, but really what the author did was find a way to use the new persistent buffers feature to optimize D3D code using the older per-frame map/unmap method. This is in fact what the post essentially said (after a re-read), I just misunderstood and thought the pipeline stall was actually waiting for the GPU. The note in the post about the "GPU" line really being the driver is important.

acomminos 9y ago
There's two main parts to the stall, which aren't well illustrated by the diagram (I'll get on updating it): 1. Waiting for the resource to exit the command stream (wined3d_resource_wait_idle). 2. Waiting for the CS thread to finish after the map (occurs in wined3d_cs_map). It's a pipeline stall because the D3D thread has to wait for the CS thread to do things, and thus is unable to dispatch more commands to the CS (and thus the GPU) during this time. I don't consider the actual glMapBufferRange to be part of the stall. Edit: saw your edit :)
- twtw 9y ago
  Thanks for clarifying, that makes sense. I'm glad you saw the edit. I initially wrote it based on my first interpretation of what you wrote, but after re-reading I realized that your description was totally accurate, I just misunderstood. Great work, and thanks for writing it up.

by twtw 9y ago

acomminos 9y ago

There's two main parts to the stall, which aren't well illustrated by the diagram (I'll get on updating it): 1. Waiting for the resource to exit the command stream (wined3d_resource_wait_idle). 2. Waiting for the CS thread to finish after the map (occurs in wined3d_cs_map). It's a pipeline stall because the D3D thread has to wait for the CS thread to do things, and thus is unable to dispatch more commands to the CS (and thus the GPU) during this time. I don't consider the actual glMapBufferRange to be part of the stall. Edit: saw your edit :)

twtw 9y ago
Thanks for clarifying, that makes sense. I'm glad you saw the edit. I initially wrote it based on my first interpretation of what you wrote, but after re-reading I realized that your description was totally accurate, I just misunderstood. Great work, and thanks for writing it up.