I think Roland's patch can't cope with more than two texture units. As I experimented with this while I had Andreas Stenglein's 3TMU patch applied some of the time I decided to make something that can handle a variable number of texture units. Since the number of texture units is going to be configurable this will be a good thing even after Andreas' patch is committed. On r200 this affects the tex, cube and mat arrays. See the radeon driver for details.
Regards, Felix On Fri, 09 Jan 2004 09:27:59 +0000 Keith Whitwell <[EMAIL PROTECTED]> wrote: > Roland Scheidegger wrote: > > Based on the idea of Felix Kühling that the order in which state atoms > > are emitted might be important on the radeon, I thought maybe it might > > be important on the r200 as well, even though there are no lockups. > > With the attached patch indeed the random color flashings seem to be > > gone (at least in specviewperf 7.1 and nwn - note that the lighting in > > nwn is still hosed in some areas completely, but it no longer flickers). > > > > The emit order of the atoms in this patch is just a guess. I've just > > tried to figure out an order which looked somehow logical, i.e. the > > stuff which MIGHT need some other state applied first is submitted last, > > not sure if it really makes sense - but it worked on the second try (as > > first try I have just used the order the state atoms are defined in > > r200_context.h, this only changed the flickering but didn't eliminate it). > > > > I've also disabled the isosurf workaround, this likely wouldn't do > > anything useful now. Though I'm not sure what exactly this did correct, > > isosurf looked just the same with or without that workaround here. (btw > > isosurf still looks wrong, in POLYGON_MODE_FILL and REFLECT the > > reflection has a completely wrong color pattern - it looks almost as it > > is reversed if you compare it with software mesa (I've just used > > LIBGL_ALWAYS_INDIRECT=1), though interestingly in POLYGON_MODE_LINE the > > reflection color pattern looks ok. But it's the same with or without > > this patch.) > > > > I've no idea if the order is really important or if this just hides > > another problem, maybe someone with databooks could answer that. > > It seems odd that order is important, but in the interests of repeatibility of > bugs and narrowing the range of hidden behaviours in the driver which could > mask bugs, I think moving to a fixed ordering of state emits is probably a > positive step. > > The patch looks fine to me, however I did get this error applying: > > > $ patch < /home/progs/r200_changeemitorder.diff > patching file r200_cmdbuf.c > patching file r200_context.h > patch unexpectedly ends in middle of line > Hunk #1 succeeded at 187 with fuzz 1. > > > In general it makes me more confident if patches are well-formed... It looks > fine though & I've committed the change. > > > > Keith > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > -- > _______________________________________________ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > ------------ __\|/__ ___ ___ ------------------------- Felix ___\_e -_/___/ __\___/ __\_____ You can do anything, Kühling (_____\Ä/____/ /_____/ /________) just not everything [EMAIL PROTECTED] \___/ \___/ U at the same time. ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
