Updates to GLX_EXT_texture_from_pixmap

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Jones wrote:
> A few updates to the spec:
> 
>         -Disallowed rendering to a drawable while it is bound as a texture
>          and defined the exact contents of a texture after a drawable has
>          been bound to it.

[snip]

> I realize the first change is still under debate.  Consider it a proposal, as 
> the language in question has already gone back and forth many times.  I have 
> no doubt it will change again.  Here is the relevant text:
> 
>     The contents of the texture after the drawable has been bound are defined
>     as the result of all rendering that has completed before the call to
>     glXBindTexImageEXT.  In other words, the results of any operation which
>     has caused damage on the drawable prior to the glXBindTexImageEXT call
>     will be represented in the texture.

This is the behavior that app developers will expect.  The
synchronisation steps mentioned in the issues section will make app
developers unhappy.

>     Rendering to the drawable, either using the GL or other means, while it is
>     bound to a texture is not allowed.  It is the responsibility of the user
>     to enforce this constraint.  If the drawable is rendered to while it is
>     bound as a texture, the contents become undefined.

This wording is no good.  It is either not allowed (i.e., you get an
error of some sort when you try to do it) or the results are undefined.
 In terms of how GL functionality is specified, the two are mutually
exclusive.

> Dependencies
> 
>     OpenGL 1.1 is required.
>     GLX 1.3 is required.

Should this be "Either GLX 1.3, or GLX 1.2 and GLX_SGIX_fbconfig is
required"?  I only mention this because the status section claims that
this is implemented on an X-server that *does not* implement GLX 1.3. :)
 It implements GLX 1.2 + GLX_SGIX_fbconfig.  I also don't see anything
in the spec that requires functionality not in GLX 1.2 + GLX_SGIX_fbconfig.

>     GL_EXT_framebuffer_object affects the definition of this extension.
>     GL_ARB_texture_rectangle affects the definition of this extension.
>     GL_ARB_texture_non_power_of_two affects the definition of this extension.
> 
> Issues
> 
>     2. Should we allow applications to render to different mipmap levels and
>     cube map faces?
> 
>     In order to discourage the use of this extension as a render to texture
>     mechanism, cube maps and rendering directly to mip-map levels > 0 will
>     not be supported.  A new FBConfig attribute is introduced that specifies
>     whether or not drawables created with that config will support multiple
>     mipmap levels when bound to a texture.  The other mipmap levels can be
>     filled in by the FBO GenerateMipmapEXT function.

I agree with the conclusion, but this is the wrong rationale to use.
There will be some users that will say, "Damnit!  I want to use this as
render-to-texture, and you spec'ed it this way just to spite me!"  A
better rationale is that being able to bind to mipmap levels, cube
faces, or slices of a 3D texture may result in an implicit data copy
where it would otherwise not be need.  For that reason and others,
supporting this functionality places additional burden on
implementations and may prevent driver fast-paths from being used.

>     4. What should the default value for GLX_TEXTURE_TARGET_EXT be?  Should
>     users be required to set this value if GLX_TEXTURE_FORMAT_EXT is not
>     GLX_TEXTURE_FORMAT_NONE_EXT?
> 
>     The implementation is capable of choosing a reasonable default, we simply
>     need to specify the correct way to do so.  We can base the ordering on
>     the properties of the pixmap and the texturing capabilities of the
>     pixmap's FBConfig and the implementation.
> 
>     The order is:
> 
>     - If GL_ARB_texture_non_power_of_two is supported GL_TEXTURE_2D will
>       be used for all pixmap sizes.
> 
>     - If only GL_ARB_texture_rectangle is supported GL_TEXTURE_2D will
>       be used for all power of two pixmap sizes and GL_TEXTURE_RECTANGLE_ARB
>       will be used for all non power of two pixmap sizes.

I'm not sure I like this.  It seems to violate the principle of least
surprise.  The issue being that GL_TEXTURE_2D and
GL_TEXTURE_RECTANGLE_ARB treat texture coordinates differently.  It may
be better to have the application explicitly request the target that it
wants in all cases, and have the bind fail if that request cannot be
satisfied (e.g., because the texture is not a power-of-two and
GL_ARB_texture_non_power_of_two / GL 2.0 are not supported).  Dunno.

>     6. What is the result of calling GenerateMipmapEXT on a drawable that
>     was not created with mipmap levels?
> 
>     The results are undefined.

Is there a particular reason to not generate an error?

>     Accepted by the <Buffer> parameter of glXBindTexImageEXT and 
>     glXReleaseTexImageEXT: 

For symmetry with the rest of the GL, the following should also be defined:

          GLX_FRONT_EXT                      GLX_FRONT_LEFT_EXT
          GLX_BACK_EXT                       GLX_BACK_LEFT_EXT

>         GLX_FRONT_LEFT_EXT                 0x???? (0x6005)
>         GLX_FRONT_RIGHT_EXT                0x????
>         GLX_BACK_LEFT_EXT                  0x????
>         GLX_BACK_RIGHT_EXT                 0x????
>         GLX_AUX0_EXT                       0x???? 
>         GLX_AUX1_EXT                       0x???? 
>         GLX_AUX2_EXT                       0x???? 
>         GLX_AUX3_EXT                       0x???? 
>         GLX_AUX4_EXT                       0x???? 
>         GLX_AUX5_EXT                       0x???? 
>         GLX_AUX6_EXT                       0x????
>         GLX_AUX7_EXT                       0x???? 
>         GLX_AUX8_EXT                       0x???? 
>         GLX_AUX9_EXT                       0x????

> Additions to the GLX Specification

[snip]

>     It is not an error to call TexImage2D, TexImage1D, CopyTexImage1D, or
>     CopyTexImage2D to replace an image of a texture object that has a color
>     buffer bound to it.  However, these calls will cause the color buffer to be
>     released and new memory to be allocated for the texture.  Note that the
>     color buffer is released even if the image that is being defined is a mipmap
>     level that was not defined by the color buffer.  GenerateMipmapEXT is an
>     exception.  GenerateMipmapEXT can be used to define mipmap levels for
>     drawables that have been created with GLX_MIPMAP_TEXTURE_EXT set.  Calling
>     GenerateMipmapEXT on a drawable that was created without
>     GLX_MIPMAP_TEXTURE_EXT is undefined.

Since SGIS_generate_mipmap is part of core GL, there should be at least
some mention of the interation with it.  What happens if an application
makes the following calls:

    glBindTexture( GL_TEXTURE_2D, my_tex );
    glTexParameteri( GL_TEXTURE_2D, GL_GENERATE_MIPMAP, GL_TRUE );
    glXBindTexImageEXT( dpy, my_glx_pixmap, GL_FRONT_LEFT_EXT, NULL );

If mipmap levels are not generated (and I suspect that they aren't), the
spec needs explicitly say that.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEELLnX1gOwKyEAw8RAv8IAJ9rn1/lw0bWUbM557CWsR1lAcJJdgCfegvK
Thz/tuTKPFxntXzDVpgPvPI=
=S95h
-----END PGP SIGNATURE-----