Increase GPU v-sync worker thread priority to reduce v-sync latency

This applies only to code running under D3DVsync experiment.

My experiments show that increasing the GPU V-sync worker thread priority has 
a noticeable impact on latency on the GPU process side, even before the v-sync
signal is sent over IPC to the browser.

The tables below show the deltas (in us) between the adjusted DWM v-blank timestamp
and the now() time when on the thread wakeup on v-blank.
This was tested on a consumer grade DELL XPS laptop with 4 cores.

With the current DISPLAY priority the distribution looks like this:
< 0       9.8%
0-99      78.7%
100-199   4.8%
200-499   1.7%
500-999   2.2%
1000-1999 1.4%
2000-4999 1.0%
5000-9999 0.4%
10000+    <0.1%

With the higher REALTIME_AUDIO priority the distribution looks much improved
with a much steeper drop after 200 us:
< 0       8.6%
0-99      82.4%
100-199   8.5%
200-499   0.2%
500-999   0.2%
1000-1999 <0.1%

Bug: 751340
Cq-Include-Trybots: 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
Change-Id: I082d4561e6b27fc23e2242a9023c19d6787492fd
Reviewed-on: https://chromium-review.googlesource.com/596625Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Commit-Queue: Stanislav Chiknavaryan <stanisc@chromium.org>
Cr-Commit-Position: refs/heads/master@{#491528}

gpu/ipc/service/gpu_vsync_provider_win.cc

@@ -153,7 +153,7 @@ class GpuVSyncWorker : public base::Thread,
 GpuVSyncWorker::GpuVSyncWorker(
     const gfx::VSyncProvider::UpdateVSyncCallback& callback,
     SurfaceHandle surface_handle)
-    : base::Thread(base::StringPrintf("VSync-%d", surface_handle)),
+    : base::Thread(base::StringPrintf("VSync-%p", surface_handle)),
       callback_(callback),
       surface_handle_(surface_handle) {
   HMODULE gdi32 = GetModuleHandle(L"gdi32");
@@ -558,8 +558,12 @@ GpuVSyncProviderWin::GpuVSyncProviderWin(
 
   // Start the thread.
   base::Thread::Options options;
-  // TODO(stanisc): might consider even higher priority - REALTIME_AUDIO.
-  options.priority = base::ThreadPriority::DISPLAY;
+  // Realtime priority is needed to ensure the minimal possible wakeup latency
+  // and to ensure that the thread isn't pre-empted when it handles the v-blank
+  // wake-up.  The thread sleeps most of the time and does a tiny amount of
+  // actual work on each cycle. So the increased priority is mostly for the best
+  // possible latency.
+  options.priority = base::ThreadPriority::REALTIME_AUDIO;
   vsync_worker_->StartWithOptions(options);
 }