public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Brian Paul <brian.paul@tungstengraphics.com>
To: Discuss issues related to the xorg tree  <xorg@lists.freedesktop.org>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: Re: State of Linux graphics
Date: Thu, 01 Sep 2005 10:04:27 -0600	[thread overview]
Message-ID: <4317268B.20306@tungstengraphics.com> (raw)
In-Reply-To: <1125590991.15768.55.camel@localhost.localdomain>

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

  reply	other threads:[~2005-09-01 16:05 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-30 16:03 State of Linux graphics Jon Smirl
2005-08-30 17:26 ` David Reveman
2005-08-30 18:13   ` Jon Smirl
2005-08-30 22:38   ` Dave Airlie
2005-08-31  6:33   ` Allen Akin
2005-08-31  8:11     ` Anshuman Gholap
2005-08-31 17:20     ` David Reveman
2005-08-31 17:48     ` Jim Gettys
2005-08-31 18:23       ` Jon Smirl
2005-08-31 19:06       ` Allen Akin
2005-08-31 19:14         ` Jim Gettys
2005-08-31 18:29     ` Keith Packard
2005-08-31 20:06       ` Allen Akin
2005-08-31 20:20         ` Ian Romanick
2005-09-01  1:04           ` James Cloos
2005-08-31 21:06         ` Keith Packard
2005-09-01  1:58           ` Allen Akin
2005-09-01  3:11             ` Ian Romanick
2005-09-01  6:00               ` Antonio Vargas
2005-09-01 10:20                 ` Alan Cox
2005-09-01 13:57                   ` Antonio Vargas
2005-09-01  6:11               ` Allen Akin
2005-09-01  3:59             ` Keith Packard
2005-09-01 15:24               ` Brian Paul
2005-09-01 15:59                 ` Jim Gettys
2005-09-01 16:39                   ` Andreas Hauser
2005-09-01 20:18                     ` Jim Gettys
2005-09-01 20:38                       ` Jon Smirl
2005-09-01 21:29                         ` Sean
2005-09-01 16:09                 ` Alan Cox
2005-09-01 16:04                   ` Brian Paul [this message]
2005-09-01 17:21                     ` Ian Romanick
2005-09-01 17:26                       ` Keith Whitwell
2005-09-01 20:03               ` Allen Akin
2005-08-31  3:11 ` Daniel Stone
2005-08-31  4:29   ` Jon Smirl
2005-08-31  4:50   ` Jon Smirl
     [not found]     ` <1125464500.8730.68.camel@localhost.localdomain>
2005-08-31  5:17       ` Jon Smirl
2005-08-31  5:23       ` Jon Smirl
2005-08-31  5:40         ` Jon Smirl
2005-08-31  6:15 ` Eric Anholt
2005-08-31 13:38   ` Jon Smirl
  -- strict thread matches above, loose matches on Subject: below --
2005-09-02  2:44 rep stsb
2005-09-03  4:00 mcartoaje

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4317268B.20306@tungstengraphics.com \
    --to=brian.paul@tungstengraphics.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xorg@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox