command_buffer_gles2: Add test command_buffer_gles2_test for command_buffer_gles2

command_buffer_gles2: Add test command_buffer_gles2_test for command_buffer_gles2

Add test command_buffer_gles2_test for testing command_buffer_gles2
library.

Makes the gpu bots to build target, but the target is not run
on any bot.

As an example, fix a potential nullptr reference in eglInitialize
and tests the problem.

Adding the test runner would be useful in order to further develop
command_buffer_gles2. One development direction of the library
would be to extend it enough to support creating OpenGL ES 3.0
context.

BUG=581634
Committed: https://crrev.com/ee2d13a54fc1de09762f1e5be97d6db44235fa80
Cr-Commit-Position: refs/heads/master@{#374353}
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel

Committed: https://crrev.com/6aceb55a100ae0f821a83751ea73ab136cc746f9
Cr-Commit-Position: refs/heads/master@{#375420}

[Kimmo Kinnunen, 2016-01-27 13:26:30]

kkinnunen@nvidia.com changed reviewers:
+ piman@chromium.org, zmo@google.com

[Kimmo Kinnunen, 2016-01-27 16:01:20]

I think I need to fix this to not build on platforms that do not have
command_buffer_gles2. It'd be great to get feedback on whether this test
executable is wanted or not..

[Zhenyao Mo, 2016-01-27 17:34:55]

Description was changed from

==========
command_buffer_gles2: Add test command_buffer_gles2_test for
command_buffer_gles2

Add test command_buffer_gles2_test for testing command_buffer_gles2
library.

Makes the gpu bots to build target, but the target is not run
on any bot.

As an example, fix a potential nullptr reference in eglInitialize
and tests the problem.

Adding the test runner would be useful in order to further develop
command_buffer_gles2. One development direction of the library
would be to extend it enough to support creating OpenGL ES 3.0
context.

BUG=581634
==========

to

==========
command_buffer_gles2: Add test command_buffer_gles2_test for
command_buffer_gles2

Add test command_buffer_gles2_test for testing command_buffer_gles2
library.

Makes the gpu bots to build target, but the target is not run
on any bot.

As an example, fix a potential nullptr reference in eglInitialize
and tests the problem.

Adding the test runner would be useful in order to further develop
command_buffer_gles2. One development direction of the library
would be to extend it enough to support creating OpenGL ES 3.0
context.

BUG=581634
==========

[Zhenyao Mo, 2016-01-27 17:34:55]

zmo@chromium.org changed reviewers:
+ kbr@chromium.org

[Zhenyao Mo, 2016-01-27 17:38:33]

We do run it on GPU FYI bots. Code search for internal_gles2_conform_test. Since
gles2 conform suite is not open source, we could only run it internally.

[Ken Russell (switch to Gerrit), 2016-01-27 18:24:23]

kbr@chromium.org changed reviewers:
+ vmiura@chromium.org

[Ken Russell (switch to Gerrit), 2016-01-27 18:24:23]

Not sure of the status of the command_buffer_gles2 library. As zmo points out,
the GLES2 conformance tests are definitely run on top of the command buffer on
the chromium.gpu.fyi bots.

[vmiura, 2016-01-27 19:47:18]

It seems useful to set up a test harness for the command_buffer_gles2
library, though discussing with kbr@, gpu/gles2_conform_support may
not be the best location.

Perhaps gpu/command_buffer/tests?

[piman, 2016-01-27 23:19:15]

On 2016/01/27 19:47:18, vmiura wrote:
> It seems useful to set up a test harness for the command_buffer_gles2
> library, though discussing with kbr@, gpu/gles2_conform_support may
> not be the best location.
> 
> Perhaps gpu/command_buffer/tests?

Thanks for the test! Yes, gpu/command_buffer/tests seems appropriate.

@kbr: command_Buffer_gles2 is used to test skia+command buffers standalone
(upstream). It's good to have sanity unit tests here, I think. I don't think we
should try to have a separate run of conformance tests for this lib, it should
already be plenty covered by the regular conformance tests run.

[Kimmo Kinnunen, 2016-02-01 13:41:59]

kkinnunen@nvidia.com changed reviewers:
+ thakis@chromium.org

[Kimmo Kinnunen, 2016-02-01 13:42:00]

thakis@ for build/all.gyp, base/at_exit.cc

I would also need a bit of help with fixing the command_buffer_gles2 gn build:

1) command_buffer_gles2 should build a shared library in all configurations.
2) command_buffer_gles2_tests should link to command_buffer_gles2 dynamically.

