The BlendingFactor group contains two duplicate enums:

<group name="BlendingFactor"> <enum name="GL_ZERO"/> <enum name="GL_ONE"/> <enum name="GL_SRC_COLOR"/> **1 <enum name="GL_ONE_MINUS_SRC_COLOR"/> <enum name="GL_DST_COLOR"/> <enum name="GL_ONE_MINUS_DST_COLOR"/> <enum name="GL_SRC_ALPHA"/> **2 <enum name="GL_ONE_MINUS_SRC_ALPHA"/> <enum name="GL_DST_ALPHA"/> <enum name="GL_ONE_MINUS_DST_ALPHA"/> <enum name="GL_CONSTANT_COLOR"/> <enum name="GL_ONE_MINUS_CONSTANT_COLOR"/> <enum name="GL_CONSTANT_ALPHA"/> <enum name="GL_ONE_MINUS_CONSTANT_ALPHA"/> <enum name="GL_SRC_ALPHA_SATURATE"/> <enum name="GL_SRC1_COLOR"/> **1 <enum name="GL_ONE_MINUS_SRC_COLOR"/> <enum name="GL_SRC1_ALPHA"/> **2 <enum name="GL_ONE_MINUS_SRC_ALPHA"/> </group>

Based on the glBlendFunc documentation [1], I'm guessing that the duplicate entries should be GL_ONE_MINUS_SRC1_COLOR and GL_ONE_MINUS_SRC1_ALPHA respectively.

[1] https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glBlendFunc.xhtml

Need to add interfaces for the following extensions to gl.xml and the generated extension headers. There was some urgency about publishing these prior to SIGGRAPH and the XML changes were skipped.

