Re: [Dri-devel] textures corruption vs. hw rendering

[Daryll S. <da...@pr...>]

On Sun, Dec 19, 1999 at 01:22:38PM -0600, Brynn Rogers wrote:

> If you look at the moebius runnning with hw accel, you will see that
  anything in the top 1/4 of the screen looks fine.  The line '
  glPolygonMode(GL_FRONT_AND_BACK, GL_LINE); ' is almost the only
  difference between the fast, working moebius (except forthe ant legs,
  the are also GL_LINE) and the really Slooooow broken moebius.

Yes, I noticed that. Also notice the ants thmselves are fine. I also
flipped to the back buffer. (I have a little hack that lets me do that)
and the image is identical, so this isn't a blitting problem. It also
can't be a clipping problem because we are getting something drawn on
the entire region. So that leaves a driver problem.

> the GL_POINTS that are used in a few other places have the same exact
  problem.  I think these are all related to the same thing.  Bug number
  1000438 on sourceforge is my first report of this problem.

> There is a time in the performer town demo when you can stroll up to a
  billboard, and only that portion of the billboard in the top 1/4 of
  the screen will get textured correctly, but any part of the billboard
  lower than that is fubar.

> Whatever this bug is also seems to cause a huge performance hit, you
  also noticed that the mesa moebius appears faster than the hw accell
  one ( at least untill you stop doing so many GL_LINE's)

This is all consistent with lines being done in software and being
broken. At least it narrows the focus. The billboards are probably done
as a pixmap instead of a texture map, and that too hits the software
path which goes through the same routine to write the pixels to the
screen. At least that's my theory from the discussion. I need to do some
more debugging on it to be sure. (See fxddspan.c)

By the way, when we are writing pixels, we basically lock the
framebuffer and then do a bunch of direct writes. That's very
inefficient. I suspect we'd get much better performance if we used
grDrawPoint(s) which essentially sends a 1x1 triangle(s). The problem is
that locking the framebuffer requires flushing all the operations that
are in the pipe and waiting for the hardware to idle.

						- |Daryll