Re: [Dri-devel] Mach64 work
I haven't started working on these, so if you choose one of these to work there there wouldn't be chance of we repeating same work. I'll keep updating all other mach64_* files until their are in sync with Mesa 4.x and then start on the file of these that you don't choose or help in any other way. Is this ok with you? Just hope, after all these wonderful texture-related changes, you wont forget to update (and notify us testers) binary snapshots:) Cheers, Sergey PS Thank for new slim tarballs. Less then 2 megs - it is cool! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-3-branch compiles, runs (and segfaults)
On 2002.03.01 07:25 Leif Delgass wrote: I've commited the last major chunk of the Mesa 4 merge, mainly in mach64_tris.c. The branch should now compile and run, but it needs debugging, as glxgears is still segfaulting. That's great Leif! I'm working on it. It seems that the problem is on the vertex buffers setup: #0 emit_wg (ctx=0x8050440, start=0, end=216, dest=0x40c5c020, stride=1) at ../../../../../../extras/Mesa/src/tnl_dd/t_dd_vbtmp.h:331 #1 0x40493958 in mach64BuildVertices (ctx=0x8050440, start=0, count=216, newinputs=16777218) at mach64_vb.c:365 #2 0x404593b9 in run_render (ctx=0x8050440, stage=0x8105940) at t_vb_render.c:307 #3 0x40417a67 in _tnl_run_pipeline (ctx=0x8050440) at t_pipeline.c:155 #4 0x40416129 in _tnl_run_cassette (ctx=0x8050440, IM=0x810c140) at t_imm_exec.c:372 #5 0x40410ac2 in execute_compiled_cassette (ctx=0x8050440, data=0x8113d9c) at t_imm_dlist.c:376 #6 0x4035ae69 in execute_list (ctx=0x8050440, list=1) at dlist.c:4000 #7 0x4035c9c6 in _mesa_CallList (list=1) at dlist.c:4836 ... -- Leif Delgass http://www.retinalburn.net _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Bleeding-edge Was: Mach64 work
Automated binary snapshots of the mach64-0-0-3-branch built in every 4 hours from now on are available on http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/bleeding-edge/ . Be aware though that at this moment this won't be of much use unless you also want to help debugging the segfaults. Regards, José Fonseca On 2002.02.28 20:38 Sergey V. Udaltsov wrote: ... Just hope, after all these wonderful texture-related changes, you wont forget to update (and notify us testers) binary snapshots:) Cheers, Sergey PS Thank for new slim tarballs. Less then 2 megs - it is cool! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Bleeding-edge Was: Mach64 work
Automated binary snapshots of the mach64-0-0-3-branch built in every 4 hours from now on are available on http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/bleeding-edge/ . Great! Be aware though that at this moment this won't be of much use unless you also want to help debugging the segfaults. Thanks for the warning. Just please give a shout when it is testable, OK? Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: More on TCL Testing...
On Mon, Feb 25, 2002 at 05:53:51PM -0500, Adam K Kirchhoff wrote: On Mon, 25 Feb 2002, Keith Whitwell wrote: OK, great - it looks like some things work for you... That's an improvement, anyway... What would be helpful would be to look at Mesa/samples, and identify what in there works doesn't work. Start with 'depth', 'prim', 'stars', 'tri'. Similarly for the Mesa/demos directory. I'm breaking them into either works or doesn't work. I'm skipping the ones that need unsupported extensions. If you'd like more detail on any (or all) of them, just let me know. Here's the rundown on the Mesa/samples... accum -- works bitmap1 -- works bitmap2 -- works ... etc Could be a red herring, but pretty much the output of grep -l DEPTH_TEST ~/Mesa/samples/*.c == 'doesn't work' in your list. -- Michael. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: More on TCL Testing...
Michael wrote: On Mon, Feb 25, 2002 at 05:53:51PM -0500, Adam K Kirchhoff wrote: On Mon, 25 Feb 2002, Keith Whitwell wrote: OK, great - it looks like some things work for you... That's an improvement, anyway... What would be helpful would be to look at Mesa/samples, and identify what in there works doesn't work. Start with 'depth', 'prim', 'stars', 'tri'. Similarly for the Mesa/demos directory. I'm breaking them into either works or doesn't work. I'm skipping the ones that need unsupported extensions. If you'd like more detail on any (or all) of them, just let me know. Here's the rundown on the Mesa/samples... accum -- works bitmap1 -- works bitmap2 -- works ... etc Could be a red herring, but pretty much the output of grep -l DEPTH_TEST ~/Mesa/samples/*.c == 'doesn't work' in your list. I'd really been scratching my head about that one. I'll look into this. In the meantime I'me about to commit something rather nice: A dedicated Begin/End engine for the radeon tcl driver with dynamic code generation for commands like glVertex, glColor, etc. This has significantly improved scores on some of the viewperf tests, and once it's better integrated, should do so for most of them. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-3-branch runs (and locks) Was: segfaults
José Fonseca wrote: I've found the problem. It was the GET_VIEWPORT_MAT() which was defined to 0 but when there is no hw viewport (as in our case) this is used to get the viewport matrix. Strangely the viewport matrix is stored in a context variable named hw_viewport. Hence my confusion and previous decision to not define it... It can be hard to name things. This is the viewport matrix massaged to include whatever hardware oddities are required (origin in wrong place, pixel centering, etc). Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: PIOlocking disabling
On 2002.03.01 18:30 Leif Delgass wrote: On Fri, 1 Mar 2002, José Fonseca wrote: I've overcome this, but sursprisingly there is no further segfault. I see all the debuging statements scrolling in my terminal without stoping. This either means that the problem is at the locking mechanism or in the card programming in _tris.c. I'm really suspicious about the locking because when I first disabled the MMIO (since the driver doesn't really do PIO) and forget about disabling the locking the my computer also hanged. How can this be? Since when the locking is overriden the computer doesn't hang this means that the problem must when locking. Hmm, I'm not sure. I know that we never resolved all the issues with locking with the DDX driver, which is why XAA is disabled. The card locking up could just mean it's been programmed with bad data or state, not necessarily a lock conflict, I think. Any ideas? Here's my experience so far: With locking disabled, I got a segfault in mach64CopyBuffer at line 139, where box (mmesa-pClipRects) was null. Then I re-enabled locking (still This segfault is fixed with the attached patch that allows to enter into mach64GetLock to setup the clipRects. with debugging output on). Then I get a see a bunch of messages, the last ones which are still visible are: FLUSH_BATCH in mach64WriteMonoRGBAPixels_RGB565 followed by a lockup in mach64CopyBuffer once again. This appears to happpen right before swapping buffers via the DRM. The lockup isn't fatal, so I can ssh in, kill X and restart X from another box. I'll let you know if I make any progress here. Ok. José Fonseca mach64-debug-2.patch Description: Binary data
Re: [Dri-devel] Re: PIOlocking disabling
On Fri, 1 Mar 2002, José Fonseca wrote: ... With locking disabled, I got a segfault in mach64CopyBuffer at line 139, where box (mmesa-pClipRects) was null. Then I re-enabled locking (still This segfault is fixed with the attached patch that allows to enter into mach64GetLock to setup the clipRects. with debugging output on). Then I get a see a bunch of messages, the last ones which are still visible are: FLUSH_BATCH in mach64WriteMonoRGBAPixels_RGB565 followed by a lockup in mach64CopyBuffer once again. This appears to happpen right before swapping buffers via the DRM. The lockup isn't fatal, so I can ssh in, kill X and restart X from another box. ok, disregard this part, I think this was while still running without the locking on. So a couple of things: I disabled the color mask code in mach64_state.c (and checked it in), because I'm not sure that part is correct. Also, I tried setting HAVE_TEX0_VERTICES and HAVE_TEX1_VERTICES in _vb.c. I ran glxgears with locking and register writes enabled, but printf's for the register writes. The screen gets all messed up, but it's trying to draw. The last thing I saw in the terminal before a _hard_ lockup (reboot required) were reg. writes to the first vertex registers in the setup engine, and it was beginning on the second vertex (it's hard to tell exactly where it stopped because of buffering of the printf output). So I think we need to look at the vertex formats in the template code and the register programming in _tris.c and make sure we're giving the hardware the right data in the right format. -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: PIOlocking disabling
I've overcome this, but sursprisingly there is no further segfault. I see all the debuging statements scrolling in my terminal without stoping. This either means that the problem is at the locking mechanism or in the register programming in _tris.c. I'm really suspicious about the locking because when I first disabled the MMIO (since the driver doesn't really do PIO) and forgot about disabling the locking the my computer also hanged. How can this be? Since when the locking is overriden the computer doesn't hang this means that the problem must when locking. Any ideas? Later on I'm going to see if I can get another laptop from a friend of mine to make further debugging. José Fonseca On 2002.03.01 17:35 José Fonseca wrote: Have no idea. I'm still having troubles disabling the lock, because some of the state variables are set up when the card is locked (cliprects e.g.), so I'm getting segfaults due to this, and not the the _real_ problem yet. As soon as I overcome this and stumble into concrete problems I'll come back to you. Jose Fonseca On 2002.03.01 17:23 Leif Delgass wrote: OK, where was the lockup happening after you fixed the viewport problem? On Fri, 1 Mar 2002, José Fonseca wrote: I've disabled PIO and locking and I'm now running glxgears with gdb to catch all the segfaults. I commited so that we both can do the same thing. The patch is attached in case you need to reverse it. Regards, José Fonseca -- Leif Delgass http://www.retinalburn.net _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach64 debugging
Here's a bit more info on what I've found. I tried running a GL program of mine in gdb, and here's what happens: I turned off double buffering to see what's going on. The glClear calls the clear ioctl in the DRM and works, the window background is cleared to black (which is what the program specifies). The program has an array of normals, texcoords, and verts which is passes to glDrawArrays. The state is initially set to disable texturing and draw smooth shaded triangles. When I enter glDrawArrays, I see a series of register writes following by hardware state flushes. So many verts actually do complete, the problem is that stuff is getting drawn all over the screen, not in the glut window. Eventually it hangs up. I can ssh in, kill gdb do an xrefresh and all is well again. The hang happens in the same place if I'm double buffering, it locks up in DrawArrays before it gets to swap buffers. Any ideas? -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] GLperf and SPECviewperf
Anyone get these to compile with XFree86-4.2.0 and DRI? It's not finding GL includes, but I'm not sure where to change them, or where to point them. I have /usr/include/GL form glut-3.7 and /usr/X11R6/include/GL from XFree86. glut.h tries to include GL/gl.h but doesn't find it. Is gult wrong or is the Makefile just not getting the right paths? -Thomas ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
