summaryrefslogtreecommitdiffstats
path: root/chrome/gpu/gpu_thread.h
Commit message (Collapse)AuthorAgeFilesLines
* Blacklist bad GPU drivers: currenly we disable all gpu related features if a ↵zmo@google.com2010-12-111-0/+5
| | | | | | | | | | | (os, device, driver) configuration is on the blacklist. BUG=58182 TEST=unittest Review URL: http://codereview.chromium.org/5612002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68948 0039d316-1c4b-4281-b951-d872f2087c98
* Add flow control between renderer and GPU processes, and, on Mac OS X,kbr@google.com2010-11-261-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | between GPU process and browser process. Thanks to Al Patrick for the renderer<->GPU flow control mechanism. This CL prevents the renderer from issuing more OpenGL work than the GPU process can execute, and, on the Mac, prevents the combination of the renderer and GPU processes from transmitting more frames via IOSurfaces from the GPU to the browser process than can be handled by the GPU. This fix causes the renderer to block inside ggl::SwapBuffers() when it gets too far ahead. Different strategies can be considered going forward, including measuring frame rates in the GPU and renderer processes and trying to match them via techniques such as delaying the execution of some timers. However, despite the general undesirability of blocking the render thread, this fix results in a significant performance improvement. With this fix integrated, a fill-limited test case from Chris Rogers displays at 60 FPS instead of 15 FPS on a Mac Pro. Gregg Tavares' aquarium from webglsamples.googlecode.com displays at 30 FPS instead of 4 or 5 FPS on a MacBook Pro. The frame rates measured at the JavaScript level now match the actual frame rate of the browser, where previously they were much higher since they were issuing more work than the browser could render. A few other minor OpenGL bugs potentially impacting the correctness of the Mac compositor are being fixed as well in this CL. Verified that WebGL, CSS 3D and YouTube (Core Animation plugin) content all work. BUG=63539 TEST=none Review URL: http://codereview.chromium.org/5317007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67470 0039d316-1c4b-4281-b951-d872f2087c98
* Collect DirectX diagnostic information asynchronously.apatrick@chromium.org2010-11-151-0/+5
| | | | | | | | | | | | | Collecting this can take a couple of seconds. I put the code onto a worker thread. The about:gpuinfo handler polls for it until it is available, initially displaying only the subset of informtation that can be retreived quickly. This makes the startup time for accelerated compositing, WebGL, etc significantly lower on Windows. None of the other platforms have this issue. TEST=go to about:gpuinfo, try BUG=59711 Review URL: http://codereview.chromium.org/4860001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66184 0039d316-1c4b-4281-b951-d872f2087c98
* - Relanding 61718.apatrick@chromium.org2010-11-091-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I disabled the GPU watchdog in three new cases: - If the OSMesa software renderer is in use. This will disable it on bots. - When running on valgrind, whether on a bot or locally. - In debug builds I added a GPU process initialization time to the GPU info. I moved the GPU initialization code outside the watchdog protection because it can take a long time and trigger the watchdog. I increased the timeout. I set up a field trial with different timeouts to see the rate of failure for each period. Original CL description: I added a watchdog thread that intermitently checks the main thread can respond to tasks posted on its message queue. I fixed some bugs that prevented GGL from failing when the GPU channel was lost. Added a command line swith to disable the watchdog thread for debugging purposes. TEST=try, local testing of all features BUG=none git-svn-id: svn://svn.chromium.org/chrome/trunk/src@65461 0039d316-1c4b-4281-b951-d872f2087c98
* Deleted code associated with --enable-gpu-rendering andkbr@chromium.org2010-11-081-18/+0
| | | | | | | | | | | | | | | | | | | | --enable-video-layering flags. With the introduction of accelerated compositing to Chromium this code is now obsolete, and it is causing problems and bug reports when users experiment with these flags. Tested on Linux in the following configurations: - Compositor on, CSS 3D content - Compositor on, HTML5 video content - Compositor off, HTML5 video content Also ran patch successfully through the try bots. BUG=54932 TEST=none Review URL: http://codereview.chromium.org/4399003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@65383 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 63388 - ↵stoyan@chromium.org2010-10-211-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | http://build.chromium.org/buildbot/waterfall/builders/Mac10.6%20Tests%20(dbg)(2)/builds/10949 - Relanding 61718. I disabled the GPU watchdog in three new cases: - If the OSMesa software renderer is in use. This will disable it on bots. - When running on valgrind, whether on a bot or locally. - In debug builds I added a GPU process initialization time to the GPU info. I moved the GPU initialization code outside the watchdog protection because it can take a long time and trigger the watchdog. I increased the timeout. I set up a field trial with different timeouts to see the rate of failure for each period. I made ui_tests always run with OSMesa, for consistent operation on bots and when run locally. Original CL description: I added a watchdog thread that intermitently checks the main thread can respond to tasks posted on its message queue. I fixed some bugs that preventede GGL from failing when the GPU channel was lost. Added a command line swith to disable the watchdog thread for debugging purposes. TEST=try, local testing of all features BUG=none Review URL: http://codereview.chromium.org/3794011 TBR=apatrick@chromium.org Review URL: http://codereview.chromium.org/3979004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@63396 0039d316-1c4b-4281-b951-d872f2087c98
* Relanding 61718.apatrick@chromium.org2010-10-211-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I disabled the GPU watchdog in three new cases: - If the OSMesa software renderer is in use. This will disable it on bots. - When running on valgrind, whether on a bot or locally. - In debug builds I added a GPU process initialization time to the GPU info. I moved the GPU initialization code outside the watchdog protection because it can take a long time and trigger the watchdog. I increased the timeout. I set up a field trial with different timeouts to see the rate of failure for each period. I made ui_tests always run with OSMesa, for consistent operation on bots and when run locally. Original CL description: I added a watchdog thread that intermitently checks the main thread can respond to tasks posted on its message queue. I fixed some bugs that preventede GGL from failing when the GPU channel was lost. Added a command line swith to disable the watchdog thread for debugging purposes. TEST=try, local testing of all features BUG=none Review URL: http://codereview.chromium.org/3794011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@63388 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 60421 - Revert 60373, trying to track down a perf regression (see bug ↵thakis@chromium.org2010-09-241-0/+1
| | | | | | | | | | | | | | | | | 56752)- Add about:gpuhang BUG=None TEST=None Review URL: http://codereview.chromium.org/3447023 TBR=thakis@chromium.org Review URL: http://codereview.chromium.org/3398027 TBR=thakis@chromium.org Review URL: http://codereview.chromium.org/3398028 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@60430 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 60373, trying to track down a perf regression (see bug 56752)- Add ↵thakis@chromium.org2010-09-241-1/+0
| | | | | | | | | | | | | | about:gpuhang BUG=None TEST=None Review URL: http://codereview.chromium.org/3447023 TBR=thakis@chromium.org Review URL: http://codereview.chromium.org/3398027 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@60421 0039d316-1c4b-4281-b951-d872f2087c98
* Add about:gpuhangthakis@chromium.org2010-09-231-0/+1
| | | | | | | | | BUG=None TEST=None Review URL: http://codereview.chromium.org/3447023 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@60373 0039d316-1c4b-4281-b951-d872f2087c98
* Add about:gpucrashthakis@chromium.org2010-09-151-0/+1
| | | | | | | | | BUG=None TEST=open a tab that uses the compositor. Open a second tab, go to about:gpucrash. Verify in the task manager that the gpu process is now gone. Review URL: http://codereview.chromium.org/3424007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59540 0039d316-1c4b-4281-b951-d872f2087c98
* Updating the about:gpu to start a webgl context if one does not exist so ↵rlp@chromium.org2010-09-101-0/+1
| | | | | | | | | | | | | | | | | | that some gpu_info will actually exist. It does this by refreshing the page every 5 seconds until a context does exist, if necessary. We also looked into other methods: - synchronous call to create context, but that will hang if there are issues creating a context - a call back, but that will also hang until we have a gpu context - display no data and rely on the user to refresh which is somewhat unintuitive to the user The method in this CL seemed to be the least annoying method of doing this which didn't cause the browser to hang. BUG=none TEST=visual Review URL: http://codereview.chromium.org/3348007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59141 0039d316-1c4b-4281-b951-d872f2087c98
* `#pragma once` for app, base, chrome, gfx, ipc, net, skia, viewsthakis@chromium.org2010-07-261-0/+1
| | | | | | | | | BUG=50273 TEST=everything still builds, build is 10% faster on windows, same speed on mac/linux TBR: erg git-svn-id: svn://svn.chromium.org/chrome/trunk/src@53716 0039d316-1c4b-4281-b951-d872f2087c98
* GPU process command buffer stubs are destroyed when channel is closed.apatrick@chromium.org2010-07-151-0/+3
| | | | | | | | | | | | | | | | - This was didn't work by of a reference counting cycle. GPU process no longer automatically terminates when the last channel is closed. - The GPU process will be launched at renderer startup and keep running unless it crashes. Command buffer stubs no longer hold a strong reference to their parent. TEST=try BUG=none Review URL: http://codereview.chromium.org/2903006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@52531 0039d316-1c4b-4281-b951-d872f2087c98
* Split GpuProcessHost into GpuProcessHostUIShim, which runs on the UIkbr@google.com2010-03-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | thread, and GpuProcessHost, which now runs on the IO thread and derives from ChildProcessHost. This split was necessary in order to service synchronous messages from the renderer process. Moved message handlers for GPU messages from renderer to browser from BrowserRenderProcessHost to ResourceMessageFilter. Stopped sending multiple ViewHostMsg_EstablishGpuChannel messages from the same renderer if the connection was already established. Resetting the channel was causing failures in Send, and every other page reload containing WebGL content to fail. This cleanup will allow further simplification in the GPU process, but this is being left for a subsequent CL. Fixed bug in sandboxing of GPU process. Fixed latent bugs in cleanup code in GpuChannel and GpuChannelHost. Fixed crashes in ChildProcessHost if resource_dispatcher_host_ was NULL. Fixed apparent latent race conditions in creation of BackingStoreProxy and VideoLayerProxy. With these changes, WebGL content is running in the sandbox on both Mac and Windows. Linux support will be added in a following CL. BUG=29120 TEST=ran WebGL demos on Mac and Windows Review URL: http://codereview.chromium.org/1546001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@43029 0039d316-1c4b-4281-b951-d872f2087c98
* Added command buffer implementation of WebGL which runs in the sandbox.kbr@google.com2010-03-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | Added synchronous initialization of the channel to the GPU process, needed to obey WebGL startup semantics. There are problems with this on the Windows platform which will be addressed via refactoring in the GpuProcessHost in a subsequent CL. Implemented offscreen rendering code path in GGL / GLES2CmdDecoder for Mac OS X. This new code path is not yet complete for all platforms and is still being stress tested. The previous in-process WebGL implementation is currently used when the sandbox is disabled; it will be removed in a subsequent CL. A one-line code change in WebKit is needed after this CL lands to enable the new code path. BUG=29120 TEST=ran WebGL demos on command buffer implementation on Mac Review URL: http://codereview.chromium.org/1328001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42879 0039d316-1c4b-4281-b951-d872f2087c98
* Calling OpenGL from the renderer processapatrick@chromium.org2010-03-251-0/+4
| | | | | | | | | | | | | | - Added ability for renderer processes to render to a real window (Windows only so far). - Added ability to create offscreen frame buffer objects that can be resized later. - OpenGL context can have a "parent" context that can access its last swapped back buffer through a texture ID. - Moved code to establish GPU channel from RenderWidget to RenderThread. - Changed way service size command buffer object lifetimes are managed. TEST=trybot and visual verification that OpenGL can clear the browser window to magenta. BUG=none Review URL: http://codereview.chromium.org/1136006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42679 0039d316-1c4b-4281-b951-d872f2087c98
* Move some more files to toplevel gfx dir.ben@chromium.org2010-03-171-1/+1
| | | | | | | | | TBR=darin BUG=none TEST=none git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41812 0039d316-1c4b-4281-b951-d872f2087c98
* Added support for opening a GPU command buffer from a renderer processes ↵apatrick@chromium.org2010-03-051-0/+1
| | | | | | | | | | | | through a GPU channel. Probably only works in windows only so far. TEST=none BUG=none Review URL: http://codereview.chromium.org/657046 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@40783 0039d316-1c4b-4281-b951-d872f2087c98
* Fix the ARM build which can't find OpenGL. This adds a new define which I usebrettw@chromium.org2010-01-261-3/+4
| | | | | | | | | | | | to detect X and GL related build options. On ARM, this means we don't compile the accelerated backing store even though its Linux. BUG=none TEST=none Review URL: http://codereview.chromium.org/546144 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37091 0039d316-1c4b-4281-b951-d872f2087c98
* Create initial GPU backing store in the GPU process for X windows applications.brettw@chromium.org2010-01-261-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | This gets the window from the RenderWidgetHostViewGtk and just does OpenGL calls directly into it. There are a lot of bugs, especially around expose events, which aren't really processed at all, and also tab teardown and reparenting. The new backing store defaults to off. This does some refactoring of the existing Windows GPU process backing store implementation to make some of it sharable by this Linux verion. This removes some previously defunct in-process GL backing store code and moves it to the GPU process. This patch does some refactoring around how child processes are created using zygoes or not. I found there were many places where a command line would be checked with special logic to know whether to enable zygote code or not. I tried to unify this so it could be computed once for each process type. This is what most of the changed files in chrome/browser are related to. BUG=none TEST=none Review URL: http://codereview.chromium.org/548112 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37088 0039d316-1c4b-4281-b951-d872f2087c98
* Add the ability for the GPU process to be used to paint the backing store of abrettw@chromium.org2010-01-131-0/+28
tab. This is the first pass and is currently a bit buggy and incomplete. This patch refactors the backing store to make it a virtual interface which is then implemented by the platform-specific backing stores. This cleans up the multi-platform aspects of the old code, and also makes it possible to create different backing stores (such as ones in another process). This renames the BackingStore::PaintRect function to PaintToBackingStore which clears up what it does. I would often get confused and think that it paints the backing store to the screen. This makes a common way to capture backing store information and adds it to the backing store API. This removed a bunch of ugly ifdefs. This adds the ability for a backing store to specify that the TransportDIB should not be freed by RenderWidgetHost when painting is complete. This is necessary since the out-of-process version needs to use it after the RenderWidget paint function has returned. This pushes up the vector of copy_rect from RenderWidgetHost to the actual BackingStores. This prevents us from sending duplicate data over IPC. It also makes the common non-IPC case more efficient, since we end up setting up various surfaces only once when there are multiple update rects. BUG=none TEST=none Review URL: http://codereview.chromium.org/523028 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36075 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-19 02:52:00 +0000