Name
    INTEL_map_texture

Name Strings
    GL_INTEL_map_texture

Contact
    Slawomir Grajewski, INTEL (slawomir.grajewski 'at' intel.com)

Contributors
    Jan Paul van Waveren, id Software
    Kamil Patelczyk, INTEL
    Aneta Roztkowska, INTEL
    Piotr Uminski, INTEL

Status
    Draft.

Version
    Last Modified Date: June 5, 2012
    Author Revision: 1

Number

    429

Dependencies
    OpenGL 3.0 is required.

    This extension is written against the OpenGL 4.2 Specification
    compatibility profile.

Overview
    Systems with integrated GPUs can share the same physical memory between CPU
    and GPU. This feature, if exposed by API, can bring significant performance
    benefits for graphics applications by reducing the complexity of
    uploading/accessing texture contents. This extension enables CPU direct
    access to the GPU memory holding textures.

    The problem with texture memory directly exposed to clients is that
    textures are often 'tiled'. Texels are kept in specific layout to improve
    locality of reference and thus performance of texturing. This 'tiling'
    is specific to particular hardware and would be thus difficult to use.

    This extension allows to create textures with 'linear' layout which allows
    for simplified access on user side (potentially sacrificing some
    performance during texture sampling).

New Procedures and Functions

    void* MapTexture2DINTEL(uint texture, int level, bitfield access,
                            int *stride, enum *layout);

    void UnmapTexture2DINTEL(uint texture, int level);

    void SyncTextureINTEL(uint texture);


New Tokens

    Accepted by the <pname> parameter of TexParameteri, for target TEXTURE_2D

             TEXTURE_MEMORY_LAYOUT_INTEL    0x83FF

    Accepted by the <params> when <pname> is set to
    <TEXTURE_MEMORY_LAYOUT_INTEL>:

             LAYOUT_DEFAULT_INTEL            0
             LAYOUT_LINEAR_INTEL             1
             LAYOUT_LINEAR_CPU_CACHED_INTEL  2

Additions to Chapter 3.10.8 of the OpenGL 4.2 (Compatibility Profile)
Specification

Add a row to the table 3.22

    Name:
    TEXTURE_MEMORY_LAYOUT_INTEL

    Type:
    enum

    Legal Values:
    LAYOUT_DEFAULT_INTEL
    LAYOUT_LINEAR_INTEL
    LAYOUT_LINEAR_CPU_CACHED_INTEL

Add a paragraph in the end of the section:

    When <pname> is TEXTURE_MEMORY_LAYOUT_INTEL and <params> is
    LAYOUT_LINEAR_INTEL the texture is forced to be allocated as linear and can
    be mapped directly to the CPU address space by MapTexture2DINTEL (see section
    3.10.4).

    When <pname> is TEXTURE_MEMORY_LAYOUT_INTEL and <params> is
    LAYOUT_LINEAR_CPU_CACHED_INTEL the behavior is the same as in case of
    <params> set to LAYOUT_LINEAR_INTEL with an exception that texture is
    cached for CPU accesses. This can result in better performance when reading
    texture on CPU but might negatively impact the GPU side access to the
    texture. Thus the option is intended only for cases when volume of the read
    access from CPU justifies such effect.

    Only when <pname> is TEXTURE_MEMORY_LAYOUT_INTEL or
    LAYOUT_LINEAR_CPU_CACHED_INTEL, MapTexture2DINTEL returns CPU accessible
    pointer.

    The allocation of the texture can be reverted to the default,
    implementation-specific format, including tiled formats, by calling
    TexParameteri with <pname> set to TEXTURE_MEMORY_LAYOUT_INTEL and <params>
    set to LAYOUT_DEFAULT_INTEL. The configured texture layout is ignored until
    the texture is allocated or reallocated using TexImage2D function.

    The error INVALID_VALUE is generated when <pname> is
    TEXTURE_MEMORY_LAYOUT_INTEL and the texture target is not TEXTURE_2D.

