Fix InProcessCommandBuffer::OrderingBarrier(). |
||
Issue descriptionInProcessCommandBuffer calls Flush() every time OrderingBarrier() is called. This isn't necessary and could have some performance impact. Since there is no shared GPU channel for InProcessCommandBuffer we don't need to do anything immediately for OrderingBarrier(), but we do need to call Flush() with the right put_offset if FlushPendingWork() gets called afterwards. I think the following changes would work: 1. InProcessCommandBuffer::OrderingBarrier() shouldn't call Flush(). Instead it should store |put_offset| in a member variable. 2. InProcessCommandBuffer::Flush() should reset the stored |put_offset|. 3. InProcessCommandBuffer::FlushPendingWork() should call Flush() with the stored |put_offset| if there is a value stored there. It's not clear if InProcessCommandBuffer::EnsureWorkVisible() should change. piman@ mentioned changing it in slack, but the description on GpuControl::EnsureWorkVisible() specifies it's a no-op for in process command buffers.
,
Sep 10
I thought this was necessary too, and https://chromium-review.googlesource.com/c/chromium/src/+/1200414/1 implements OrderingBarrier the way suggested above. However, OrderingBarrier is only called by viz for the sync token sent back to clients. This sync token is immediately verified, and verification certainly needs flushing and posting a task to the scheduler which is now done by the OrderingBarrier. So there would be not practical benefit in implementing OrderingBarrier.
,
Sep 10
|
||
►
Sign in to add a comment |
||
Comment 1 by piman@chromium.org
, Sep 10