Revert of gpu: GPU service scheduler.

Revert of gpu: GPU service scheduler. (patchset #18 id:340001 of https://codereview.chromium.org/2814843002/ )

Reason for revert:
Suspected of breaking the Win7 Tests (dbg)(1) builder:

https://build.chromium.org/p/chromium.win/builders/Win7%20Tests%20%28dbg%29%281%29/builds/59869

Sample stack trace:

[6424:6796:0512/085713.197:FATAL:gpu_channel.cc(122)] Check failed: channel_messages_.empty(). 
Backtrace:
	base::debug::StackTrace::StackTrace [0x100AD557+55]
	base::debug::StackTrace::StackTrace [0x100AD1F1+17]
	logging::LogMessage::~LogMessage [0x1010103E+94]
	gpu::GpuChannelMessageQueue::~GpuChannelMessageQueue [0x0AA6A1DE+126]
	gpu::GpuChannelMessageQueue::`scalar deleting destructor' [0x0AA6D13F+15]
	base::RefCountedThreadSafe<gpu::GpuChannelMessageQueue,base::DefaultRefCountedThreadSafeTraits<gpu::GpuChannelMessageQueue> >::DeleteInternal [0x0AA6E4A2+34]
	base::DefaultRefCountedThreadSafeTraits<gpu::GpuChannelMessageQueue>::Destruct [0x0AA6E7BC+12]
	base::RefCountedThreadSafe<gpu::GpuChannelMessageQueue,base::DefaultRefCountedThreadSafeTraits<gpu::GpuChannelMessageQueue> >::Release [0x0AA731D0+32]
	scoped_refptr<gpu::GpuChannelMessageQueue>::Release [0x0AA7323B+11]
	scoped_refptr<gpu::GpuChannelMessageQueue>::~scoped_refptr<gpu::GpuChannelMessageQueue> [0x0AA69A5A+26]
	gpu::GpuChannelMessageFilter::~GpuChannelMessageFilter [0x0AA6A0F7+151]
	gpu::GpuChannelMessageFilter::`vector deleting destructor' [0x0AA6CC4D+77]
	base::RefCountedThreadSafe<IPC::MessageFilter,base::DefaultRefCountedThreadSafeTraits<IPC::MessageFilter> >::DeleteInternal [0x0B154D27+39]
	base::DefaultRefCountedThreadSafeTraits<IPC::MessageFilter>::Destruct [0x0B154F3C+12]
	base::RefCountedThreadSafe<IPC::MessageFilter,base::DefaultRefCountedThreadSafeTraits<IPC::MessageFilter> >::Release [0x0B1565DA+58]
	scoped_refptr<IPC::MessageFilter>::Release [0x0B15662E+14]
	scoped_refptr<IPC::MessageFilter>::~scoped_refptr<IPC::MessageFilter> [0x0B152A7A+26]
	scoped_refptr<IPC::MessageFilter>::`scalar deleting destructor' [0x0B15411F+15]
	std::allocator<scoped_refptr<IPC::MessageFilter> >::destroy<scoped_refptr<IPC::MessageFilter> > [0x0B151261+17]
	std::allocator_traits<std::allocator<scoped_refptr<IPC::MessageFilter> > >::destroy<scoped_refptr<IPC::MessageFilter> > [0x0B15127F+15]
	std::_Wrap_alloc<std::allocator<scoped_refptr<IPC::MessageFilter> > >::destroy<scoped_refptr<IPC::MessageFilter> > [0x0B151234+20]
	std::_Destroy_range1<std::allocator<scoped_refptr<IPC::MessageFilter> >,scoped_refptr<IPC::MessageFilter> *> [0x0B15074B+43]
	std::_Destroy_range<std::allocator<scoped_refptr<IPC::MessageFilter> >,scoped_refptr<IPC::MessageFilter> *> [0x0B1507AA+26]
	std::vector<scoped_refptr<IPC::MessageFilter>,std::allocator<scoped_refptr<IPC::MessageFilter> > >::_Destroy [0x0B15740D+29]
	std::vector<scoped_refptr<IPC::MessageFilter>,std::allocator<scoped_refptr<IPC::MessageFilter> > >::clear [0x0B15878E+46]
	IPC::ChannelProxy::Context::OnChannelClosed [0x0B1558EB+395]
	IPC::SyncChannel::SyncContext::OnChannelClosed [0x0B190416+38]
	??$Invoke@ABV?$scoped_refptr@VContext@ChannelProxy@IPC@@@@$$V@?$FunctorTraits@P8Context@ChannelProxy@IPC@@AEXXZX@internal@base@@SAXP8Context@ChannelProxy@IPC@@AEXXZABV?$scoped_refptr@VContext@ChannelProxy@IPC@@@@@Z [0x0B14F978+24]
	base::internal::InvokeHelper<0,void>::MakeItSo<void (__thiscall IPC::ChannelProxy::Context::*const &)(void),scoped_refptr<IPC::ChannelProxy::Context> const &> [0x0B1500B8+40]
	base::internal::Invoker<base::internal::BindState<void (__thiscall IPC::ChannelProxy::Context::*)(void),scoped_refptr<IPC::ChannelProxy::Context> >,void __cdecl(void)>::RunImpl<void (__thiscall IPC::ChannelProxy::Context::*const &)(void),std::tuple<scoped [0x0B1504A4+52]
	base::internal::Invoker<base::internal::BindState<void (__thiscall IPC::ChannelProxy::Context::*)(void),scoped_refptr<IPC::ChannelProxy::Context> >,void __cdecl(void)>::Run [0x0B156904+36]
	base::Callback<void __cdecl(void),0,0>::Run [0x10049A45+53]
	base::debug::TaskAnnotator::RunTask [0x100B444C+476]
	base::MessageLoop::RunTask [0x1012F94C+620]
	base::MessageLoop::DeferOrRunPendingTask [0x1012DE4B+43]
	base::MessageLoop::DoWork [0x1012E44F+239]
	base::MessagePumpForIO::DoRunLoop [0x10136211+33]
	base::MessagePumpWin::Run [0x101372FB+123]
	base::MessageLoop::RunHandler [0x1012F5C5+293]
	base::RunLoop::Run [0x101EDB26+166]
	base::Thread::Run [0x10289D01+273]
	base::Thread::ThreadMain [0x1028AE4F+863]
	base::PlatformThread::Sleep [0x102659EC+380]
	BaseThreadInitThunk [0x76A9338A+18]
	RtlInitializeExceptionChain [0x77A39902+99]
	RtlInitializeExceptionChain [0x77A398D5+54]

Original issue's description:
> gpu: GPU service scheduler.
> 
> The GPU service scheduler runs tasks (closures) containing command
> buffer work. Tasks are enqueued in sequences which represent indepdent
> streams of execution. A task in one sequence may wait on a sync token
> fence that's released on another sequence. Tasks can specify their sync
> token fences beforehand so that the scheduler won't run a sequence only
> to disable it due to a sync token wait. Tasks can check if they should
> yield so that a higher priority task may run. If a task decides to
> yield, it can continue execution by supplying a new closure which will
> run before any other scheduled tasks in that sequence.
> 
> The scheduler maintains a priority queue of sequences ordered by
> sequence priority and then order number. Priority inversion because of
> sync token dependencies is handled by a simple priority ceiling scheme.
> Sequences which are expected to release sync tokens dependencies are
> assigned a priority (HIGH) that's higher than any client specified
> priorities. However, browser view context sequences can have an even
> higher priority (REAL_TIME).
> 
> GPU channel IPC messages are run as tasks in the scheduler. Each client
> side stream is mapped to a sequence. The client is expected to use a
> small number of streams to partition its command buffers so there is no
> tracking of stream lifetimes in the service. The message filter posts
> messages as tasks. AsyncFlush is the only message for which sync token
> dependencies are given to the scheduler.
> 
> The initial implementation uses the GPU main thread to run scheduled
> tasks. Future implementations, for example, could use a worker pool
> with task traits to specify which thread a task should run on.
> 
> R=piman@chromium.org
> BUG=514813
> CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
> 
> Review-Url: https://codereview.chromium.org/2814843002
> Cr-Commit-Position: refs/heads/master@{#471187}
> Committed: https://chromium.googlesource.com/chromium/src/+/e7e36ccdaa3fcf63b330bc956eeeb73abf7c39ea

TBR=piman@chromium.org,vmiura@chromium.org,dcheng@chromium.org,sadrul@chromium.org,sunnyps@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=514813
Review-Url: https://codereview.chromium.org/2881813002
Cr-Commit-Position: refs/heads/master@{#471335}
Committed: https://chromium.googlesource.com/chromium/src/+/9d3cbf5bb0cca7fdcbfa22c63a18008e242f3bc9

[Justin Donnelly, 2017-05-12 16:43:44]

The CQ bit was checked by jdonnelly@chromium.org

[Justin Donnelly, 2017-05-12 16:43:45]

Created Revert of gpu: GPU service scheduler.

[commit-bot: I haz the power, 2017-05-12 16:44:15]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-12 16:45:44]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1494607424828940, "parent_rev":
"a999f951a26f1fece78238836b198999b0050ae6", "commit_rev":
"9d3cbf5bb0cca7fdcbfa22c63a18008e242f3bc9"}

[commit-bot: I haz the power, 2017-05-12 16:45:58]

Description was changed from

==========
Revert of gpu: GPU service scheduler. (patchset #18 id:340001 of
https://codereview.chromium.org/2814843002/ )

Reason for revert:
Suspected of breaking the Win7 Tests (dbg)(1) builder:

https://build.chromium.org/p/chromium.win/builders/Win7%20Tests%20%28dbg%29%2...

Sample stack trace:

[6424:6796:0512/085713.197:FATAL:gpu_channel.cc(122)] Check failed:
channel_messages_.empty(). 
Backtrace:
	base::debug::StackTrace::StackTrace [0x100AD557+55]
	base::debug::StackTrace::StackTrace [0x100AD1F1+17]
	logging::LogMessage::~LogMessage [0x1010103E+94]
	gpu::GpuChannelMessageQueue::~GpuChannelMessageQueue [0x0AA6A1DE+126]
	gpu::GpuChannelMessageQueue::`scalar deleting destructor' [0x0AA6D13F+15]
	base::RefCountedThreadSafe<gpu::GpuChannelMessageQueue,base::DefaultRefCountedThreadSafeTraits<gpu::GpuChannelMessageQueue>
>::DeleteInternal [0x0AA6E4A2+34]
	base::DefaultRefCountedThreadSafeTraits<gpu::GpuChannelMessageQueue>::Destruct
[0x0AA6E7BC+12]
	base::RefCountedThreadSafe<gpu::GpuChannelMessageQueue,base::DefaultRefCountedThreadSafeTraits<gpu::GpuChannelMessageQueue>
>::Release [0x0AA731D0+32]
	scoped_refptr<gpu::GpuChannelMessageQueue>::Release [0x0AA7323B+11]
	scoped_refptr<gpu::GpuChannelMessageQueue>::~scoped_refptr<gpu::GpuChannelMessageQueue>
[0x0AA69A5A+26]
	gpu::GpuChannelMessageFilter::~GpuChannelMessageFilter [0x0AA6A0F7+151]
	gpu::GpuChannelMessageFilter::`vector deleting destructor' [0x0AA6CC4D+77]
	base::RefCountedThreadSafe<IPC::MessageFilter,base::DefaultRefCountedThreadSafeTraits<IPC::MessageFilter>
>::DeleteInternal [0x0B154D27+39]
	base::DefaultRefCountedThreadSafeTraits<IPC::MessageFilter>::Destruct
[0x0B154F3C+12]
	base::RefCountedThreadSafe<IPC::MessageFilter,base::DefaultRefCountedThreadSafeTraits<IPC::MessageFilter>
>::Release [0x0B1565DA+58]
	scoped_refptr<IPC::MessageFilter>::Release [0x0B15662E+14]
	scoped_refptr<IPC::MessageFilter>::~scoped_refptr<IPC::MessageFilter>
[0x0B152A7A+26]
	scoped_refptr<IPC::MessageFilter>::`scalar deleting destructor' [0x0B15411F+15]
	std::allocator<scoped_refptr<IPC::MessageFilter>
>::destroy<scoped_refptr<IPC::MessageFilter> > [0x0B151261+17]
	std::allocator_traits<std::allocator<scoped_refptr<IPC::MessageFilter> >
>::destroy<scoped_refptr<IPC::MessageFilter> > [0x0B15127F+15]
	std::_Wrap_alloc<std::allocator<scoped_refptr<IPC::MessageFilter> >
>::destroy<scoped_refptr<IPC::MessageFilter> > [0x0B151234+20]
	std::_Destroy_range1<std::allocator<scoped_refptr<IPC::MessageFilter>
>,scoped_refptr<IPC::MessageFilter> *> [0x0B15074B+43]
	std::_Destroy_range<std::allocator<scoped_refptr<IPC::MessageFilter>
>,scoped_refptr<IPC::MessageFilter> *> [0x0B1507AA+26]
	std::vector<scoped_refptr<IPC::MessageFilter>,std::allocator<scoped_refptr<IPC::MessageFilter>
> >::_Destroy [0x0B15740D+29]
	std::vector<scoped_refptr<IPC::MessageFilter>,std::allocator<scoped_refptr<IPC::MessageFilter>
> >::clear [0x0B15878E+46]
	IPC::ChannelProxy::Context::OnChannelClosed [0x0B1558EB+395]
	IPC::SyncChannel::SyncContext::OnChannelClosed [0x0B190416+38]
	??$Invoke@ABV?$scoped_refptr@VContext@ChannelProxy@IPC@@@@$$V@?$FunctorTraits@P8Context@ChannelProxy@IPC@@AEXXZX@internal@base@@SAXP8Context@ChannelProxy@IPC@@AEXXZABV?$scoped_refptr@VContext@ChannelProxy@IPC@@@@@Z
[0x0B14F978+24]
	base::internal::InvokeHelper<0,void>::MakeItSo<void (__thiscall
IPC::ChannelProxy::Context::*const
&)(void),scoped_refptr<IPC::ChannelProxy::Context> const &> [0x0B1500B8+40]
	base::internal::Invoker<base::internal::BindState<void (__thiscall
IPC::ChannelProxy::Context::*)(void),scoped_refptr<IPC::ChannelProxy::Context>
>,void __cdecl(void)>::RunImpl<void (__thiscall
IPC::ChannelProxy::Context::*const &)(void),std::tuple<scoped [0x0B1504A4+52]
	base::internal::Invoker<base::internal::BindState<void (__thiscall
IPC::ChannelProxy::Context::*)(void),scoped_refptr<IPC::ChannelProxy::Context>
>,void __cdecl(void)>::Run [0x0B156904+36]
	base::Callback<void __cdecl(void),0,0>::Run [0x10049A45+53]
	base::debug::TaskAnnotator::RunTask [0x100B444C+476]
	base::MessageLoop::RunTask [0x1012F94C+620]
	base::MessageLoop::DeferOrRunPendingTask [0x1012DE4B+43]
	base::MessageLoop::DoWork [0x1012E44F+239]
	base::MessagePumpForIO::DoRunLoop [0x10136211+33]
	base::MessagePumpWin::Run [0x101372FB+123]
	base::MessageLoop::RunHandler [0x1012F5C5+293]
	base::RunLoop::Run [0x101EDB26+166]
	base::Thread::Run [0x10289D01+273]
	base::Thread::ThreadMain [0x1028AE4F+863]
	base::PlatformThread::Sleep [0x102659EC+380]
	BaseThreadInitThunk [0x76A9338A+18]
	RtlInitializeExceptionChain [0x77A39902+99]
	RtlInitializeExceptionChain [0x77A398D5+54]

Original issue's description:
> gpu: GPU service scheduler.
> 
> The GPU service scheduler runs tasks (closures) containing command
> buffer work. Tasks are enqueued in sequences which represent indepdent
> streams of execution. A task in one sequence may wait on a sync token
> fence that's released on another sequence. Tasks can specify their sync
> token fences beforehand so that the scheduler won't run a sequence only
> to disable it due to a sync token wait. Tasks can check if they should
> yield so that a higher priority task may run. If a task decides to
> yield, it can continue execution by supplying a new closure which will
> run before any other scheduled tasks in that sequence.
> 
> The scheduler maintains a priority queue of sequences ordered by
> sequence priority and then order number. Priority inversion because of
> sync token dependencies is handled by a simple priority ceiling scheme.
> Sequences which are expected to release sync tokens dependencies are
> assigned a priority (HIGH) that's higher than any client specified
> priorities. However, browser view context sequences can have an even
> higher priority (REAL_TIME).
> 
> GPU channel IPC messages are run as tasks in the scheduler. Each client
> side stream is mapped to a sequence. The client is expected to use a
> small number of streams to partition its command buffers so there is no
> tracking of stream lifetimes in the service. The message filter posts
> messages as tasks. AsyncFlush is the only message for which sync token
> dependencies are given to the scheduler.
> 
> The initial implementation uses the GPU main thread to run scheduled
> tasks. Future implementations, for example, could use a worker pool
> with task traits to specify which thread a task should run on.
> 
> R=piman@chromium.org
> BUG=514813
>
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
> 
> Review-Url: https://codereview.chromium.org/2814843002
> Cr-Commit-Position: refs/heads/master@{#471187}
> Committed:
https://chromium.googlesource.com/chromium/src/+/e7e36ccdaa3fcf63b330bc956eee...

TBR=piman@chromium.org,vmiura@chromium.org,dcheng@chromium.org,sadrul@chromiu...
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=514813
==========

to

==========
Revert of gpu: GPU service scheduler. (patchset #18 id:340001 of
https://codereview.chromium.org/2814843002/ )

Reason for revert:
Suspected of breaking the Win7 Tests (dbg)(1) builder:

https://build.chromium.org/p/chromium.win/builders/Win7%20Tests%20%28dbg%29%2...

Sample stack trace:

[6424:6796:0512/085713.197:FATAL:gpu_channel.cc(122)] Check failed:
channel_messages_.empty(). 
Backtrace:
	base::debug::StackTrace::StackTrace [0x100AD557+55]
	base::debug::StackTrace::StackTrace [0x100AD1F1+17]
	logging::LogMessage::~LogMessage [0x1010103E+94]
	gpu::GpuChannelMessageQueue::~GpuChannelMessageQueue [0x0AA6A1DE+126]
	gpu::GpuChannelMessageQueue::`scalar deleting destructor' [0x0AA6D13F+15]
	base::RefCountedThreadSafe<gpu::GpuChannelMessageQueue,base::DefaultRefCountedThreadSafeTraits<gpu::GpuChannelMessageQueue>
>::DeleteInternal [0x0AA6E4A2+34]
	base::DefaultRefCountedThreadSafeTraits<gpu::GpuChannelMessageQueue>::Destruct
[0x0AA6E7BC+12]
	base::RefCountedThreadSafe<gpu::GpuChannelMessageQueue,base::DefaultRefCountedThreadSafeTraits<gpu::GpuChannelMessageQueue>
>::Release [0x0AA731D0+32]
	scoped_refptr<gpu::GpuChannelMessageQueue>::Release [0x0AA7323B+11]
	scoped_refptr<gpu::GpuChannelMessageQueue>::~scoped_refptr<gpu::GpuChannelMessageQueue>
[0x0AA69A5A+26]
	gpu::GpuChannelMessageFilter::~GpuChannelMessageFilter [0x0AA6A0F7+151]
	gpu::GpuChannelMessageFilter::`vector deleting destructor' [0x0AA6CC4D+77]
	base::RefCountedThreadSafe<IPC::MessageFilter,base::DefaultRefCountedThreadSafeTraits<IPC::MessageFilter>
>::DeleteInternal [0x0B154D27+39]
	base::DefaultRefCountedThreadSafeTraits<IPC::MessageFilter>::Destruct
[0x0B154F3C+12]
	base::RefCountedThreadSafe<IPC::MessageFilter,base::DefaultRefCountedThreadSafeTraits<IPC::MessageFilter>
>::Release [0x0B1565DA+58]
	scoped_refptr<IPC::MessageFilter>::Release [0x0B15662E+14]
	scoped_refptr<IPC::MessageFilter>::~scoped_refptr<IPC::MessageFilter>
[0x0B152A7A+26]
	scoped_refptr<IPC::MessageFilter>::`scalar deleting destructor' [0x0B15411F+15]
	std::allocator<scoped_refptr<IPC::MessageFilter>
>::destroy<scoped_refptr<IPC::MessageFilter> > [0x0B151261+17]
	std::allocator_traits<std::allocator<scoped_refptr<IPC::MessageFilter> >
>::destroy<scoped_refptr<IPC::MessageFilter> > [0x0B15127F+15]
	std::_Wrap_alloc<std::allocator<scoped_refptr<IPC::MessageFilter> >
>::destroy<scoped_refptr<IPC::MessageFilter> > [0x0B151234+20]
	std::_Destroy_range1<std::allocator<scoped_refptr<IPC::MessageFilter>
>,scoped_refptr<IPC::MessageFilter> *> [0x0B15074B+43]
	std::_Destroy_range<std::allocator<scoped_refptr<IPC::MessageFilter>
>,scoped_refptr<IPC::MessageFilter> *> [0x0B1507AA+26]
	std::vector<scoped_refptr<IPC::MessageFilter>,std::allocator<scoped_refptr<IPC::MessageFilter>
> >::_Destroy [0x0B15740D+29]
	std::vector<scoped_refptr<IPC::MessageFilter>,std::allocator<scoped_refptr<IPC::MessageFilter>
> >::clear [0x0B15878E+46]
	IPC::ChannelProxy::Context::OnChannelClosed [0x0B1558EB+395]
	IPC::SyncChannel::SyncContext::OnChannelClosed [0x0B190416+38]
	??$Invoke@ABV?$scoped_refptr@VContext@ChannelProxy@IPC@@@@$$V@?$FunctorTraits@P8Context@ChannelProxy@IPC@@AEXXZX@internal@base@@SAXP8Context@ChannelProxy@IPC@@AEXXZABV?$scoped_refptr@VContext@ChannelProxy@IPC@@@@@Z
[0x0B14F978+24]
	base::internal::InvokeHelper<0,void>::MakeItSo<void (__thiscall
IPC::ChannelProxy::Context::*const
&)(void),scoped_refptr<IPC::ChannelProxy::Context> const &> [0x0B1500B8+40]
	base::internal::Invoker<base::internal::BindState<void (__thiscall
IPC::ChannelProxy::Context::*)(void),scoped_refptr<IPC::ChannelProxy::Context>
>,void __cdecl(void)>::RunImpl<void (__thiscall
IPC::ChannelProxy::Context::*const &)(void),std::tuple<scoped [0x0B1504A4+52]
	base::internal::Invoker<base::internal::BindState<void (__thiscall
IPC::ChannelProxy::Context::*)(void),scoped_refptr<IPC::ChannelProxy::Context>
>,void __cdecl(void)>::Run [0x0B156904+36]
	base::Callback<void __cdecl(void),0,0>::Run [0x10049A45+53]
	base::debug::TaskAnnotator::RunTask [0x100B444C+476]
	base::MessageLoop::RunTask [0x1012F94C+620]
	base::MessageLoop::DeferOrRunPendingTask [0x1012DE4B+43]
	base::MessageLoop::DoWork [0x1012E44F+239]
	base::MessagePumpForIO::DoRunLoop [0x10136211+33]
	base::MessagePumpWin::Run [0x101372FB+123]
	base::MessageLoop::RunHandler [0x1012F5C5+293]
	base::RunLoop::Run [0x101EDB26+166]
	base::Thread::Run [0x10289D01+273]
	base::Thread::ThreadMain [0x1028AE4F+863]
	base::PlatformThread::Sleep [0x102659EC+380]
	BaseThreadInitThunk [0x76A9338A+18]
	RtlInitializeExceptionChain [0x77A39902+99]
	RtlInitializeExceptionChain [0x77A398D5+54]

Original issue's description:
> gpu: GPU service scheduler.
> 
> The GPU service scheduler runs tasks (closures) containing command
> buffer work. Tasks are enqueued in sequences which represent indepdent
> streams of execution. A task in one sequence may wait on a sync token
> fence that's released on another sequence. Tasks can specify their sync
> token fences beforehand so that the scheduler won't run a sequence only
> to disable it due to a sync token wait. Tasks can check if they should
> yield so that a higher priority task may run. If a task decides to
> yield, it can continue execution by supplying a new closure which will
> run before any other scheduled tasks in that sequence.
> 
> The scheduler maintains a priority queue of sequences ordered by
> sequence priority and then order number. Priority inversion because of
> sync token dependencies is handled by a simple priority ceiling scheme.
> Sequences which are expected to release sync tokens dependencies are
> assigned a priority (HIGH) that's higher than any client specified
> priorities. However, browser view context sequences can have an even
> higher priority (REAL_TIME).
> 
> GPU channel IPC messages are run as tasks in the scheduler. Each client
> side stream is mapped to a sequence. The client is expected to use a
> small number of streams to partition its command buffers so there is no
> tracking of stream lifetimes in the service. The message filter posts
> messages as tasks. AsyncFlush is the only message for which sync token
> dependencies are given to the scheduler.
> 
> The initial implementation uses the GPU main thread to run scheduled
> tasks. Future implementations, for example, could use a worker pool
> with task traits to specify which thread a task should run on.
> 
> R=piman@chromium.org
> BUG=514813
>
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
> 
> Review-Url: https://codereview.chromium.org/2814843002
> Cr-Commit-Position: refs/heads/master@{#471187}
> Committed:
https://chromium.googlesource.com/chromium/src/+/e7e36ccdaa3fcf63b330bc956eee...

TBR=piman@chromium.org,vmiura@chromium.org,dcheng@chromium.org,sadrul@chromiu...
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=514813

Review-Url: https://codereview.chromium.org/2881813002
Cr-Commit-Position: refs/heads/master@{#471335}
Committed:
https://chromium.googlesource.com/chromium/src/+/9d3cbf5bb0cca7fdcbfa22c63a18...
==========

[commit-bot: I haz the power, 2017-05-12 16:45:59]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/9d3cbf5bb0cca7fdcbfa22c63a18...

[sunnyps, 2017-05-12 17:28:38]

A revert of this CL (patchset #1 id:1) has been created in
https://codereview.chromium.org/2876913003/ by sunnyps@chromium.org.

The reason for reverting is: Reland.

[Justin Donnelly, 2017-05-12 20:19:42]

On 2017/05/12 17:28:38, sunnyps wrote:
> A revert of this CL (patchset #1 id:1) has been created in
> https://codereview.chromium.org/2876913003/ by mailto:sunnyps@chromium.org.
> 
> The reason for reverting is: Reland.

Why re-land this? Did you make some other change to address the issue? Or do you
believe that this is not related to the stack trace I listed?

[sunnyps, 2017-05-12 20:29:31]

On 2017/05/12 20:19:42, Justin Donnelly wrote:
> On 2017/05/12 17:28:38, sunnyps wrote:
> > A revert of this CL (patchset #1 id:1) has been created in
> > https://codereview.chromium.org/2876913003/ by mailto:sunnyps@chromium.org.
> > 
> > The reason for reverting is: Reland.
> 
> Why re-land this? Did you make some other change to address the issue? Or do
you
> believe that this is not related to the stack trace I listed?

I removed the dcheck and added a comment explaining why it was wrong. I edited
the description after creating the reland CL but the reason stated here is old.

[Justin Donnelly, 2017-05-12 20:33:22]

On 2017/05/12 20:29:31, sunnyps wrote:
> On 2017/05/12 20:19:42, Justin Donnelly wrote:
> > On 2017/05/12 17:28:38, sunnyps wrote:
> > > A revert of this CL (patchset #1 id:1) has been created in
> > > https://codereview.chromium.org/2876913003/ by
mailto:sunnyps@chromium.org.
> > > 
> > > The reason for reverting is: Reland.
> > 
> > Why re-land this? Did you make some other change to address the issue? Or do
> you
> > believe that this is not related to the stack trace I listed?
> 
> I removed the dcheck and added a comment explaining why it was wrong. I edited
> the description after creating the reland CL but the reason stated here is
old.

Ok, thanks.