Well, you were right. I had added the code to set mmesa->multitex to mach64ChooseVertex for lack of a better place, so that bit's my fault ;). Well, the better place is in mach64UpdateTextureState, so I moved it there. Multiarb works now (at last!).
Ok, so we still have some problems with textures though. The Mesa mipmap demo doesn't draw anything (other than the background clear). I noticed that some of the texture coords show up as not-a-number, so there are still some issues with the vb template, most likely. I tried quake and some of the textures show up and some don't. Another issue that I've noticed (with the old driver too) is that texture fallbacks with single-buffering have problems where old textures show through. -- Leif Delgass http://www.retinalburn.net ---------- Forwarded message ---------- Date: Thu, 7 Mar 2002 22:40:14 -0500 (EST) From: Leif Delgass <[EMAIL PROTECTED]> To: José Fonseca <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: [Dri-devel] Re: mach64 mulltiarb I'll try to take a look at when multitex is set. I did find a problem that I committed a fix for. When stepping through multiarb, I noticed that when UpdateTexUnit is called for unit=1, SetTexImages was being passed the texture object bound to unit 0. Turns out that the mmesa->tmu_source[] wasn't being set. This was preventing the second texture from being uploaded. So now the second texture gets uploaded, but I'm still getting a lockup. I'm looking into the locking issues and I have some ideas, I let you know if I turn anything up. On Fri, 8 Mar 2002, José Fonseca wrote: > Leif, > > After some debugging it seems I was right: the texture unit isn't being > updated for enabling multitexturing before drawing the primitives. > > In case you want to reproduce do the following: > > gdb multiarb > run > (on my laptop there is an math exception because there is no SSE2 > so I grab the opportunity mach64.so is loaded to make some breakpoints) > break mach64ChooseVertex > break mach64_texstate.c:410 > break mach64_draw_quad > continue > continue > ... > ... > > (when it gets in mach64_draw_quad quite unless you want experience > the lock) > quit > > > For the mach64_draw_quad breakpoint to work you have to disable the inline > function expansion: > > --- mach64_tris.c 6 Mar 2002 03:07:05 -0000 1.1.6.8 > +++ mach64_tris.c 8 Mar 2002 01:30:00 -0000 > @@ -116,7 +116,7 @@ > COPY_DWORDS( j, vb, vertsize, v2 ); > } > #else > -static __inline void mach64_draw_quad( mach64ContextPtr mmesa, > +/*static __inline*/ void mach64_draw_quad( mach64ContextPtr mmesa, > mach64VertexPtr v0, > mach64VertexPtr v1, > mach64VertexPtr v2, > > You'll see that mach64UpdateTextureUnit is not being called between the > ChooseVertex sets multitex to 1 and _draw_quad. > > Why and how to fix I still didn't look figured it out (I'm going now to > bed, but I wanted to let you know before that). > > BTW, I've stopped trying to enable the PCI thing. I just made a fresh > checkout because I was wasting too much time and wasn't getting nowhere > since the X didn't even started properly. When I get some more time I try > to repeat the changes incrementally to see whats's breaking. > > Regards, > > José Fonseca > > PS: It's sad to know that mipmapping is really broken, but it was nice > that you made that check on windows, so that now we can focus on more > important things. > -- Leif Delgass http://www.retinalburn.net _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