• MESA_shader_integer_functions (#495)
• NVX_blend_equation_advanced_multi_draw_buffers (#492)
• ARB_gl_spirv (ARB #190)
• NV_gpu_multicast (#494)
• NVX_linked_gpu_multicast (#493)

4 types listed in Table 2.2 - GL data types are missing from GLES/gl.h (but have been provided by 1.0 gl.h in the past): byte, clampf, short, and ushort.

The function ScissorArrayvOES() added by OES_viewport_array is missing this entry in its error section/listing:

"An INVALID_VALUE error is generated if is negative."

This should probably be added to make it consistent with ViewportArrayvOES() and DepthRangeArrayfvOES(). Also, this error message as used to describe ViewportArrayvOES() has an unnecessary '>' character at the end.

In gl.xml the "pname" group references GL_NUM_DEVICE_UUIDS:

    <group name="GetPName">
        ...
        <enum name="GL_NUM_DEVICE_UUIDS"/>

GL_NUM_DEVICE_UUIDS is not mentioned anywhere else in the document.
GL_NUM_DEVICE_UUIDS_EXT on the other hand is defined:

     <enum value="0x9596" name="GL_NUM_DEVICE_UUIDS_EXT"/>

GLX_EXT_swap_control and GLX_SGI_swap_control are included in the specification, but GLX_MESA_swap_control seems to be missing.

following are used in in function parameter definitions but don't have a group definition:

BinormalPointerTypeEXT
CombinerComponentUsageNV
CombinerPortionNV
CombinerStageNV
CullParameterEXT
DataTypeEXT
ElementPointerTypeATI
EvalMapsModeNV
FragmentLightNameSGIX
FragmentLightParameterSGIX
GetVariantValueEXT
IndexFunctionEXT
IndexMaterialParameterEXT
MapTypeNV
MatrixIndexPointerTypeARB
ParameterRangeEXT
PathColorFormat
PixelTransformPNameEXT
PixelTransformTargetEXT
ProgramFormat
ProgramStringProperty
ProgramTarget
ReplacementCodeTypeSUN
ScalarType
SecondaryColorPointerTypeIBM
TangentPointerTypeEXT
VariantCapEXT
VertexShaderTextureUnitParameter
VertexShaderWriteMaskEXT
VertexWeightPointerTypeEXT
WeightPointerTypeARB

(updated 2019-06-21 in response to recent PRs - @oddhack)

Both GL/glext.h and GLES/glext.h use the same "_glext_h" include guards. This makes it hard to include both headers.

This is of interest to implementations that support both APIs.

Fixed by PR #149

Chapter 4.4 in GLSL 4.50 (revision 6) is missing an entry in the layout qualifier table. Atomic counters can use the offset qualifier (4.4.6.1), but it is not listed in the table as being valid.

Looking at the GL 1.2.1 spec:

https://www.khronos.org/registry/OpenGL/specs/gl/glspec121.pdf

It seems these two functions are present (and associated enums). But in latest gl.xml it seems they're recorded as being introduced in GL 1.4. Although it's highly unlikely to matter in practice, this difference seems like a technical error likely in the xml.

@oddhack any thoughts?

On page 97 of the spec, you can find the words "The command" floating between two sentences:

If UseProgram is called with program set to zero, then there is no current program object.
The command
The executable code for an individual shader stage is taken from the current program for that stage.

After looking at this specification, it is not clear how it interacts with features of desktop OpenGL that are not present in OpenGL ES 3.0+.

For example, in desktop GL, you are allowed to use glCompressedTexSubImage*D to modify any arbitrary rectangle, so long as the specified rectangle is along the block size boundary for the format. But in ES 3.0, you're only allowed to modify a rectangle that ends at the top right; the offset+size in each dimension must be equal to the total size in that dimension.

The extension uses the ES 3.0 wording; should we take that to mean that, if the extension is exposed to desktop GL, that the ASTC formats would have the same limitation?

For another example, destkop OpenGL allows you to create 1D textures and 1D array textures. Can you use ASTC for these?

Note that this bug was taken from the Bugzilla database. There was a response that indicated that this would be discussed and corrected, but new versions of the specification were published since then, and the issue remains.

There are several scenarios that the OpenGL specification does not explicitly disallow which are... dubious. For example:

layout(binding = 0, r32ui) uniform uimage2D foo;
layout(binding = 0, r32ui) uniform uimageRect bar;

The validation rules in section 11.1.3.11 explicitly disallows this for samplers, but not for images. And there is no explicit disallowing of two image types from using the same binding index. Which also means:

layout(binding = 0, r32ui) uniform uimage2D foo;
layout(binding = 0, r32f) uniform uimage2D bar;

The same image unit is being used with different formats.

This extends to other things as well. There is no language explicitly disallowing the user from having UBO/SSBO's share the same binding index. So this is technically legal:

layout(std430, binding = 0) buffer Buff1{...};
layout(std430, binding = 0) buffer Buff2{...};

Now, the behavior of accessing the same memory through different buffer variables is well understood (memory coherency is only guaranteed by default for read/writes to memory through the same variable). So such code could theoretically work.

But what does it mean if Buff1 and Buff2 are declared differently?

Is the ability to do these things an oversight or is it intended for them to be allowed?

In xml/gl.xml the parameter data for "precision" does not match what the OpenGL spec says. The xml has len=2:
<param len="2"><ptype>GLint</ptype> *<name>precision</name></param>
While the spec for precision reads "Specifies the address of an integer into which the numeric precision of the implementation is written.".
Thus I'd expect len to be 1.

In 7.3.1 of OpenGL 4.5, when explaining the behavior of glGetProgramResource, the behavior of the properties GL_NUM_COMPATIBLE_SUBROUTINES and GL_COMPATIBLE_SUBROUTINES are never explained. This also causes a problem with the subroutine introspection APIs added to 4.0, since they are now defined in terms of the behavior of those two properties. Which are not described.

Hello,
it look there is a trivial bug in the the start attribute of the Oculus enumeration inside the OpenGL xml registry
https://raw.githubusercontent.com/KhronosGroup/OpenGL-Registry/master/xml/gl.xml

...


...

Added an issues here since it does not look a Khronos specification problem to me.

The text "When an FBO is bound to a target, the available buffer names." makes no sense.

It is on this page: https://www.khronos.org/opengl/wiki/Framebuffer_Object

What does it mean???

I didn't notice until regenerating the headers after merging #45, but this changed the name, and sometimes the type of a number of parameters in gl.xml, in addition to creating new groups. Those parameter name changes are going to have to be reverted. In particular changing GLint internalformat -> GLenum causes API breakage with compatibility mode applications using the very ancient format names 1-4, and the other parameter name changes, such as texture->target, are incompatible with the specifications.

I'm going to revert #45. @frabert if you want to re-submit a PR which just has the new groups and group= information, without modifying any parameter names or types, that's fine. There may be a couple of cases where that's appropriate to do but in general there's historical reasons for what we have now and we consider it more important to maintain compatibility between spec, header, ref pages, etc. than to be absolutely consistent.

The extensions GL_EXT_debug_marker, GL_KHR_debug, GL_OES_surfaceless_context, and GL_OES_texture_npot are supportable in gles1 but are not marked as such in gl.xml.

Merge request to follow.

This is trivial to do but will become important when extensions are added, because scanning extensions/registry.py manually doesn't reveal this information. It can be inferred by looking at the ends of the extensions/*ext.php lists but that is a pain.

The GL_KHR_texture_compression_astc_ldr/hdr extension seems to say that ASTC-compressed textures must have each mipmap layers' width and height be multiples of block sizes. Is this intended, as no other compressed format works that way. Even ES 3.0 has no language stating that its compressed formats are required to be multiples of block sizes. Not only that, it doesn't fit the wording for glTexStorage*D, which explains those commands in terms of glTexImage*D. And there, nothing compensates for having to use sizes that are multiples of block boundaries on mipmaps.

Various functions (glVertexAttribPointer, etc) have arguments that accept void * or similar but also accept (or in core, only accept) an offset into a bound buffer. It would be nice to indicate that in the XML.

(I have a partial list, so could submit a PR for those, just need to know how to mark it in the XML. group="OffsetOrPointer" maybe, or new attribute?)

I’m trying to push a new OpenGL ES extension to https://github.com/KhronosGroup/OpenGL-Registry,

I created a local branch “add_QCOM_framebuffer_foveated” , tracking origin/master. I’ve followed the wiki. When I attempt to push to the remote repo, I get this error:

$ git remote -v
origin  https://github.com/KhronosGroup/OpenGL-Registry.git (fetch)
origin  https://github.com/KhronosGroup/OpenGL-Registry.git (push)
$ git push origin add_QCOM_framebuffer_foveated
remote: Permission to KhronosGroup/OpenGL-Registry.git denied to jackohound.
fatal: unable to access 'https://github.com/KhronosGroup/OpenGL-Registry.git/': The requested URL returned error: 403

The machine I am pushing from is running Ubuntu Linux 14.04.
I’ve confirmed that I can push to other Github repos from the same computer without problem.

Anyone seen this before, or have ideas why I cannot push to OpenGL-Registry?

In gl.xml, enums GL_TEXTURE_LUMINANCE_TYPE and GL_TEXTURE_INTENSITY_TYPE are required in 3.0 for profile="compatibility" (line 33935), and later removed in the version 3.2 BUT for profile="core" (line 34980).
Is it intended?

Hello. When will support of SPIR-V in XML specs?
GLAD library can no at now use this extension.

The spec has it as glMultiDrawElementsBaseVertexEXT (since it's attached to EXT_multi_draw_arrays which has no OES equivalent). However the gl.xml file has

<command name="glMultiDrawElementsBaseVertexOES" comment="Supported only if GL_EXT_multi_draw_arrays is supported"/>

and

    <command>
        <proto>void <name>glMultiDrawElementsBaseVertexOES</name></proto>
        <param group="PrimitiveType"><ptype>GLenum</ptype> <name>mode</name></param>
        <param len="COMPSIZE(drawcount)">const <ptype>GLsizei</ptype> *<name>count</name></param>
        <param group="DrawElementsType"><ptype>GLenum</ptype> <name>type</name></param>
        <param len="COMPSIZE(drawcount)">const void *const*<name>indices</name></param>
        <param><ptype>GLsizei</ptype> <name>primcount</name></param>
        <param len="COMPSIZE(drawcount)">const <ptype>GLint</ptype> *<name>basevertex</name></param>
        <alias name="glMultiDrawElementsBaseVertex"/>
    </command>

It may be worth noting that mesa is also accidentally providing the OES suffix for that command. The question is whether to change the gl.xml or to change the extension spec.

The deprecation tag for gl.xml is not yet supported, and that makes defining enums and commands for a version with the forward compatibility bit set to true is tough.

The EXT_shader_framebuffer_fetch specification does not detail the interaction between framebuffer fetch and sRGB rendering.

The correct behaviour in this case is to convert framebuffer values to linear space at input to the fragment shader.

Currently many of the opengl 1.0 enums are included with the opengl 1.1 enums. There is a comment mentioning this in the xml, but i'd like to see this fixed.

The "type" element may have a "requires" attribute, which allows one to specify a type that a given type is dependent on. This allows type elements to be processed in arbitrary order while still guaranteeing correctness of generated code.

However, this mechanism does not work when more than a single type is required.

Case in point: GLDEBUGPROC.

GLDEBUGPROC is defined as:
typedef void ( * GLDEBUGPROC)(GLenum source,GLenum type,GLuint id,GLenum severity,GLsizei length,const GLchar *message,const void *userParam);

It relies on a number of other non-builtin types. The corresponding type element lacks a "requires" attribute, and there's no way to determine its dependencies short of parsing the C typedef declaration.

As long as the tool that consumes the XML spec processes all types in the order they appear in the file, this won't present an issue. However, if for some reason things go in incorrect order, errors may occur.

Proposed fix: surround the referenced non-builtin types with tags, as is already done for command parameters and return values.

Using this rule, the new type element for GLDEBUGPROC would look like:
<type>typedef void ( * <name>GLDEBUGPROC</name>)(<ptype>GLenum</ptype> source, <ptype>GLenum</ptype> type,<ptype>GLuint</ptype> id, <ptype>GLenum</ptype> severity, <ptype>GLsizei</ptype> length,const <ptype>GLchar</ptype> *message,const void *userParam)</type>

On the WebGL 1 spec page (and on other non-Khronos reference sites), the following link is 404ing:

[GLES20GLSL]
The OpenGL® ES Shading Language Version 1.00, R. Simpson, May 2009.

It is pointing to:

https://www.khronos.org/registry/OpenGL/specs/es/2.0/GLSL_ES_Specification_1.0.pdf

Followup for: #162

1. Due to the change the GL API depends on khrplatform.h now which was previously not the case, this seems like a breaking change that may affect multiple users of the specification. This may also affect users that are using glcorearb.h directly (including OS package maintainers?).

2. The typedefinitions have a lot of duplicates now <type requires="khrplatform">typedef khronos_intptr_t <name>GLintptr</name>;</type>: <type api="gles1" requires="khrplatform">typedef khronos_intptr_t <name>GLintptr</name>;</type>, <type api="gles2" requires="khrplatform">typedef khronos_intptr_t <name>GLintptr</name>;</type> etc.

3. Extension types were not changed: <type requires="stddef">typedef ptrdiff_t <name>GLintptrARB</name>;</type>

Background information (shouldn't affect your decision on keeping this change):
glad an application to generate loaders based on these specifiactions broke, mainly due to a bug that was triggered by this and not the specification change itself. That's how I noticed the change (multiple users reported the generator breaking over night). My fix was to wrap the typedefs with a macro that checks if khrplatform.h was previously included, this works for glad but would not be enough for the specs.

I am not sure to fix this "better", it might be possible using macros, like guarding the type definition.

There's two slight issues that may be present with gl.xml's information on GL_EXT_texture_storage (and also potentially some overlap with GL_ARB_texture_storage).

1. The EXT extension specifies:

In particular, note that OpenGL ES 1.x/2.0 do not have proxy textures,
1D textures, or 3D textures, and thus only the TexStorage2DEXT
entry point is required. If OES_texture_3D is supported, the
TexStorage3DEXT entry point is also required.

The ARB spec is specified against OpenGL ES 1.0 and OpenGL ES 2.0, which do not have 1D/3D textures but I didn't see any mention of the conditional exposure. Seems like an oversight - in any case this information is missing from gl.xml that I saw.

2. The EXT extension is specified against OpenGL ES 1.0, OpenGL ES 2.0 or OpenGL 1.2 but gl.xml does not include it as a desktop GL extension. Conversely for ARB, it is also specified as OpenGL ES 1.0, OpenGL ES 2.0 or OpenGL 1.2, but gl.xml does not list it for gles APIs. Not sure if this is intentional.

@oddhack can you provide any clarification here? It was something we noticed when implementing an entry point loader via gl.xml.

api/GL/glx.h is missing but all other generated headers (including glxext.h) are in place.

hello I hope I can post this here.

there is an error on this page :

https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/cross.xhtml

at 'Description'

the last line of the example is :
x[0] × y[1] − y[1] × x[0]

but it should be :
x[0] × y[1] − y[0] × x[1]

by hoping it will help you

keep me in touch when you changed it, please

(sorry for my English, I'm learning)

Generated gl.h file mentions GL/glplatform.h, but I can't find any mention of this file anywhere. Is there a mistake or have I just searched too shallowly?

I'm fixing #4 and noticed that these two enums (in NV_gpu_multicast and NVX_linked_gpu_multicast) are both BufferStorage bits, with the same value, but different names. The spec language appears (effectively) identical for both, but I wanted to make sure these are intended to be semantically the same and can share the BufferStorage behavior.

Also, the MapBufferUsageMask <enums> group in gl.xml currently has bits 0x0800 and 0x1000 reserved by Joshua Schnarr, [email protected], so I also wanted to verify that this use is consistent with whatever Joshua had planned.

The extension for GL_NV_path_rendering states:

When NV_path_rendering is advertised, the following functionality must be supported...
The following entry points (specified by the EXT_direct_state_access extension) MUST be supported:

void MatrixLoadfEXT(enum matrixMode, const float *m);
void MatrixLoaddEXT(enum matrixMode, const double *m);
(snip)

However these entry points are never mentioned in gl.xml, and EXT_direct_state_access is not mentioned as a GLES extension. Maybe these entry points be added to gl.xml under this extension, instead of under EXT_direct_state_access, since that is not specified as a GLES extension.

This is making life hard for my auto-generation script. @oddhack any possible resolution?

This is related with the issue Dav1dde/glad#115.

I'm using glad loader, with OpenGL core 3.3, and it seems that the loader doesn't define GL_BLEND_COLOR because in the gl.xml, GL_BLEND_COLOR is not <require>'d by GL 2.0.

However, the functions glBlendColor, glBlendFunc, glBlendEquation are available for OpenGL 2.0-4.5, and assume that you can use GL_BLEND_COLOR.

Am I mistaking something or is it an actual bug?

Some time ago in email, @Khronoswebmaster suggested that we should:

add the following just below the <title></title> tags:

<meta name="viewport" content="width=device-width”/>

With it, the pages flow properly and the text is readable.

Should revisit this now.

The type VULKANPROCNV is not defined, but used (for the extension GL_NV_draw_vulkan_image) in a typedef. Naturally, this makes projects fail to compile that include GL/glcorearb.h GL/glext.h or GLES2/gl2ext.h

I was not sure if this bug belonged in Bugzilla or here, for reference the bug in Bugzilla is located at https://www.khronos.org/bugzilla/show_bug.cgi?id=1943

The error list DispatchComputeIndirect says:

An INVALID_OPERATION error is generated if zero is bound to the
DRAW_INDIRECT_BUFFER binding.

I'm fairly sure that should be DISPATCH_INDIRECT_BUFFER, not DRAW.

I am the developer of glad and currently in glad the SVN/CVS will be used to download specifications (as well as for daily updates on the online generator).

Now with Dav1dde/glad#73 the issue arose of a bug in the spec, you guys fixed the issue very quickly here, but this fix has not been pushed to SVN yet.

What is the state of the SVN mirror? Is the Github master branch "stable enough" to use?

When this was registered, I was told that "the spec is applicable to both desktop OpenGL and OpenGL ES". However, the dependencies section does not say what the required version of ES or ESSL is. Until someone from Mesa corrects this, it will not be tagged as part of the ES registry in extensions/registry.py, just the GL registry.

https://www.khronos.org/registry/OpenGL/extensions/MESA/MESA_shader_integer_functions.txt

It looks like the symbols for NV_pixel_buffer_object never made it into the XML file, and by extension are missing from gl2ext.h.

I am using the gl.xml for CodeGeneration with glad and i noticed that the len value on some parameters are missing. For example the glGetnUniformfv is missing the len value on "params" while glGetnUniformfvARB and glGetnUniformfvEXT got them.

Following a list of functions where the value is missing

• glReadnPixels - <param>void *<name>data</name></param>
• glGetnUniformfv - <param><ptype>GLfloat</ptype> *<name>params</name></param>
• glGetnUniformiv - <param><ptype>GLint</ptype> *<name>params</name></param>
• glGetnUniformuiv - <param><ptype>GLuint</ptype> *<name>params</name></param>
• glGetnUniformfvKHR - <param><ptype>GLfloat</ptype> *<name>params</name></param>
• glGetnUniformivKHR - <param><ptype>GLint</ptype> *<name>params</name></param>
• glGetnUniformuivKHR - <param><ptype>GLuint</ptype> *<name>params</name></param>
• glGetQueryivEXT - <param><ptype>GLint</ptype> *<name>params</name></param>
• glGetQueryObjectivEXT - <param><ptype>GLint</ptype> *<name>params</name></param>
• glGetQueryObjectuivEXT - <param><ptype>GLuint</ptype> *<name>params</name></param>

Hey,

@mcclure found a bug where GL_EXT_texture_filter_minmax contains the definitions for GL_EXT_raster_multisample, but GL_ARB_texture_filter_minmax contains the correct ones.

Definition for TEXTURE_FILTER_MINIMAX:

        <extension name="GL_EXT_texture_filter_minmax" supported="gl|glcore|gles2">
            <require>
                <enum name="GL_RASTER_MULTISAMPLE_EXT"/>
                <enum name="GL_RASTER_SAMPLES_EXT"/>
                <enum name="GL_MAX_RASTER_SAMPLES_EXT"/>
                <enum name="GL_RASTER_FIXED_SAMPLE_LOCATIONS_EXT"/>
                <enum name="GL_MULTISAMPLE_RASTERIZATION_ALLOWED_EXT"/>
                <enum name="GL_EFFECTIVE_RASTER_SAMPLES_EXT"/>
                <command name="glRasterSamplesEXT"/>
            </require>
        </extension>

And the one for RASTER_MULTISAMPLE:

        <extension name="GL_EXT_raster_multisample" supported="gl|glcore|gles2">
            <require>
                <enum name="GL_RASTER_MULTISAMPLE_EXT"/>
                <enum name="GL_RASTER_SAMPLES_EXT"/>
                <enum name="GL_MAX_RASTER_SAMPLES_EXT"/>
                <enum name="GL_RASTER_FIXED_SAMPLE_LOCATIONS_EXT"/>
                <enum name="GL_MULTISAMPLE_RASTERIZATION_ALLOWED_EXT"/>
                <enum name="GL_EFFECTIVE_RASTER_SAMPLES_EXT"/>
                <command name="glRasterSamplesEXT"/>
            </require>
        </extension>

Looking at GL_ARB_texture_filter_minmax, these definitions appear to be correct:

        <extension name="GL_ARB_texture_filter_minmax" supported="gl|glcore">
            <require>
                <enum name="GL_TEXTURE_REDUCTION_MODE_ARB"/>
                <enum name="GL_WEIGHTED_AVERAGE_ARB"/>
            </require>
        </extension>

Original Bug Report: Dav1dde/glad#126

Specifically, it talks about gl_Vertex/InstanceIndex, rather than gl_Vertex/InstanceID. However much I might wish that we had the former instead of the latter, GLSL sadly does not. Well, except for the KHR_vulkan_glsl variation, but that's a different matter. Indeed, the ARB_gl_spirv extension specifically calls out how GLSL doesn't have these variables in its "Corresponding features not added to GLSL that GL_KHR_vulkan_glsl added" section.

We just had a bug report in Mesa about conflicting type declarations in GL & GLES3 headers.

The gist of it is:

/usr/include/GLES3/gl31.h:77:25: error: conflicting declaration 'typedef khronos_ssize_t GLsizeiptr'
 typedef khronos_ssize_t GLsizeiptr;
                         ^~~~~~~~~~
/usr/include/GL/glext.h:468:19: note: previous declaration as 'typedef ptrdiff_t GLsizeiptr'
 typedef ptrdiff_t GLsizeiptr;
                   ^~~~~~~~~~

A quick glance at the two headers reveals many more conflicts.

My first thought is that the generation script should detect these duplicates and move them to a common header, which would be included by all the headers; this could look something like:

#if defined(GL_ES_VERSION_2_0) || defined(GL_VERSION_1_5)
typedef khronos_ssize_t GLsizeiptr;
typedef khronos_intptr_t GLintptr;
#endif

What are your thoughts?

Adding all the GL and ES ref page trees would increase the size of this repo by about 50% (80 MB or so), and it's already pretty huge. OTOH it's convenient to have them in the same place as the registry. TBD.