Re: [Dri-devel] radeon: quads rendered too small

2002-10-18 Thread Keith Whitwell
Michel Dänzer wrote: On Son, 2002-10-13 at 17:54, Michel Dänzer wrote: I've done some more clueless digging into the problem visible in http://penguinppc.org/~daenzer/DRI/evas_test.jpeg and http://penguinppc.org/~daenzer/DRI/celestia.jpeg . My first suspicion was an off-by-one error in the

Re: [Dri-devel] PCIGART Radeon AIW support

2002-10-18 Thread Michel Dänzer
On Don, 2002-10-17 at 21:07, James Fung wrote: The PCI radeon seems to work fairly well actually: OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI Radeon 20020611 AGP 1x x86/MMX/3DNow! TCL OpenGL version string: 1.2 Mesa 4.0.4 glxgears gives 1000 frames in

Re: [Dri-devel] dri_data_flow and control_flow diagrams +explanations website

2002-10-18 Thread Michel Dänzer
On Die, 1999-11-30 at 03:07, Smitty wrote: This has been sitting around for a long time, since I got pulled into the website side of things. I wish to put this up as high level design documentation. Any comments? The two documents look great! Up they go. They match many of my

Re: [Dri-devel] radeon: quads rendered too small

2002-10-18 Thread Brian Paul
Keith Whitwell wrote: Michel Dänzer wrote: On Son, 2002-10-13 at 17:54, Michel Dänzer wrote: I've done some more clueless digging into the problem visible in http://penguinppc.org/~daenzer/DRI/evas_test.jpeg and http://penguinppc.org/~daenzer/DRI/celestia.jpeg . My first suspicion was an

Re: [Dri-devel] r200: unexpected texture format in r200ChoosTexFormat

2002-10-18 Thread Brian Paul
Dieter Nützel wrote: Mesa/tests ./multipal r200CreateScreen 2 texture units supported ../images/tile.rgb 256 x 256 Mesa implementation error: unexpected texture format in r200ChoosTexFormat Please report to the DRI bug database at dri.sourceforge.net multipal: texstore.c:729:

Re: [Dri-devel] Mesa 4.1 branch

2002-10-18 Thread Stefan Lange
I cvs-updated both Mesa and mesa-4-1-branch today, and I don't get any more FPE's with R200_NO_TCL=1. Thanks! Stefan --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf

Re: [Dri-devel] radeon: quads rendered too small

2002-10-18 Thread Michel Dänzer
On Fre, 2002-10-18 at 15:13, Brian Paul wrote: Keith Whitwell wrote: Michel Dänzer wrote: On Son, 2002-10-13 at 17:54, Michel Dänzer wrote: I've done some more clueless digging into the problem visible in http://penguinppc.org/~daenzer/DRI/evas_test.jpeg and

Re: [Dri-devel] Mesa 4.1 branch

2002-10-18 Thread Brian Paul
Stefan Lange wrote: I cvs-updated both Mesa and mesa-4-1-branch today, and I don't get any more FPE's with R200_NO_TCL=1. Thanks! Hmmm, I don't recall changing anything that would account for this. Bugs that magically go away always make me nervous. -Brian

Re: [Dri-devel] radeon: quads rendered too small

2002-10-18 Thread Brian Paul
Michel Dänzer wrote: On Fre, 2002-10-18 at 15:13, Brian Paul wrote: Keith Whitwell wrote: Michel Dänzer wrote: On Son, 2002-10-13 at 17:54, Michel Dänzer wrote: I've done some more clueless digging into the problem visible in http://penguinppc.org/~daenzer/DRI/evas_test.jpeg and

Re: [Dri-devel] radeon: quads rendered too small

2002-10-18 Thread Allen Akin
On Fri, Oct 18, 2002 at 08:49:11AM -0600, Brian Paul wrote: | | ...(except polygon offset, IMHO). Is the precision requirement too high, or is something more fundamental broken? Allen --- This sf.net email is

Re: [Dri-devel] celestia and multitexture

2002-10-18 Thread Voyageur
Thanks for the gcc 3.2 indication! And indeed card doesn't seem to make a difference: same problem with mach64 (0-0-5 branch from a week ago, mobility M1 chipset). I was so glad it didn't segfault anymore when trying to see Earth (problem signaled a few months ago), but now no Saturn :( So

Re: [Dri-devel] radeon: quads rendered too small

2002-10-18 Thread Brian Paul
Allen Akin wrote: On Fri, Oct 18, 2002 at 08:49:11AM -0600, Brian Paul wrote: | | ...(except polygon offset, IMHO). Is the precision requirement too high, or is something more fundamental broken? IIRC, the test draws extremely small (subpixel) triangles.

Re: [Dri-devel] dri_data_flow and control_flow diagrams + explanations website

2002-10-18 Thread Smitty
btw is the DDX Driver what causes the XServer to be single threaded? I think there are more fundamental reasons. Better change that back then. Also sticking up dri_driver_features table by Brian Paul, it may not be complete but it is full of info already. Yes, looks good. I'd change

Re: [Dri-devel] radeon: quads rendered too small

2002-10-18 Thread Allen Akin
On Fri, Oct 18, 2002 at 11:49:46AM -0600, Brian Paul wrote: | | IIRC, the test draws extremely small (subpixel) triangles. Yeah, the original version of the test did that. The current version uses a full-window-size quad, so I think it's much better with respect to the problems you mentioned.

Re: [Dri-devel] OpenGL 1.3, 1.4, and extension string issue

2002-10-18 Thread Ian Romanick
I sent this message once, but I accidentally just sent it to Brian, so here goes... On Thu, Oct 17, 2002 at 01:16:13PM -0600, Brian Paul wrote: In the DRI drivers we keep a bitfield to determine if/why we need a software fallback. I suppose IsFast() could return a similar bitfield but coming

[Dri-devel] STOP YOUR FORCLOSURE................................................... csq

2002-10-18 Thread FORCLOSURE SPECIALISTS… . . 99259
CLICK HERE Unsubscribe click here litohpicgeevpryrmchlqkvpoqedhdv --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD

Re: [Dri-devel] radeon: quads rendered too small

2002-10-18 Thread Allen Akin
On Sat, Oct 19, 2002 at 12:03:05AM +0200, Michel Dänzer wrote: | Attached is the output of glean -c comparing two runs, one with the | subpixel offset for the Y coordinate, the other without. It seems if it | makes a difference, it's for the good ... Did the trunk pass the tests involving

Re: [Dri-devel] Re: [Xpert]Re: Probable return of Radeon, R128XFree86 crash at VT switch

2002-10-18 Thread Mike A. Harris
On Thu, 17 Oct 2002, Marc Aurele La France wrote: The problem WAS that this re-enabling did not always take place before Marc's changes, which is why we added the explicit call to do this. I've checked the code in current XFree86 CVS, but would very much like to know (just for interest's