On Thu, 11 Jul 2002, Allen Barnett wrote: > On Wednesday 10 July 2002 07:59 pm, Leif Delgass wrote: > > On Thu, 11 Jul 2002, José Fonseca wrote: > > > Allen, thanks for the detailed report of the problems. It's gonna take a > > > little time (at least for me) to reproduce all this (I have been a little > > > busy lately and I still have some changes I want to do on the driver > > > before I can look into it) but it will be done. > > No problem. > > > > Note also that there are some OpenGL conformance issues which have been > > > neglected so far, and which can be the cause behind of some of these > > > problems. At any rate your cases will help to determine that. > > > > I'm > > not sure that the banding in textures is really a bug. At 16-bit, > > RGBA/RGBA8 textures use stored in an ARGB4444 format, and RGB/RGB8 > > textures are stored as RGB565, so there is less color information in the > > textures with an alpha channel. The test looks the same on the Rage 128 > > as on Mach 64. > > I guess this is what I expected. Is there a way to keep the full resolution > of the texture image until it is shipped off to the hardware, or is that what > you mean by "stored as ARGB4444"?
With Mesa 4.x, Mesa allows the driver to choose a texture format that matches the hardware, which eliminates the need to convert the texture to hardware format before uploading it. Delaying that conversion would only make a difference for software fallbacks, I think. The hardware does the texture application otherwise, and at that point the texture has been converted and uploaded to AGP or card memory. > > The registration problem with the stipple test may be a > > result of the conformance problems Jose mentioned. The stippled lines are > > rendered in software, so the difference in placement is likely a result of > > slight errors in the coordinates on the hardware path. I've noticed gaps > > between triangles in places and some problems with texture coordinates as > > well. I think these first appeared with the Mesa 4.x merge. > > OK. > > Thanks for looking into this. 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. -- Leif Delgass http://www.retinalburn.net ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases & more http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
