On Thu, 11 Jul 2002 16:44:50 -0400 (EDT)
Leif Delgass <[EMAIL PROTECTED]> wrote:
> 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.
Could there also be an off-by-one error for the x-coordinates? I'm
asking because I still see the problem that the right most collumn and
bottom line of the screen (not window) are not drawn correctly.
Just a thought,
Felix
__\|/__ ___ ___ ___
__Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___
_____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____
[EMAIL PROTECTED] >o<__/ \___/ \___/ at the same time!
-------------------------------------------------------
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
