lkml.org 
[lkml]   [2005]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: State of Linux graphics
    Alan Cox wrote:
    > On Iau, 2005-09-01 at 09:24 -0600, Brian Paul wrote:
    >
    >>If the blending is for screen-aligned rects, glDrawPixels would be a
    >>far easier path to optimize than texturing. The number of state
    >>combinations related to texturing is pretty overwhelming.
    >
    >
    > As doom showed however once you can cut down some of the combinations
    > particularly if you know the texture orientation is limited you can
    > really speed it up.
    >
    > Blending is going to end up using textures onto flat surfaces facing the
    > viewer which are not rotated or skewed.

    Hi Alan,

    It's other (non-orientation) texture state I had in mind:

    - the texel format (OpenGL has over 30 possible texture formats).
    - texture size and borders
    - the filtering mode (linear, nearest, etc)
    - coordinate wrap mode (clamp, repeat, etc)
    - env/combine mode
    - multi-texture state

    It basically means that the driver may have to do state checks similar
    to this to determine if it can use optimized code. An excerpt from Mesa:

    if (ctx->Texture._EnabledCoordUnits == 0x1
    && !ctx->FragmentProgram._Active
    && ctx->Texture.Unit[0]._ReallyEnabled == TEXTURE_2D_BIT
    && texObj2D->WrapS == GL_REPEAT
    && texObj2D->WrapT == GL_REPEAT
    && texObj2D->_IsPowerOfTwo
    && texImg->Border == 0
    && texImg->Width == texImg->RowStride
    && (format == MESA_FORMAT_RGB || format == MESA_FORMAT_RGBA)
    && minFilter == magFilter
    && ctx->Light.Model.ColorControl == GL_SINGLE_COLOR
    && ctx->Texture.Unit[0].EnvMode != GL_COMBINE_EXT) {
    if (ctx->Hint.PerspectiveCorrection==GL_FASTEST) {
    if (minFilter == GL_NEAREST
    && format == MESA_FORMAT_RGB
    && (envMode == GL_REPLACE || envMode == GL_DECAL)
    && ((swrast->_RasterMask == (DEPTH_BIT | TEXTURE_BIT)
    && ctx->Depth.Func == GL_LESS
    && ctx->Depth.Mask == GL_TRUE)
    || swrast->_RasterMask == TEXTURE_BIT)
    && ctx->Polygon.StippleFlag == GL_FALSE
    && ctx->Visual.depthBits <= 16) {
    if (swrast->_RasterMask == (DEPTH_BIT | TEXTURE_BIT)) {
    USE(simple_z_textured_triangle);
    }
    else {
    USE(simple_textured_triangle);
    }
    }
    [...]

    That's pretty ugly. Plus the rasterization code for textured
    triangles is fairly complicated.

    But the other significant problem is the application has to be sure it
    has set all the GL state correctly so that the fast path is really
    used. If it gets one thing wrong, you may be screwed. If different
    drivers optimize slightly different paths, that's another problem.

    glDrawPixels would be simpler for both the implementor and user.

    -Brian
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-09-01 18:08    [W:0.023 / U:30.700 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site