On Tue, 2010-08-17 at 13:16 -0700, Luca Barbieri wrote: > > Using a flag instead of a new texture target allows to avoid hundreds of > > changes to existing code, and allows drivers for modern hardware to > > just ignore this flag. > I grepped a bit through the code, and a new texture target seems > easier than expected: apparently there are only about 36 checks for > PIPE_TEXTURE_2D (grepping for > ([!=]=.*PIPE_TEXTURE_2D|PIPE_TEXTURE_2D.*[!=]=|case.*PIPE_TEXTURE_2D)). > > It's still going to be more intrusive than a flag that almost > everything just ignores (and with much greater risk of introducing > bugs), but it could perhaps be an option, if the consensus is to add a > new target.
A new texture target is much less surprising than any of these other suggestions. GL describes this behaviour as a texture target and its meaning is well understood. I think modifying 36 usages is pretty manageable, it's a one time cost and keeps gallium within a set of concepts with which people are already familiar. I appreciate all the work you've put into looking at alternatives, but at this stage I'm going to be firm - if PIPE_TEXTURE_RECT can be made to work, that's the direction we should be taking. I haven't seen anything so far that suggests it isn't a feasible approach. So if that's ok, let's start from a minimal suggestion and really try to avoid letting complexity creep into the interface design. What about this for a starting poing: - PIPE_TEXTURE_RECT texture target, following GL semantics - PIPE_CAP_TEXTURE_2D_NPOT (nv30 should not advertise this) Is there anything more you actually require right now? Keith _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
