build/common.gypi - Issue 556333003: Add support for khronos gl-cts using its drawElements apis

Unified Diff: build/common.gypi

Issue 556333003: Add support for khronos gl-cts using its drawElements apis (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master

Patch Set: Created 6 years, 3 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View side-by-side diff with in-line comments

Download patch

Index: build/common.gypi

diff --git a/build/common.gypi b/build/common.gypi

index dc38c4be9fb3d91418a7803d634e91992f0c1584..78dc2ba09a68e031432e6a96f4d4a5e12d167ffa 100644

--- a/build/common.gypi

+++ b/build/common.gypi

@@ -1378,6 +1378,9 @@

# Set to 1 to compile with the OpenGL ES 2.0 conformance tests.

'internal_gles2_conform_tests%': 0,

+ # Set to 1 to compile with the OpenGL ES 3.x conformance tests.

+ 'internal_khronos_conform_tests%': 0,

piman 2014/09/10 20:12:50 Does this and internal_gles2_conform_tests need to

U. Artie Eoff 2014/09/10 22:12:59 I think the "gles2" in the name "internal_gles2_co

Ken Russell (switch to Gerrit) 2014/09/11 00:03:26 Understood that the duplication may be necessary f

U. Artie Eoff 2014/09/11 01:09:19 Well... the idea is to target all the tests actual

Ken Russell (switch to Gerrit) 2014/09/11 01:25:17 I still think a more targeted name is appropriate.

I still think a more targeted name is appropriate. If not gles3, then gles, or khronos_gles, or something. If some future API comes around under Khronos' umbrella that isn't tested in this particular harness, a naming conflict with this would be unfortunate. What do you think?

U. Artie Eoff 2014/09/11 16:50:52 Yeah, I'd be fine using "khronos_gles_conform". O

On 2014/09/11 01:25:17, Ken Russell wrote: > On 2014/09/11 01:09:19, uartie wrote: > > On 2014/09/11 00:03:26, Ken Russell wrote: > > > On 2014/09/10 22:12:59, uartie wrote: > > > > On 2014/09/10 20:12:50, piman (Very slow to review) wrote: > > > > > Does this and internal_gles2_conform_tests need to be separate? I'd > assume > > > > > whoever has access to one has access to the other one. It'd be simpler > to > > > only > > > > > have one of these. > > > > > > > > I think the "gles2" in the name "internal_gles2_conform_tests" is too > narrow > > > and > > > > implies only es2 tests. We want to add es3 tests and future versions > later. > > > > > We > > > > could merge these, I suppose, into one form eventually; one which doesn't > > > > constrict meaning so much (like internal_khronos_conform here). But I'd > > > rather > > > > be able to compile one and not the other. I think the idea behind this is > > to > > > > incrementally ramp up with the new drawElements support and phase out the > > old. > > > > > > > This requires having both for the transition phase. > > > > > > Understood that the duplication may be necessary for the time being due to > > major > > > differences between the test harnesses. However the naming convention here > is > > > confusing. Since you're explicitly targeting the ES 3.x tests can you please > > > replace 'khronos' with 'gles3' throughout this CL? > > > > Well... the idea is to target all the tests actually. That is, to target ES2, > > ES30, ES31, and any future ES versions (and who knows, maybe GL21 thru GL44 > and > > beyond). All versions can be targeted in one [binary] instance using this new > > API. That is why I chose the more generic naming convention. In fact, this > > particular patch only targets the ES2 tests at the moment, the same as the > > gles2_conform_support. The main difference is it's using the new APIs so that > > we can trivially add the other ESx tests later without being constrained by > > naming conventions. > > I still think a more targeted name is appropriate. If not gles3, then gles, or > khronos_gles, or something. If some future API comes around under Khronos' > umbrella that isn't tested in this particular harness, a naming conflict with > this would be unfortunate. What do you think?

Yeah, I'd be fine using "khronos_gles_conform". Or, what about "khronos_glcts"? GL-CTS is the true project name of their entire conformance suite afterall (see their cmake file). It does make a shorter prefix and also is a bit more of a targeted name than my original. If no one likes that, I'll go with the former.

Ken Russell (switch to Gerrit) 2014/09/11 17:40:04 Both sound fine. If khronos_glcts is closer to the

On 2014/09/11 16:50:52, uartie wrote: > On 2014/09/11 01:25:17, Ken Russell wrote: > > On 2014/09/11 01:09:19, uartie wrote: > > > On 2014/09/11 00:03:26, Ken Russell wrote: > > > > On 2014/09/10 22:12:59, uartie wrote: > > > > > On 2014/09/10 20:12:50, piman (Very slow to review) wrote: > > > > > > Does this and internal_gles2_conform_tests need to be separate? I'd > > assume > > > > > > whoever has access to one has access to the other one. It'd be simpler > > to > > > > only > > > > > > have one of these. > > > > > > > > > > I think the "gles2" in the name "internal_gles2_conform_tests" is too > > narrow > > > > and > > > > > implies only es2 tests. We want to add es3 tests and future versions > > later. > > > > > > > We > > > > > could merge these, I suppose, into one form eventually; one which > doesn't > > > > > constrict meaning so much (like internal_khronos_conform here). But I'd > > > > rather > > > > > be able to compile one and not the other. I think the idea behind this > is > > > to > > > > > incrementally ramp up with the new drawElements support and phase out > the > > > old. > > > > > > > > > This requires having both for the transition phase. > > > > > > > > Understood that the duplication may be necessary for the time being due to > > > major > > > > differences between the test harnesses. However the naming convention here > > is > > > > confusing. Since you're explicitly targeting the ES 3.x tests can you > please > > > > replace 'khronos' with 'gles3' throughout this CL? > > > > > > Well... the idea is to target all the tests actually. That is, to target > ES2, > > > ES30, ES31, and any future ES versions (and who knows, maybe GL21 thru GL44 > > and > > > beyond). All versions can be targeted in one [binary] instance using this > new > > > API. That is why I chose the more generic naming convention. In fact, this > > > particular patch only targets the ES2 tests at the moment, the same as the > > > gles2_conform_support. The main difference is it's using the new APIs so > that > > > we can trivially add the other ESx tests later without being constrained by > > > naming conventions. > > > > I still think a more targeted name is appropriate. If not gles3, then gles, or > > khronos_gles, or something. If some future API comes around under Khronos' > > umbrella that isn't tested in this particular harness, a naming conflict with > > this would be unfortunate. What do you think? > > Yeah, I'd be fine using "khronos_gles_conform". Or, what about "khronos_glcts"? > GL-CTS is the true project name of their entire conformance suite afterall (see > their cmake file). It does make a shorter prefix and also is a bit more of a > targeted name than my original. If no one likes that, I'll go with the former.

Both sound fine. If khronos_glcts is closer to the real name of the project, let's go with that.

# Set to 1 to compile the filter fuzzer.

'internal_filter_fuzzer%': 0,

« AUTHORS ('K') | « build/all.gyp ('k') | gpu/khronos_conform_support/DEPS » ('j') | gpu/khronos_conform_support/DEPS » ('J')