src/libANGLE/ProgramPipeline.cpp


Log

Author Commit Date CI Message
Jamie Madill 7a0faa82 2020-09-24T20:15:26 Revert "Pass #pragma optimize setting down to compilation." This reverts commit 499173de1c91932ba272269cab6918bf7e8d7c11. Reason for revert: Causes unexpected HLSL compiler errors in some cases. See bug. Bug: angleproject:5094 Original change's description: > Pass #pragma optimize setting down to compilation. > > This will allow us to disable optimizations in the back-end. This can > be useful both for developers and for ANGLE to disable very slow > shader compilation on D3D11. > > Also apply this pragma to VerifyMaxVertexUniformVectorsWithSamplers. > Reduces compilation time by half in local testing. > > Bug: angleproject:5076 > Change-Id: I64ad576e11b9cee5b41f8af0d3621570304d65c2 > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2420749 > Commit-Queue: Jamie Madill <jmadill@chromium.org> > Reviewed-by: Jonah Ryan-Davis <jonahr@google.com> > Reviewed-by: Geoff Lang <geofflang@chromium.org> TBR=geofflang@chromium.org,jonahr@google.com,jmadill@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: angleproject:5076 Change-Id: I733e788fe8e9421ae0af662c0eb51af1ed79dde3 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2429517 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Jamie Madill 499173de 2020-09-20T10:42:56 Pass #pragma optimize setting down to compilation. This will allow us to disable optimizations in the back-end. This can be useful both for developers and for ANGLE to disable very slow shader compilation on D3D11. Also apply this pragma to VerifyMaxVertexUniformVectorsWithSamplers. Reduces compilation time by half in local testing. Bug: angleproject:5076 Change-Id: I64ad576e11b9cee5b41f8af0d3621570304d65c2 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2420749 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Jonah Ryan-Davis <jonahr@google.com> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Courtney Goeltzenleuchter c5b5cf6c 2020-09-10T16:58:18 Refactor to pass ProgramMergedVaryings to link impl Follow-on CL needs the ProgramMergedVaryings in the Vulkan backend to generate valid SPIRV. Bug: angleproject:3078 Change-Id: Ic442a3e0bd713fec36bd6b9420f67f3b1118e5ad Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2404336 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Courtney Goeltzenleuchter <courtneygo@google.com>
Tim Van Patten b3545b42 2020-07-29T16:50:53 Get storage buffers/images from ProgramExecutable Update StateCache::updateActiveShaderStorageBufferIndices() and StateCache::updateActiveImageUnitIndices to get the storage buffers and image bindings from the ProgramExecutable, respectively. This requires updating the ProgramPipeline's ProgramExecutable to build up its vector of buffers/images from each Program's ProgramExecutable. Bug: angleproject:4869 Test: VertexAttributeTestES31.UsePpoComputeShaderToUpdateVertexBuffer Test: SimpleStateChangeTestES31.InvalidateThenStorageWriteThenBlendPpo Change-Id: I68b7d23eedda910c3dcbf5f9c50b74b5e80134d8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2327701 Commit-Queue: Tim Van Patten <timvp@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Tim Van Patten 80d7725d 2020-07-15T15:14:17 Use Subject/Observer pattern for Programs/Executables in PPOs This CL updates the frontend to use the subject/observer pattern for Programs and ProgramExecutables in PPOs. This allows us to remove the hack that iterated through all PPOs and marking them all dirty when a Program is re-linked. Instead, just the PPOs the Program is bound to are signalled, and only when the Program is in a PPO. Additionally the necessary PPOs are signalled when an Executable's textures are updated, rather than iterating through all PPOs and signalling them. Bug: angleproject:4559 Test: CQ Change-Id: Iaefb88c64c13259e921c8dfe95cf640247d17f85 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2300705 Commit-Queue: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Tim Van Patten e0a2bd5e 2020-07-15T18:07:45 Remove ProgramPipelineState::mHasBeenBound The member ProgramPipelineState::mHasBeenBound is unused and should be removed. Bug: angleproject:3570 Test: CQ Change-Id: Idc41574f79e665ac36bef5b206704c667c49dadb Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2301101 Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Tim Van Patten <timvp@google.com>
Tim Van Patten 289365fa 2020-06-12T17:09:13 Remove ProgramExecutable::mProgram[Pipeline]State Remove the ProgramExecutable::mProgram[Pipeline]State pointers. Bug: angleproject:4520 Test: Build/CQ Change-Id: I1717e291ff9beec226bd2888e990b27d8078797c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2243764 Commit-Queue: Tim Van Patten <timvp@google.com> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tim Van Patten ce29916b 2020-06-12T14:40:22 Remove mProgramState from ProgramExecutable::isCompute() ProgramExecutable::isCompute() is being updated to no longer use mProgramState or mProgramPipelineState, as part of the effort to remove those members from ProgramExecutable. Functionally, things are the same for PPOs, but Programs are being updated to use the boolean ProgramExecutable::mIsCompute rather than checking the linked shader stages to determine draw vs compute. Slightly unrelated, but this CL also removes the unused function ProgramPipeline::hasImages() which was missed in one of the earlier CLs in this relation chain. Bug: angleproject:4520 Test: Build/CQ Change-Id: Ief28021310d6d0b1be5b7608a59deb87b0cf591d Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2243326 Commit-Queue: Tim Van Patten <timvp@google.com> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tim Van Patten c5014259 2020-06-11T23:30:47 Move ProgramState::mImageBindings to ProgramExecutable The member ProgramState::mImageBindings is being moved to ProgramExecutable to allow ProgramExecutable::getImageBindings() to answer the query without relying on the Program[Pipeline]State. Bug: angleproject:4520 Test: Build/CQ Change-Id: Ia4934c8e57b5ba49b0a399dcad7c1b324c43385d Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2241750 Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Tim Van Patten <timvp@google.com>
Tim Van Patten c117e360 2020-06-05T15:48:36 Move ProgramState::mSamplerBindings to ProgramExecutable The member ProgramState::mSamplerBindings is being moved to ProgramExecutable to allow ProgramExecutable::getSamplerBindings() to answer the query without relying on the Program[Pipeline]State. Bug: angleproject:4520 Test: Build/CQ Change-Id: I0daa997424d6e2aa5172e0731da221db72063435 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2233363 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com> Commit-Queue: Tim Van Patten <timvp@google.com>
Tim Van Patten db3ef872 2020-05-28T20:04:06 Move ProgramState::mDefaultUniformRange to ProgramExecutable The member ProgramState::mDefaultUniformRange is being moved to ProgramExecutable to allow ProgramExecutable::hasDefaultUniforms() to answer the query without relying on the Program[Pipeline]State. Bug: angleproject:4520 Test: Build/CQ Change-Id: Ic0d78b7193a28962b7ab6480964f8920a23bb7be Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2220776 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com> Commit-Queue: Tim Van Patten <timvp@google.com>
Tim Van Patten 77851053 2020-05-26T18:14:56 Reduce dependency on ProgramExecutable::mProgram[Pipeline]State Remove the dependency on mProgramState/mProgramPipelineState for the following functions in ProgramExecutable: hasUniformBuffers() hasStorageBuffers() hasAtomicCounterBuffers() hasTransformFeedbackOutput() getTransformFeedbackBufferCount() The data structures those function were querying were recently moved into the ProgramExecutable, so the call stack was: ProgramExecutable -> ProgramState -> ProgramExecutable This change updates the functions to return the results immediately. Remaining functions to be cleaned up in later CLs: hasDefaultUniforms() hasTextures() hasImages() Bug: angleproject:4520 Test: Build/CQ Change-Id: Ieaa041ff128e389f322745d55f688d4b07a5a23d Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2216764 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Tim Van Patten <timvp@google.com>
Tim Van Patten d34ab323 2020-05-04T10:48:48 Vulkan: Save linked ProgramExecutable data PPOs need to support drawing with Programs that failed their last linkProgram() if they had previously successfully linked. This requires saving the ProgramExecutable when linkProgram() succeeds, and not overwriting it with subsequent linkProgram() calls unil the next successful one. To achieve this, the new member ProgramState::mLinkedExecutable will point to the last successfully linked ProgramExecutable and ProgramState::mExecutable will point to a new ProgramExecutable when the next linkProgram() is attempted. If the link fails, the newly allocated ProgramExecutable will be delete()'ed and mExecutable will point to the previous 'good' ProgramExecutable still being tracked by mLinkedExecutable. If it succeeds, the old mLinkedExecutable will be delete()'ed and mLinkedExecutable will be updated to point to the ne one. Bug: angleproject:4514 Test: KHR-GLES31.core.sepshaderobjs.StateInteraction Change-Id: I0677602a6d652a055404667ec9e9305fed5b4177 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2181450 Commit-Queue: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tim Van Patten 24268826 2020-05-04T10:48:48 Vulkan: Pass Input/Output Varying lists during linking When linking program varyings, the necessary functions need the following: - Lists of Input and Output varyings - Shader versions - Shader types Rather than the full Shader itself, just this information will be passed around to the functions. This allows us to limit how much data is saved for each Program when linkProgram() succeeds, so PPos can link the attached Programs at draw time. Bug: angleproject:4514 Test: CQ Change-Id: I27b639cae9a153d0d3f5efab3b38550f09f4f49b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2181449 Commit-Queue: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tim Van Patten fecd1afc 2020-05-04T10:24:57 Vulkan: Move necessary members from ProgramState to ProgramExecutable ProgramPipeline's need to be able to link Programs before drawing, even if the Program's previous linkProgram() failed. To work towards this, some ProgramState members are being moved to ProgramExecutable so they can be saved when linkProgram() succeeds and not overwritten by any subsequent linkProgram() attempts that may fail. This also allows the second half of this change, which is to pass in the Program's ProgramExecutable to GlslangAssignLocations() and GlslangWrapperVk::TransformSpirV() so the values saved from the last successful linkProgram() are used. Bug: angleproject:4514 Test: CQ Change-Id: I68aa429be76c0c6e1b886be09a12200217fcc7ab Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2181448 Commit-Queue: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tim Van Patten 39d187b8 2020-04-23T19:30:12 Update Program[Pipeline]State to hold a ProgramExecutable Pointer This is a refactor CL to convert mExecutable in ProgramState and ProgramPipelineState to a pointer, so it can be changed to point to a different ProgramExecutable in a future CL. Bug: angleproject:4514 Test: end2end Change-Id: Id8ee9e5f2d1b02313973519cb2b4b0d5f7533b09 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2181447 Commit-Queue: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tim Van Patten 12b6a82e 2020-04-03T18:31:22 No-Op draws when no active VS and/or FS is present Re-land CL with WebGL fixes: This required some extra pointer checking during validation to handle the fact that a Program and/or ProgramExecutable may not be present when attempting to draw. This isn't an error, just undefined behavior, which we (eventually) treat as a no-op. According to the OpenGL ES 3.1 spec: 7.3. PROGRAM OBJECTS If there is no active program for the vertex or fragment shader stages, the results of vertex and fragment shader execution will respectively be undefined. However, this is not an error. To handle this, if no VS or FS is present in the active Program/PPO, we will no-op the draw command. Bug: angleproject:3570 Test: KHR-GLES31.core.sepshaderobjs.StateInteraction Change-Id: I70d688bf344a78cf3b4fd66c995ae03ce4b9b807 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2185156 Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Tim Van Patten <timvp@google.com>
Courtney Goeltzenleuchter 1ab55d96 2020-05-06T14:45:18 Revert "No-Op draws when no active VS and/or FS is present" This reverts commit a4b506f79e3286ffcf3a5d68f20aa97a63edab8e. Reason for revert: WebGL crash https://bugs.chromium.org/p/angleproject/issues/detail?id=4616 Original change's description: > No-Op draws when no active VS and/or FS is present > > According to the OpenGL ES 3.1 spec: > > 7.3. PROGRAM OBJECTS > If there is no active program for the vertex or fragment shader > stages, the results of vertex and fragment shader execution will > respectively be undefined. However, this is not an error. > > To handle this, if no VS or FS is present in the active Program/PPO, > we will no-op the draw command. > > Bug: angleproject:3570 > Test: KHR-GLES31.core.sepshaderobjs.StateInteraction > Change-Id: If19e9fbb1bc09fa0d490832079bb9f514eab6035 > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2136386 > Reviewed-by: Jamie Madill <jmadill@chromium.org> > Commit-Queue: Tim Van Patten <timvp@google.com> TBR=timvp@google.com,jmadill@chromium.org,cclao@google.com Change-Id: Ia24c4156ff7779b69c1f3f705f1a91cbb1c9684c No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: angleproject:3570 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2184849 Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com> Commit-Queue: Courtney Goeltzenleuchter <courtneygo@google.com>
Tim Van Patten a4b506f7 2020-04-03T18:31:22 No-Op draws when no active VS and/or FS is present According to the OpenGL ES 3.1 spec: 7.3. PROGRAM OBJECTS If there is no active program for the vertex or fragment shader stages, the results of vertex and fragment shader execution will respectively be undefined. However, this is not an error. To handle this, if no VS or FS is present in the active Program/PPO, we will no-op the draw command. Bug: angleproject:3570 Test: KHR-GLES31.core.sepshaderobjs.StateInteraction Change-Id: If19e9fbb1bc09fa0d490832079bb9f514eab6035 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2136386 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Tim Van Patten <timvp@google.com>
Tim Van Patten 913f4f42 2020-04-15T00:54:37 Vulkan: Support VS, FS, and CS in the same PPO This CL adds support for a Program Pipeline Object to have a VS, FS, and CS attached to the same PPO and then using that PPO for both draw and dispatch calls. Bug: angleproject:3570 Test: KHR-GLES31.core.compute_shader.sso* Change-Id: I262cdbdfd442f6db5ba2b45d1308003102b237cb Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2150078 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com> Commit-Queue: Tim Van Patten <timvp@google.com>
Tim Van Patten 405f8e7b 2020-02-24T17:38:10 Vulkan: Support Program Pipeline Objects Add support for PPOs to the Vulkan back end. Bug: angleproject:3570 Change-Id: I5403456929847c185467b008d810f31ecfcb60cc Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2072652 Commit-Queue: Tim Van Patten <timvp@google.com> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Tim Van Patten 68083e89 2020-03-04T15:55:53 Vulkan: Move cached samplers/images and has*() to ProgramExecutable The active samplers and images are being moved from Program into ProgramExecutable to unify interacting with them for Programs and ProgramPipelines Also, create some helper functions for gl::Program that ProgramExecutable can call to make it easier for ProgramPipeline to respond to similar queries for each of the Programs in the ProgramPipeline. Bug: angleproject:3570 Change-Id: I0b37f1a379e56b9659d82d92f6d7a546beee11cd Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2087648 Commit-Queue: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Jamie Madill c431d596 2019-12-16T10:59:44 Add Serial to all GL resources. The Serial will help track active resources for filtering out inactive setup calls in capture/replay. Bug: angleproject:4223 Change-Id: I64ba50f27d656c12d45155dc735e9b6f9c04528f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1969062 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Cody Northrop <cnorthrop@google.com> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Jamie Madill f703443b 2019-09-21T14:10:35 Use Resource IDs in RefCountObject. This lets us use strongly typed IDs pretty much everywhere. Only one or two additional places still use GLuint IDs. Mostly for external queries and for Framebuffer Attachments. With some clever type reflection helpers lets us define a single template function for handling operator== and != for resource IDs. Refactor in preparation for more Capture/Replay work. Bug: angleproject:3611 Change-Id: I1c0c848e89eb8a4b769714d57686f816daf01634 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1815550 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tobin Ehlis <tobine@google.com>
Jiacheng Lu 378c1881 2019-08-22T16:55:39 Use ProgramPipelineID in place of GLuint handle Bug: angleproject:3804 Change-Id: Ice37a4b3d43008e5bcd5d0a7528514d5bb504066 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1767322 Reviewed-by: Jiacheng Lu <lujc@google.com> Commit-Queue: Jiacheng Lu <lujc@google.com>
Stuart Morgan 9d737966 2019-08-14T12:25:12 Standardize copyright notices to project style For all "ANGLE Project" copyrights, standardize to the format specified by the style guide. Changes: - "Copyright (c)" and "Copyright(c)" changed to just "Copyright". - Removed the second half of date ranges ("Y1Y1-Y2Y2"->"Y1Y1"). - Fixed a small number of files that had no copyright date using the initial commit year from the version control history. - Fixed one instance of copyright being "The ANGLE Project" rather than "The ANGLE Project Authors" These changes are applied both to the copyright of source file, and where applicable to copyright statements that are generated by templates. BUG=angleproject:3811 Change-Id: I973dd65e4ef9deeba232d5be74c768256a0eb2e5 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1754397 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Jamie Madill e90d4ee9 2018-11-28T14:04:00 Pass Context to setLabel. This is useful for triggering a dirty state notification for Textures. It will lead to improvements for program and texture dirty bits. Bug: angleproject:2966 Change-Id: Iaba625da8a970a558f7d158bfa2f09c964f6761a Reviewed-on: https://chromium-review.googlesource.com/c/1347669 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Jamie Madill b980c563 2018-11-27T11:34:27 Reformat all cpp and h files. This applies git cl format --full to all ANGLE sources. Bug: angleproject:2986 Change-Id: Ib504e618c1589332a37e97696cdc3515d739308f Reviewed-on: https://chromium-review.googlesource.com/c/1351367 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Jamie Madill 1c7f08c3 2018-10-10T16:13:02 Inline RefCountObject::release. Also don't return errors from the object release methods. Not returning errors reduces the amount of code generated. Also we shouldn't be exiting early from destructor type functions. Increases object binding performance. Bug: angleproject:2877 Change-Id: Ieb8120d885b946915e355419825e1f52f31d7b49 Reviewed-on: https://chromium-review.googlesource.com/c/1270218 Reviewed-by: Geoff Lang <geofflang@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Jamie Madill acf2f3ad 2017-11-21T19:22:44 Apply Chromium style fixes. This addresses several minor code quality issues that are validated in Chromium, but not yet applied to ANGLE: * constructors and destructors must be defined out-of-line * auto is not allowed for simple pointer types * use override everywhere instead of virtual * virtual functions must also be defined out-of-line Slightly reduces binary size for me (~2k on Win, 150k on Linux). Bug: angleproject:1569 Change-Id: I073ca3365188caf5f29fb28d9eb207903c1843e6 Reviewed-on: https://chromium-review.googlesource.com/779959 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Yunchao He a336b90f 2017-08-02T16:05:21 ES31: Impl program pipeline object management entries for GL backend. The program pipeline object management entries are: GenProgramPipelines DeleteProgramPipelines BindProgramPipeline IsProgramPipeline BUG:angleproject:2123 Change-Id: I114d054b90caf2ee3f9befef7439552a1c309bc4 Reviewed-on: https://chromium-review.googlesource.com/629978 Commit-Queue: Corentin Wallez <cwallez@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org>