This should happen regardless of whether is_component_build is on or not.
Currently it works for component build, but for non-component build
command_buffer_gles2_test does not encode the link settings correctly for GN
build:

GYP_DEFINES="" build/gyp_chromium && ninja -C out/Debug
command_buffer_gles2_tests
...

ldd out/Debug/command_buffer_gles2_tests
...
	libcommand_buffer_gles2.so =>
/store/kkinnunen/chrome/src/out/Debug/lib/libcommand_buffer_gles2.so
(0x00007f60ee621000)

--> Ok.

ninja -C out/gn-no-component command_buffer_gles2_tests
ldd out/gn-no-component/command_buffer_gles2_tests
...
	libcommand_buffer_gles2.so => not found

--> problem, rpath not set?

[Nico, 2016-02-01 19:15:37]

https://chromiumcodereview.appspot.com/1640243002/diff/80001/base/at_exit.cc
File base/at_exit.cc (right):

https://chromiumcodereview.appspot.com/1640243002/diff/80001/base/at_exit.cc#...
base/at_exit.cc:27: #if !defined(COMPONENT_BUILD) &&
!defined(COMMAND_BUFFER_GLES_LIB_SUPPORT_ONLY)
having base know about some gpu define seems wrong. why "command_buffer_gles2
should build a shared library in all configurations"?

[Ken Russell (switch to Gerrit), 2016-02-01 19:23:50]

Perhaps dpranke@ may be able to help with the gn non-component build issue?

[Dirk Pranke, 2016-02-01 19:43:46]

On 2016/02/01 19:23:50, Ken Russell wrote:
> Perhaps dpranke@ may be able to help with the gn non-component build issue?

I don't think I understand what the issue is? Are you asking about the issue
Nico is
raising in #13 (which I agree with; it can't be good to have to have base know
about some
gup define), or something else?

[Ken Russell (switch to Gerrit), 2016-02-01 19:52:45]

On 2016/02/01 19:43:46, Dirk Pranke wrote:
> On 2016/02/01 19:23:50, Ken Russell wrote:
> > Perhaps dpranke@ may be able to help with the gn non-component build issue?
> 
> I don't think I understand what the issue is? Are you asking about the issue
> Nico is
> raising in #13 (which I agree with; it can't be good to have to have base know
> about some
> gup define), or something else?

Asking about Kimmo's comment in #12 where he wants the command_buffer_gles2
target to build a shared library in all configurations.

I didn't look at the patch in detail but completely agree with Nico's comment
that base/ should not know about GPU-specific defines. Kimmo, I think you need
to figure out an alternative mechanism to prevent re-registration of the
AtExitManager.

[Nico, 2016-02-01 19:58:32]

re comment 12, you need something like
https://code.google.com/p/chromium/codesearch#chromium/src/base/BUILD.gn&l=1844

    if (!is_component_build) {
      # Set rpath to find libmalloc_wrapper.so even in a non-component build.
      configs += [ "//build/config/gcc:rpath_for_built_shared_libraries" ]
    }

…but why should that target always be a shared library, even in non-component
builds?

[piman, 2016-02-01 21:14:31]

On Mon, Feb 1, 2016 at 11:58 AM, <thakis@chromium.org> wrote:

> re comment 12, you need something
likehttps://code.google.com/p/chromium/codesearch#chromium/src/base/BUILD.gn&l=1844
>
>     if (!is_component_build) {
>       # Set rpath to find libmalloc_wrapper.so even in a non-component build.
>       configs += [ "//build/config/gcc:rpath_for_built_shared_libraries" ]
>     }
>
> …but why should that target always be a shared library, even in non-component
> builds?
>
>
It's used outside of Chrome, for upstream skia testing, and is meant to be
a drop-in replacement of libGL.so. It's not used in production.

