Tilman Sauerbeck wrote: > Roland Scheidegger [2006-05-30 22:33]: > >>Tilman Sauerbeck wrote: >> >>>I finally ran glean today, and noticed that SWZ wasn't implemented >>>properly for r300 ARB vertex programs. >>> >>>So far I didn't handle per-component negation flags, the attached patch >>>adds that. >>> >>>Question: is it okay to assume that "NegateBase" in >>>struct prog_src_register will always be filled the way it's filled >>>currently? ie that the sign for the x component is at bit 0 etc. >> >>I'd guess that's ok. Whoever wants to change it needs to make sure that >>the code wherever it's used still works. Such things can get forgotten >>though, but in that case someone will notice and fix it up then :-). > > > Mmh, alright :) > > >>>If it doesn't, the patch I attached obviously wouldn't work... >>> >>>If there are no objections, I'll commit this in a few days. >> >>Wouldn't it be simpler to just change t_src to always apply >>src->NegateBase? I can't see a need for that "src->NegateBase ? >>VSF_FLAG_ALL : VSF_FLAG_NONE", as the mesa parser sets all 4 bits anyway >>when "normal" instructions are parsed. The code would both be smaller >>and faster :-). (t_src_scalar OTOH cannot be changed.) > > > That won't work for NV vertex programs. nvvertparse.c sets NegateBase to > either GL_TRUE or GL_FALSE. > > If they'd use 0xf (== VSF_FLAG_ALL) and 0x0 as NV fp and ARB vp/fp do, > it would work indeed :) > Maybe nvvertparse.c should be changed? Setting a GLuint bitfield to > GL_TRUE seems a bit weird :)
Good catch. The NegateBase field is meant to per-component. I'll fix the nvverparse.c code. The only instruction which can arbitrarily set individual bits of NegateBase is SWZ. For all other instructions, all four bits will either be set or cleared. -Brian -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
