On Tue, 2010-03-02 at 04:36 -0800, Luca Barbieri wrote:
> >> The correct value in this case seems to be 219 = 14 * 16 SM3 semantics > >> - 5 for COLOR0, COLOR1, PSIZE0, POSITION0, FOG0 which have specific > >> TGSI semantics which they need to mapped to/from. > > > > Agree, though I'd opt for 255 as a round number. > > The problem with this is that you only have 14 SM3 semantics with 16 > indices each, so you can't map 256 generic indices into the VMware > interface, or directly into an SM3 shader. > You only have 14 * 16 minus the ones used for non-GENERIC semantics > (the one mentioned above). > And of course, if you choose a smaller number, you can't map SM3 > _into_ Gallium, so you need to choose the exact number required for > SM3. > > Tying Gallium in this way to SM3 is surely a bit ugly, but it's just a > constant, and I don't see any other way to implement SM3 without doing > linkage in software in the r600 and svga drivers and/or in SM3 state > trackers. I accept that it can be viewed as an arbitrary constant, but maybe it's a step too far. If another API or piece of hardware came along that we decided was important, the calculations might change and we'd be stuck. I see our options as: a) Picking a lower number like 128, that an SM3 state tracker could usually be able to directly translate incoming semantics into, but which would force it to renumber under rare circumstances. This would make life easier for the open drivers at the expense of the closed code. b) Picking 256 to make life easier for some closed-source SM3 state tracker, but harder for open drivers. c) Picking 219 (or some other magic number) that happens to work with the current set of constraints, but makes gallium fragile in the face of new constraints. d) Abandoning the current gallium linkage rules and coming up with something new, for instance forcing the state trackers to renumber always and making life trivial for the drivers... I suspect we'll end up reworking the whole GENERIC idea at some stage, ie (d). But for now, I don't think that some piece of closed code should be dictating the gallium interface direction, so I'd suggest something that makes the open driver's lives easier -- ie (a) or (c). To be honest, I'd suggest keeping a modicum of independence in gallium plus making the open code simpler, and going with 128... But if you feel strongly, I don't mind the bigger number (219) either, except on aesthetic grounds... Keith ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
