On Fri, 12 Jul 2002, José Fonseca wrote: > On Thu, Jul 11, 2002 at 06:34:40PM -0400, Leif Delgass wrote: > > On Thu, 11 Jul 2002, Brian Paul wrote: > > > > > Leif Delgass wrote: > > > > > > > > I just discovered that the glean failures in blendFunc, logicOp, > > > > orthoPosRandTris, orthoPosRandRects, orthoPosTinyQuads, and polygonOffset > > > > are the result of an off-by-one error in the y screen coordinates. If I > > > > add one to the Y coordinate in the viewport conversion to screen > > > > coordinates, these tests all pass. However, it breaks the scissor test > > > > and the orthoPos[H,V]Lines and orthoPosPoints tests still fail (which > > > > could be a result of the implementation of points and lines with > > > > triangles/quads). It also seems to leave a row of pixels at the top of > > > > the window which isn't drawn on, but is cleared. The stipple test still > > > > has the same problem because lines still aren't conformant. I'm still a > > > > little puzzled as to where the off-by-one error actually originates, but > > > > this narrows down the problem a lot. > > > > > > The Y-coordinate error may be less than one. Most of the DRI hardware > > > drivers need X/Y coordinates biased by a small amount in order to make > > > hardware rasterization and software rasterization coincide. > > > > > > So, something like 0.75 or 0.875 might work better. > > > > Yeah, I just realized that. I'm playing with X and Y subpixel offsets to > > try and find a combination that fixes the most problems without breaking > > tests that worked. :) > > > > Leif, note that at least with the vertices generated by > mach64_translate_vertex (i.e., converted from the VB into SWVertex during a >fallback) in the new template they will already be rounded off into the chip >precision, so that can make a difference already. You'll perhaps want look into that >as well. > > Note also that the native vertex format stuff is finished, and is now > enabled by default in the CVS. The old behavior is still there and one > can change the MACH64_NATIVE_VTXMFT macro in mach64_context.h to enable > it but that code won't stay much longer - because the new code is much > more optimized and has some fixes which I didn't bother to propagate to > the old code, and also to make place for new optimizations (such as > primitive strips and so on).
Well, I added these offsets: SUBPIXEL_X 0.0125 SUBPIXEL_Y 0.15 ...and that's enough to make every glean test pass except polygonOffset (and texEnv, but that one's due to non-conformant hardware). However, I still see gaps in e.g. the Mesa tunnel demo and the lament xscreensaver hack (and probably lots of other places). The lines in Allen's stipple test now always overlap exactly. Jose, I think your changes reduced the offset necessary, but it does need a small offset to pass the tests. Actually I think the line tests start working at a smaller offset than some of the other tests. I checked in some other changes as well, one of which was to put the primitive type defines in the drm header and common header. We have the vertsize in the SAREA, and between that and the primitive list, I think the drm should be able to figure out how to add commands to the vertex buffers. As you say, we can use send fewer vertices to the card by implementing primitive strips. I just made the defines mirror the GL primitive defines, but we could reduce them to just the ones we'll implement. One other thing: I noticed you were supporting line/point size in the new primitive functions, so I removed the code from mach64_context.c that was overwriting the Mesa defaults with a max size/width of 1. However, for large, unaliased points, we need to have points implemented as quads instead of triangles (try drawing a 10 pixel point and compare it to indirect). Oh, I also fixed polygon stippling to work as a software fallback. -- Leif Delgass http://www.retinalburn.net ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
