|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|