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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
|
|