New issue
Advanced search Search tips

Issue 882437 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Sep 10
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Blocking:
issue 845593



Sign in to add a comment

Fix InProcessCommandBuffer::OrderingBarrier().

Project Member Reported by kylec...@chromium.org, Sep 10

Issue description

InProcessCommandBuffer 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.
 
EnsureWorkVisible should absolutely change (to do Flush, essentially, though beware of threading concerns as it's expected to be called from any thread). It's specified to do a no-op *because* OrderingBarrier calls Flush directly.

There is some interaction with the in-process SharedImageInterface though, as it currently runs on the same sequence, and so we need to ensure ordering between OrderingBarrier and SharedImageInterface calls that signal/depend on sync tokens (CreateSharedImage, DestroySharedImage)
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.
Status: WontFix (was: Assigned)

Sign in to add a comment