From: F. <j_r...@ya...> - 2002-03-08 15:19:56
|
Good news indeed! I'll start looking into these problems you reported as well. One thing that I plan to do is to understand and review all these state changes. There are so many different flags (and hacks) that makes it very difficult to know by which order things get updated. José Fonseca On 2002.03.08 06:34 Leif Delgass wrote: > 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 <lde...@re...> > To: José Fonseca <j_r...@ya...> > Cc: dri...@li... > 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. > > ... > > -- > Leif Delgass > http://www.retinalburn.net > |