----- Original Message ----- > > Sorry to hear the hw doesn't support it, but this is supported by d3d10 > > so it's quite likely some hw indeed supports it. There's always some > > things some hw can't do natively. > > Well I was hoping before adding new things for sw driver to gallium we > should confirm if it > makes sense for hw.
I think that's what we've been doing all along. Integer modified support was posted for review, and at the time you made the observation that R600 didn't supported, http://lists.freedesktop.org/archives/mesa-dev/2013-February/034639.html , but it didn't sound like you objected, and nobody else came forward weighing in one way or the other. If we did a bad decision we can always revert it, but it's not like we are carrying our agenda without taking in consideration other opinions. D3D10 is an abstraction that many HW vendors follow closely, so sticking with it when it doubt is IMO a good rule of thumb. > > I'd be fine to just restrict it to some opcodes, e.g. exclude logic ops > > if that helps you. Note that tgsi (and d3d10 for that matter) also for > > instance don't have a integer SUB opcode, so the natural way for > > encoding that would of course just be with a ADD with negate modifier on > > second arg, and I bet your hw could do that one. > > Nope, all r600 hw has SUB_INT. The negate bit is always specified to > only operate > on float instructions. If we decide to forhibid integer modifiers, then maybe we should have an ISUB. Anyway, I don't feel too strongly about integer modifiers either way. If no hardware supports it natively, then I'm fine passing on the responsibility to the state tracker. It would be nice to know what other HW besides R600 does. But when in doubt, sticking with existing abstractions, or leaning towards the most generic representation, are IMO good rules of thumb. Even a very dumb TGSI translator can easily handle the negative integer modifier by emiting an auxiliary instruciton, where as the opposite -- combine and INEG with other operations -- requires more complex optimization passes. Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