Additions to Chapter 3.10.4 of the OpenGL 4.2 (Compatibility Profile) Specification

    The command

        void* MapTexture2DINTEL(uint texture, int level, bitfield access,
                                int *stride, enum *layout);

    attempts to return a direct pointer to the graphics storage for 2D texture
    indicated by the <texture> parameter.

    The <level> parameter indicates the mipmap level-of-detail of the texture
    for which pointer is requested.

    The <access> bitfield indicates type of access that will be performed by
    the application on the memory accessed via the returned pointer: reading -
    MAP_READ_BIT, writing - MAP_WRITE_BIT. Performing access on mapped memory
    different then specified in <access> is undefined (and may result in
    application termination).

    If the operation is successful, the function returns a valid pointer,
    otherwise NULL is returned. Upon successful completion, the function also
    returns 'stride', which is the distance in bytes between subsequent rows in the
    texture, and <layout>, indicating the internal layout of the texture in the
    graphics memory.

    When texture uses linear memory layout, subsequent texels in a row of the
    image are occupying subsequent addresses in memory. Subsequent rows of
    image are located at 'stride' bytes distance within each other. For tiled
    layout, the relationship between texels and addresses in memory is
    different and will not be further discussed in this extension.

    The layout of the texture, discussed in the preceding section, is returned
    via <layout> parameter. In this version of the extension, the only texture
    memory layout that can be returned is LAYOUT_LINEAR_INTEL or
    LAYOUT_LINEAR_CPU_CACHED_INTEL.

    All of the following conditions need to be met for the operation to succeed:
      - <texture> is a texture first bound to TEXTURE_2D target
      - <texture> has sized color internal format (see section 3.10.3)
      - texture parameter TEXTURE_MEMORY_LAYOUT_INTEL was either
        LAYOUT_LINEAR_INTEL or LAYOUT_LINEAR_CPU_CACHED_INTEL during texture
        image specification
      - <level> texture mipmap level is defined
      - texture border of <texture> is zero
    Otherwise MapTexture2DINTEL fails with INVALID_OPERATION error, and return
    NULL.

    Please note that texture allocated as linear is noticeably slower than
    tiled when accessed by the GPU, however in many scenarios direct access to
    such texture from CPU is more important than slower GPU access, especially
    when texture is frequently updated with limited number of accesses from
    GPU.

    The command MapTexture2DINTEL can return valid pointer only if given
    internalformat as specified by TexImage2D() is sized (as indicated in
    tables 16 and 17) and natively supported by the GPU hardware. This means
    that there has to be 1:1 match between internalformat and underlying
    hardware format with respect to the number of components, their sizes and
    order in graphics memory.

    It is an error to attempt to map texture that is defined inconsistently (one
    which doesn't provide mipmap levels with the same internal format or with
    sizes not being half the previous level) or to redefine texture levels
    (through TexImage2D, CopyTexImage2D) when texture mappings exist for this
    texture. These cases will result in undefined behavior.

    The command

        void UnmapTexture2DINTEL(uint texture, int level);

    releases the pointer obtained previously via MapTexture2DINTEL. This means
    that virtual memory space dedicated to make the texture available via
    a pointer is released and an application can no longer assume this memory
    is accessible from CPU. Successful execution of this command has an additional
    effect as if SyncTextureINTEL was called with <texture> parameter.

    The command

        void SyncTextureINTEL(uint texture);

    makes sure that changes made by CPU are visible to GPU by flushing texture
    cache in GPU. The GL implementation tracks the cache usage and ignores the
    command if such flush is not needed.

    It is worth noting that this extension does not address automatic
    synchronization between CPU and GPU when both entities operate on the same
    texture at the same time. This is up to the application to assure such
    synchronization. Otherwise, the results may not be deterministic (writes
    from different entities may interleave in a non-deterministic way).

Modifications to the OpenGL Shading Language Specification.

    None.

Errors

    INVALID_OPERATION is generated by MapTexture2DINTEL when <texture> is 0 or
    not a name of texture object first bound to TEXTURE_2D target, when <level>
    of <texture> is already mapped, when <texture> storage was allocated with
    TEXTURE_MEMORY_LAYOUT_INTEL different then LAYOUT_LINEAR_INTEL or
    LAYOUT_LINEAR_CPU_CACHED_INTEL or <level> is mipmap level not defined in
    <texture>.

    INVALID_VALUE is generated by MapTexture2DINTEL when <access> has bits other
    then MAP_WRITE_BIT or MAP_READ_BIT set or is 0.

    INVALID_OPERATION is generated by UnmapTexture2DINTEL when <texture> is not
    an existing texture object or is 0, <level> of <texture> is not currently
    mapped.

New State

(add to table 6.24, "Textures (state per texture object)")

    Get Value                          Type    Get Command        Initial Value              Description             Section       Attribute
    -------------------------------    ------  -------------      -------------              --------------------    ------------  ---------
    TEXTURE_MEMORY_LAYOUT_INTEL        Z       GetTexParameteriv  LAYOUT_DEFAULT_INTEL       Texture memory layout   -             -

Issues

      (1) Is it possible to ensure that contents of mapped texture is
          automatically updated after rendering to texture or GPU write (using
          texture as FBO attachment or using image_load_store functionality)?

      RESOLUTION:
        a) No guarantees are given in case of 'rendering loops' when surface
           is mapped. To make sure that contents of mapping is 'current',
           texture data mutation needs to be guaranteed as is done already
           and mapped only after that.

      RESOLVED: No.


      (2) What happens if Tex(Sub)Image* or CopyTex(Sub)Image is called on
          mapped texture? What happens if mapped texture is deleted?

      RESOLUTION:
        a) Calling Tex(Sub)Image may cause the texture to be reallocated, thus
           it is necessary to unmap texture before calling these functions
           (after these functions complete, the pointer may become invalid).

        b) Calling CopyTex(Sub)Image is safe for a texture for which a CPU
           pointer has been obtained via MapTexture2DINTEL.

        c) After deleting the texture, the pointer obtained via
           MapTexture2DINTEL becomes invalid.

      RESOLVED: Yes.


      (3) Is it possible to enforce alignment of mapped texture level?

      RESOLUTION: No.


      (4) Is it legal to write to / read from regions between row end and stride?

      RESOLUTION:
        a) Yes. Writing to memory that is after end of the row up to stride is
           safe and has no effect.

      RESOLVED: Yes.


      (5) What happens if texture with unsupported (not native) format is
           mapped?

      RESOLUTION:
        NULL pointer is returned.

      RESOLVED: Yes.


      (6) Are compressed formats supported?

      RESOLUTION:
        a) Yes.

      RESOLVED: Yes.


Revision History

    Rev.    Date    Author        Changes
    ----  --------  --------     -----------------------------------------
     1    06/05/12  S. Grajewski Initial revision.