On 06/04/06, Brian Paul <[EMAIL PROTECTED]> wrote: > > I think the arbitrary-length bitset type is overkill. We really just > need a 64-bit bitfield for the foreseeable future, right? > > These macros in bitset.h are pretty "heavy" if all the bitsets are > just 64 bits or less. > [...] > > The code would be far more efficient this way. What do you think? > > I still need to review the rest of the patch in more detail. Maybe > this evening - I've got other things I need to work on. >
The specialization given above is okay, but to make it future proof, I would suggest the following. 1) Leave the generic bitset macros as they are. 2) Suffix 64-bit versions with "64", e.g. BITSET64_COPY. 3) In "t_context.h", where DECLARE_RENDER_INPUTS is declared, also define macro names for operations, not just declarations, e.g. #define RENDERINPUTS_COPY(x,y) BITSET64_COPY(x,y) ... and then use them in drivers and mesa core, in place of BITSET_* as it is now, in the patch. This way we can do transition to, say, 128-bit flags without touching drivers. Also, this reduces the overall burden, when more bit-fields will need multi-word handling. This will happen to swrast, when more than 64 varyings are needed. For now, I just need a confirmation that my changes will not break compilation of drivers. Then I can safely apply your proposals in my next cvs commit. -- Pozdrawiam, Michal Krol ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
