trace all EGL extensions

[José Fonseca]

On Thu, Dec 1, 2011 at 10:24 AM, Chia-I Wu <olvaffe at gmail.com> wrote:
> On Thu, Dec 1, 2011 at 5:29 PM, José Fonseca <jose.r.fonseca at gmail.com> wrote:
>> On Thu, Dec 1, 2011 at 7:20 AM, Chia-I Wu <olvaffe at gmail.com> wrote:
>>> Hi,
>>>
>>> I've spent some time adding all EGL extensions to specs/eglapi.py.
>>> The changes are available at
>>>
>>>  https://github.com/olvaffe/apitrace/commits/trace-egl-extensions
>>>
>>> $ git diff --stat master..trace-egl-extensions
>>>  specs/eglapi.py |  177 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>  1 files changed, 177 insertions(+), 0 deletions(-)
>>>
>>> It was just a tedious process to go through the specs and eglext.h to
>>> add the entrypoints, types, and enums.
>>
>> I don't know what process you used to generate these, but I added a
>> bit more documentation on the spec/scripts FWIW.
>>
>> gltxt.py doesn't handle enums or new types, but it now handles
>> prototypes reasonably well:
> I did not know about this script!  I had to do that manually.
>
> I will run the scripts to verify my changes.
>> $ ./gltxt.py --prefix=
>> http://www.khronos.org/registry/egl/extensions/NV/EGL_NV_sync.txt
>>    # EGL_NV_sync
>>    GlFunction(EGLSyncNV, "eglCreateFenceSyncNV", [(EGLDisplay,
>> "dpy"), (EGLenum, "condition"), (Const(OpaquePointer(EGLint)),
>> "attrib_list")]),
>>    GlFunction(EGLBoolean, "eglDestroySyncNV", [(EGLSyncNV, "sync")]),
>>    GlFunction(EGLBoolean, "eglFenceNV", [(EGLSyncNV, "sync")]),
>>    GlFunction(EGLint, "eglClientWaitSyncNV", [(EGLSyncNV, "sync"),
>> (EGLint, "flags"), (EGLTimeNV, "timeout")]),
>>    GlFunction(EGLBoolean, "eglSignalSyncNV", [(EGLSyncNV, "sync"),
>> (EGLenum, "mode")]),
>>    GlFunction(EGLBoolean, "eglGetSyncAttribNV", [(EGLSyncNV, "sync"),
>> (EGLint, "attribute"), (OpaquePointer(EGLint), "value")]),
>>
>> It should be easy to make it handle enums too.
>>
>> I noticed that you separated the enums:
>>
>> +EGLSyncKHRType = FakeEnum(EGLenum, [
>> +    "EGL_SYNC_REUSABLE_KHR",        # 0x30FA
>> +
>> +    # EGL_KHR_fence_sync
>> +    "EGL_SYNC_FENCE_KHR",           # 0x30F9
>> +])
>> +
>> +EGLSyncKHRAttrib = FakeEnum(EGLint, [
>> +    "EGL_SYNC_STATUS_KHR",          # 0x30F1
>> +    "EGL_SYNC_TYPE_KHR",            # 0x30F7
>> +
>> +    # EGL_KHR_fence_sync
>> +    "EGL_SYNC_CONDITION_KHR",       # 0x30F8
>> +
>> +    "EGL_NONE",
>> +])
>> +
>> +EGLSyncKHRMode = FakeEnum(EGLenum, [
>> +    "EGL_SIGNALED_KHR",             # 0x30F2
>> +    "EGL_UNSIGNALED_KHR",           # 0x30F3
>> +])
>> +
>>
>> Although this is more "correct", I think this is more trouble than
>> it's worth, specially because same enums are often used in different
>> parameters (often with different semantics). So for Khronos APIs I
>> only separate the enums when they overlap (e.g, GL_NONE, GL_ZERO,
>> etc), or for bitmask. So I'd suggest you
>>
>> EGLenum = Enum('EGLenum", [
>>    ...
>>    "EGL_SYNC_STATUS_KHR",          # 0x30F1
>>    "EGL_SIGNALED_KHR",             # 0x30F2
>>    "EGL_UNSIGNALED_KHR",           # 0x30F3
>>    "EGL_SYNC_TYPE_KHR",            # 0x30F7
>>    "EGL_SYNC_CONDITION_KHR",       # 0x30F8
>>    "EGL_SYNC_FENCE_KHR",           # 0x30F9
>>    "EGL_SYNC_REUSABLE_KHR",        # 0x30FA
>>    ....
>> ])
> That makes sense.  I will merge the enums.  I followed glxapi.py to
> separate them, but it now seems to have too many kinds of enums for no
> good reason.
>
> But this example will not work.  Where EGL_SYNC_STATUS_KHR is used
> expects EGLint, not EGLenum.  Maybe I should have
>
> EGLenum = Enum("EGLenum", [
>  # enums that are used in EGLenum
>  "EGL_NATIVE_PIXMAP_KHR",
>  ...
> ])
>
> EGLattrib = FakeEnum(EGLint, [
>  # enums that are used in EGLint
>  "EGL_SYNC_STATUS_KHR",
>  ...
> ])

Yep.  Another is keep everything in EGLenum and then do,

  EGLattrib = Alias("EGLint", EGLenum)

which means, EGLattrib is an EGLint, but its values are actually EGLenum.

>>> If there is no objection, I'd like to merge it sometime tomorrow.
>>
>> I'm fine with you merginging the branch as is BTW.  My comments above
>> are merely suggestions for future improvements.
> Thanks.  I prefer to merge the branch, and clean eglapi.py up in
> follow-on commits if that's ok.

Yep. It's fine. No need to rush either.

Jose