> https://chromiumcodereview.appspot.com/1640243002/
>
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Kimmo Kinnunen, 2016-02-02 08:49:13]

Thanks for the comments.
PTAL when you have time.
thakis@ for build/all.gyp
Command buffer interested persons: gpu/*

There's also command_buffer_gles2 -related dependency:
https://chromiumcodereview.appspot.com/1656223003#ps1

[piman, 2016-02-02 16:47:48]

https://chromiumcodereview.appspot.com/1640243002/diff/100001/gpu/gles2_confo...
File gpu/gles2_conform_support/egl/test_support.h (right):

https://chromiumcodereview.appspot.com/1640243002/diff/100001/gpu/gles2_confo...
gpu/gles2_conform_support/egl/test_support.h:12: bool
g_command_buffer_gles2_has_atexit_manager;
I think this needs to be in a .cc file, and exported as extern in a .h, to avoid
multiple definitions.  Or am I missing some subtle thing?

[piman, 2016-02-02 16:47:48]

https://chromiumcodereview.appspot.com/1640243002/diff/100001/gpu/gles2_confo...
File gpu/gles2_conform_support/egl/test_support.h (right):

https://chromiumcodereview.appspot.com/1640243002/diff/100001/gpu/gles2_confo...
gpu/gles2_conform_support/egl/test_support.h:12: bool
g_command_buffer_gles2_has_atexit_manager;
I think this needs to be in a .cc file, and exported as extern in a .h, to avoid
multiple definitions.  Or am I missing some subtle thing?

[Kimmo Kinnunen, 2016-02-03 10:14:43]

On 2016/02/02 16:47:48, piman wrote:
>
https://chromiumcodereview.appspot.com/1640243002/diff/100001/gpu/gles2_confo...
> File gpu/gles2_conform_support/egl/test_support.h (right):
> 
>
https://chromiumcodereview.appspot.com/1640243002/diff/100001/gpu/gles2_confo...
> gpu/gles2_conform_support/egl/test_support.h:12: bool
> g_command_buffer_gles2_has_atexit_manager;
> I think this needs to be in a .cc file, and exported as extern in a .h, to
avoid
> multiple definitions.  Or am I missing some subtle thing?

Yeah, if I understand correctly, there's a subtle difference, if you mean adding
the .cc file to the command_buffer_gles2 library.
However, I'm not sure I can explain it correctly, so probably relying on it is
not good.
PTAL the new, unfortunately more complex version which introduces yet-another
library.

Wrt the difference:
With plain extern and adding the .cc file to the library, the variable becomes
part of the dynamic library interface, business as usual.
So it appears it is never actually aliased.
Reiterating the problem: globals declared in dependee components (say atexit in
base) will sometimes be aliased, sometimes not. We want to detect this aliasing.

My hypothesis with the other option, though I'm no compiler nor linker
enthusiast:
When declared without extern, each compilation unit gets its own variable
reference. The linker will reduce these references to one global variable per
"compilation target" (executable or dynamic library).

If I understand correctly the pattern was not in violation of ODR, as explained
here in section "Not so good way to define global variables":
http://stackoverflow.com/questions/1433204/how-do-i-use-extern-to-share-varia...

Personally I find all this a bit redundant compared to the usefulness of the
ASSERT it tries to circumvent..

[piman, 2016-02-04 02:42:23]

Ok, I think I understand the issue.
There's a fundamental ODR violation if both the test executable and the
command_buffer_gles2 lib statically link base (i.e. in the !component build).

If there was no ODR violation (e.g. in the component build), there would be only
one AtExitManager global. The behavior we would want is:
1- if the library is used as a drop-in replacement for libGL, it should take
care of setting up and tearing down the AtExitManager
2- if the library is being tested, it should inherit the AtExitManager from the
test executable

Differentiating between the cases is done through the
g_command_buffer_gles_has_atexit_manager bool.


And so, for the !component build, the assumption is that there's an ODR
violation, but we "understand and accept" it, although we need to adapt the
behavior because in case (2), the inheritance won't happen. The solution in this
patch is to make this extra library (command_buffer_gles2_test_support) to cause
another ODR violation, that would behave the same way as base/ wrt duplicate
globals.


It probably works but is not very satisfying. First, ODR violations are not
great to start with. Second, it means the unit test uses a library in a
different configuration than in "production" (where production is really another
set of tests, but that's irrelevant). Third, when inheriting the AtExitManager
from outside the library, it really means we're registering library functions
(destructors) to be called after the program is supposed to be done with the
library. If it was dynamically loaded/unloaded, we would possibly call functions
after the library is unmapped, causing crashes.


Taking a step back the root cause of the issue is that we rely on AtExitManager
(and in truth, other globals, like CommandLine) in gpu code. This will always
cause trouble when trying to use gpu as a shared library. Ideally, we could
remove that dependency. I think it mainly comes from non-Leaky LazyInstance,
there's not that many, and they could be explicitly created/destroyed and/or
injected. This is already the case for some globals (e.g. the global
SyncPointManager is created in GpuMain and injected in lower layers). This is a
fair amount of work, but a better end state I think. Another option is to
somehow make the AtExitManager dependency a property of the LazyInstance Traits,
so that we could use a different Traits in GPU code, that relies on explicit
construction/destruction instead of AtExitManager.


Short of that, my suggestion is to avoid creating more ODRs (and more
libraries), and instead encoding the link-time behavior at compile-time. If you
move g_command_buffer_gles_has_atexit_manager into the command_buffer_gles2
library, but instead ignore its value if COMPONENT_BUILD is not defined. That
should take care of the short term issues?

[Kimmo Kinnunen, 2016-02-05 14:35:28]

On 2016/02/04 02:42:23, piman wrote:
> Short of that, my suggestion is to avoid creating more ODRs (and more
> libraries), and instead encoding the link-time behavior at compile-time. If
you
> move g_command_buffer_gles_has_atexit_manager into the command_buffer_gles2
> library, but instead ignore its value if COMPONENT_BUILD is not defined. That
> should take care of the short term issues?

That is a very much better solution. Updated.

[piman, 2016-02-05 22:33:37]

lgtm

[Kimmo Kinnunen, 2016-02-06 07:23:41]

The CQ bit was checked by kkinnunen@nvidia.com to run a CQ dry run

[commit-bot: I haz the power, 2016-02-06 07:24:00]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1640243002/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1640243002/140001

[commit-bot: I haz the power, 2016-02-06 09:12:22]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-06 09:12:23]

Dry run: This issue passed the CQ dry run.

[Kimmo Kinnunen, 2016-02-08 12:48:39]

Nico, PTAL build/all.gyp changes.

[Nico, 2016-02-09 03:14:42]

build/all lgtm (sorry, I thought you don't need me since this no longer touches
base/)

[Kimmo Kinnunen, 2016-02-09 09:16:25]

The CQ bit was checked by kkinnunen@nvidia.com

[commit-bot: I haz the power, 2016-02-09 09:17:43]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1640243002/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1640243002/140001

[commit-bot: I haz the power, 2016-02-09 12:04:38]

Description was changed from

==========
command_buffer_gles2: Add test command_buffer_gles2_test for
command_buffer_gles2

Add test command_buffer_gles2_test for testing command_buffer_gles2
library.

Makes the gpu bots to build target, but the target is not run
on any bot.

As an example, fix a potential nullptr reference in eglInitialize
and tests the problem.

Adding the test runner would be useful in order to further develop
command_buffer_gles2. One development direction of the library
would be to extend it enough to support creating OpenGL ES 3.0
context.

BUG=581634
==========

to

==========
command_buffer_gles2: Add test command_buffer_gles2_test for
command_buffer_gles2

Add test command_buffer_gles2_test for testing command_buffer_gles2
library.

Makes the gpu bots to build target, but the target is not run
on any bot.

As an example, fix a potential nullptr reference in eglInitialize
and tests the problem.

Adding the test runner would be useful in order to further develop
command_buffer_gles2. One development direction of the library
would be to extend it enough to support creating OpenGL ES 3.0
context.

BUG=581634
==========

[commit-bot: I haz the power, 2016-02-09 12:04:39]

Committed patchset #8 (id:140001)

[commit-bot: I haz the power, 2016-02-09 12:05:56]

Description was changed from

==========
command_buffer_gles2: Add test command_buffer_gles2_test for
command_buffer_gles2

Add test command_buffer_gles2_test for testing command_buffer_gles2
library.

Makes the gpu bots to build target, but the target is not run
on any bot.

As an example, fix a potential nullptr reference in eglInitialize
and tests the problem.

Adding the test runner would be useful in order to further develop
command_buffer_gles2. One development direction of the library
would be to extend it enough to support creating OpenGL ES 3.0
context.

BUG=581634
==========

to

==========
command_buffer_gles2: Add test command_buffer_gles2_test for
command_buffer_gles2

Add test command_buffer_gles2_test for testing command_buffer_gles2
library.

Makes the gpu bots to build target, but the target is not run
on any bot.

As an example, fix a potential nullptr reference in eglInitialize
and tests the problem.

Adding the test runner would be useful in order to further develop
command_buffer_gles2. One development direction of the library
would be to extend it enough to support creating OpenGL ES 3.0
context.

BUG=581634

Committed: https://crrev.com/ee2d13a54fc1de09762f1e5be97d6db44235fa80
Cr-Commit-Position: refs/heads/master@{#374353}
==========

[commit-bot: I haz the power, 2016-02-09 12:05:57]

Patchset 8 (id:??) landed as
https://crrev.com/ee2d13a54fc1de09762f1e5be97d6db44235fa80
Cr-Commit-Position: refs/heads/master@{#374353}

[Nico, 2016-02-09 15:19:17]

This seems to not build in release component builds:
https://build.chromium.org/p/chromium.fyi/builders/CrWinClang%28shared%29/bui...

FAILED: C:\b\depot_tools\python276_bin\python.exe gyp-win-tool
link-with-manifests environment.x86 True command_buffer_gles2_tests.exe
"C:\b\depot_tools\python276_bin\python.exe gyp-win-tool link-wrapper
environment.x86 False link.exe /nologo /OUT:command_buffer_gles2_tests.exe
@command_buffer_gles2_tests.exe.rsp" 1 mt.exe rc.exe
"obj\gpu\command_buffer_gles2_tests.command_buffer_gles2_tests.exe.intermediate.manifest"
obj\gpu\command_buffer_gles2_tests.command_buffer_gles2_tests.exe.generated.manifest
..\..\build\win\compatibility.manifest
command_buffer_gles2_tests.command_buffer_gles2_tests_main.obj : error LNK2019:
unresolved external symbol "bool g_command_buffer_gles_has_atexit_manager"
(?g_command_buffer_gles_has_atexit_manager@@3_NA) referenced in function _main

[Nico, 2016-02-09 15:19:36]

A revert of this CL (patchset #8 id:140001) has been created in
https://codereview.chromium.org/1680743007/ by thakis@chromium.org.

The reason for reverting is: This seems to not build in release component
builds:
https://build.chromium.org/p/chromium.fyi/builders/CrWinClang%28shared%29/bui...

FAILED: C:\b\depot_tools\python276_bin\python.exe gyp-win-tool
link-with-manifests environment.x86 True command_buffer_gles2_tests.exe
"C:\b\depot_tools\python276_bin\python.exe gyp-win-tool link-wrapper
environment.x86 False link.exe /nologo /OUT:command_buffer_gles2_tests.exe
@command_buffer_gles2_tests.exe.rsp" 1 mt.exe rc.exe
"obj\gpu\command_buffer_gles2_tests.command_buffer_gles2_tests.exe.intermediate.manifest"
obj\gpu\command_buffer_gles2_tests.command_buffer_gles2_tests.exe.generated.manifest
..\..\build\win\compatibility.manifest
command_buffer_gles2_tests.command_buffer_gles2_tests_main.obj : error LNK2019:
unresolved external symbol "bool g_command_buffer_gles_has_atexit_manager"
(?g_command_buffer_gles_has_atexit_manager@@3_NA) referenced in function _main.

[Kimmo Kinnunen, 2016-02-11 12:12:16]

Description was changed from

==========
command_buffer_gles2: Add test command_buffer_gles2_test for
command_buffer_gles2

Add test command_buffer_gles2_test for testing command_buffer_gles2
library.

Makes the gpu bots to build target, but the target is not run
on any bot.

As an example, fix a potential nullptr reference in eglInitialize
and tests the problem.

Adding the test runner would be useful in order to further develop
command_buffer_gles2. One development direction of the library
would be to extend it enough to support creating OpenGL ES 3.0
context.

BUG=581634

Committed: https://crrev.com/ee2d13a54fc1de09762f1e5be97d6db44235fa80
Cr-Commit-Position: refs/heads/master@{#374353}
==========

to

==========
command_buffer_gles2: Add test command_buffer_gles2_test for
command_buffer_gles2

Add test command_buffer_gles2_test for testing command_buffer_gles2
library.

Makes the gpu bots to build target, but the target is not run
on any bot.

As an example, fix a potential nullptr reference in eglInitialize
and tests the problem.

Adding the test runner would be useful in order to further develop
command_buffer_gles2. One development direction of the library
would be to extend it enough to support creating OpenGL ES 3.0
context.

BUG=581634

Committed: https://crrev.com/ee2d13a54fc1de09762f1e5be97d6db44235fa80
Cr-Commit-Position: refs/heads/master@{#374353}
==========

[Kimmo Kinnunen, 2016-02-12 12:27:36]

Description was changed from

==========
command_buffer_gles2: Add test command_buffer_gles2_test for
command_buffer_gles2

Add test command_buffer_gles2_test for testing command_buffer_gles2
library.

Makes the gpu bots to build target, but the target is not run
on any bot.

As an example, fix a potential nullptr reference in eglInitialize
and tests the problem.

Adding the test runner would be useful in order to further develop
command_buffer_gles2. One development direction of the library
would be to extend it enough to support creating OpenGL ES 3.0
context.

BUG=581634

Committed: https://crrev.com/ee2d13a54fc1de09762f1e5be97d6db44235fa80
Cr-Commit-Position: refs/heads/master@{#374353}
==========

to

==========
command_buffer_gles2: Add test command_buffer_gles2_test for
command_buffer_gles2

Add test command_buffer_gles2_test for testing command_buffer_gles2
library.

Makes the gpu bots to build target, but the target is not run
on any bot.

As an example, fix a potential nullptr reference in eglInitialize
and tests the problem.

Adding the test runner would be useful in order to further develop
command_buffer_gles2. One development direction of the library
would be to extend it enough to support creating OpenGL ES 3.0
context.

BUG=581634

Committed: https://crrev.com/ee2d13a54fc1de09762f1e5be97d6db44235fa80
Cr-Commit-Position: refs/heads/master@{#374353}
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[Kimmo Kinnunen, 2016-02-12 12:45:14]

The CQ bit was checked by kkinnunen@nvidia.com to run a CQ dry run

[commit-bot: I haz the power, 2016-02-12 12:45:29]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1640243002/160001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1640243002/160001

[commit-bot: I haz the power, 2016-02-12 13:21:17]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-12 13:21:19]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)

[Kimmo Kinnunen, 2016-02-12 14:34:13]

The CQ bit was checked by kkinnunen@nvidia.com to run a CQ dry run

[commit-bot: I haz the power, 2016-02-12 14:34:45]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1640243002/200001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1640243002/200001

[commit-bot: I haz the power, 2016-02-12 14:58:32]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-12 14:58:33]

Dry run: Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[Kimmo Kinnunen, 2016-02-12 17:55:50]

The CQ bit was checked by kkinnunen@nvidia.com to run a CQ dry run

[commit-bot: I haz the power, 2016-02-12 17:56:55]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1640243002/220001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1640243002/220001

[commit-bot: I haz the power, 2016-02-12 19:10:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-12 19:10:41]

Dry run: This issue passed the CQ dry run.

[Kimmo Kinnunen, 2016-02-15 06:51:36]

The CQ bit was checked by kkinnunen@nvidia.com

[Kimmo Kinnunen, 2016-02-15 06:51:36]

The patchset sent to the CQ was uploaded after l-g-t-m from thakis@chromium.org,
piman@chromium.org
Link to the patchset: https://codereview.chromium.org/1640243002/#ps220001
(title: "remove debug")

[commit-bot: I haz the power, 2016-02-15 06:51:55]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1640243002/220001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1640243002/220001

[commit-bot: I haz the power, 2016-02-15 08:04:46]

Committed patchset #12 (id:220001)

[Nico, 2016-02-15 15:28:41]

I'm a bit concerned that this only builds on Windows by accident, not because
it's actually correct...

https://codereview.chromium.org/1640243002/diff/200001/gpu/gpu.gyp
File gpu/gpu.gyp (right):

https://codereview.chromium.org/1640243002/diff/200001/gpu/gpu.gyp#newcode450
gpu/gpu.gyp:450: 'EGLAPI=__declspec(dllexport)',
Isn't the usual spelling here __declspec(dllimport) when using the library and
__declspec(dllexport) when building it?

Look at any of our _EXPORT macros (e.g. BASE_EXPORT)

https://codereview.chromium.org/1640243002/diff/200001/gpu/gpu.gyp#newcode453
gpu/gpu.gyp:453: 'defines': [
TABS

https://codereview.chromium.org/1640243002/diff/200001/gpu/gpu.gyp#newcode486
gpu/gpu.gyp:486: 'defines': [
MORE TABS

https://codereview.chromium.org/1640243002/diff/200001/gpu/gpu.gyp#newcode489
gpu/gpu.gyp:489: }],
AAAAAAH

[commit-bot: I haz the power, 2016-02-16 22:49:03]

Description was changed from

==========
command_buffer_gles2: Add test command_buffer_gles2_test for
command_buffer_gles2

Add test command_buffer_gles2_test for testing command_buffer_gles2
library.

Makes the gpu bots to build target, but the target is not run
on any bot.

As an example, fix a potential nullptr reference in eglInitialize
and tests the problem.

Adding the test runner would be useful in order to further develop
command_buffer_gles2. One development direction of the library
would be to extend it enough to support creating OpenGL ES 3.0
context.

BUG=581634

Committed: https://crrev.com/ee2d13a54fc1de09762f1e5be97d6db44235fa80
Cr-Commit-Position: refs/heads/master@{#374353}
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
command_buffer_gles2: Add test command_buffer_gles2_test for
command_buffer_gles2

Add test command_buffer_gles2_test for testing command_buffer_gles2
library.

Makes the gpu bots to build target, but the target is not run
on any bot.

As an example, fix a potential nullptr reference in eglInitialize
and tests the problem.

Adding the test runner would be useful in order to further develop
command_buffer_gles2. One development direction of the library
would be to extend it enough to support creating OpenGL ES 3.0
context.

BUG=581634

Committed: https://crrev.com/ee2d13a54fc1de09762f1e5be97d6db44235fa80
Cr-Commit-Position: refs/heads/master@{#374353}
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel

Committed: https://crrev.com/6aceb55a100ae0f821a83751ea73ab136cc746f9
Cr-Commit-Position: refs/heads/master@{#375420}
==========

[commit-bot: I haz the power, 2016-02-16 22:49:05]

Patchset 12 (id:??) landed as
https://crrev.com/6aceb55a100ae0f821a83751ea73ab136cc746f9
Cr-Commit-Position: refs/heads/master@{#375420}