Re: [Dri-devel] mach64 testing - xor logic op

[Leif D. <lde...@re...>]

Hi Graham,

I just wanted to let you know that I'm looking into this.  I think I've
found the problem with the clear happening in the wrong place.  I'm 
looking at some other clipping problems along with this, and I hope to get 
a fix commited fairly soon.

As far as the logic op problem goes, I think this may be part of another
problem I've been trying to track down which is causing conformance
problems in the glean tests.  BTW, logic ops are done in software since
the mach64 doesn't have hardware support for them.  The glean logicOp and
blendFunc tests fail and report readback error.  I think the problem might
be related to the card caching framebuffer data and Mesa is reading old
data when it does the logic op (or other software rendering).  I was able
to fix the failure of the glean maskedClear test by prereading and
discarding a dword from the framebuffer after card idle, which is what the
DDX does in the XAA sync function to counter this problem.  However, the
change I made didn't affect the logicOp and blendFunc failures in glean,
so I'm still trying to find a fix for that.

One thing you might test is whether the problem happens if you don't do
front buffer rendering, but draw to the back buffer and swap for each
mouse move.  I've found that the Mesa texenv demo has problems with the
textures done in software when drawing to the front buffer, but it works
with double-buffering.

On Tue, 2 Jul 2002, Graham Hay wrote:

> Hello all,
> I've been following the mach64 efforts closely and it seemed
> like a good time to try a binary snapshot. Very impressive!
> Thanks to all involved.
> 
> I did find a problem running an OpenGL app I wrote for work.
> It seems that when I use the XOR logic op for rubber
> banded lines/rectangles that it doesn't erase the previously
> drawn pixels. They get set to something which looks like an
> XOR would, but it stays that way. Maybe the logic op is set
> wrong?
> 
> I wrote a smaller test program for this in C which you can
> find here:
> 
> http://www.tardis.ed.ac.uk/~gnh/mach64/xor_test.c
> 
> It should show you what I'm talking about. Also, when the
> window first pops up the glClear isn't coincident with the
> top left of the window as if the viewport wasn't right,
> although the rectangle is in the right place. Another
> clear via expose does affect the whole window, but if I
> put the window half off screen and drag it back into the
> middle, only parts of it are cleared.
> 
> This all works using software rendering,
> using export LIBGL_ALWAYS_INDIRECT=1 has no problems nor
> no nvidias drivers on my other machine for example.
> 
> I hope this helps - it may not be quake III, but at least
> theres some code to look at and I know some of you aren't
> just into games.
> 
> system is a PIII dell laptop, 8MB mach64:
> ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 64) (prog-if 00 [VGA])
> 
> Thanks again for all your work,
> Graham
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Sign up for SBC Yahoo! Dial - First Month Free
> http://sbc.yahoo.com
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dri-devel mailing list
> Dri...@li...
> https://lists.sourceforge.net/lists/listinfo/dri-devel
> 

-- 
Leif Delgass 
http://www.retinalburn.net