<div class="gmail_quote">On Wed, Jul 28, 2010 at 7:25 AM, Zack Rusin <span dir="ltr"><<a href="mailto:zackr@vmware.com">zackr@vmware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Tuesday 27 July 2010 23:57:17 Jakob Bornecrantz wrote:<br>
> First off, the Core TGSI instruction set includes a lot of<br>
> instructions that not necessary all hardware can handle foremost off<br>
> these are DDX and DDY which should either be moved to the GLSL cap or<br>
> get a cap of its own. Related to this is IF and friends, tho this can<br>
> be handled by a compiler or optimizer but sometimes this might be<br>
> better to tell the higher levels about it so maybe a cap or some sort<br>
> of cap hint? And while on branching instructions the CAL and RET<br>
> opcodes could also do with the same treatment.<br>
<br>
</div>We already have PIPE_CAP_GLSL. Or are you saying that you'd like to keep<br>
support for GLSL but not for those features? Personally I don't think that<br>
would make a lot of sense (you'll never be able to pass actual conformance on<br>
anything like that).<br></blockquote><div><br>Going from GL2.1 to GL1.5 just because some hardware can't do ddx and ddy seems a bit silly to me.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
> Something that came up while planning for the tgsi optimizer and I'm<br>
> currently ignoring is source indirection (not texture). Indirection in<br>
> general isn't all that well explained in the documentation and I'm<br>
> wondering if it is available on all hardware or if it should be<br>
> protected be a cap. It is particularly challenging for the optimizer<br>
> if used to indirect a temporary read, since basically you then have to<br>
> treat all temporaries at that point as a array and it thus makes it a<br>
> lot harder to reshuffle and reallocate temporaries in such a shader.<br>
<br>
</div>Gallium already supports a feature which fixes it - indexable temporary arrays<br>
(TEMPX register file). Mesa's state tracker just doesn't use it yet.<br>
<div class="im"><br>
> Going on there is a bunch of opcodes in core that are considered for<br>
> removal, most of them are never used by the state trackers or<br>
> implemented by any driver.<br>
<br>
</div>TBH I don't think we have many (if any) opcodes anymore that we should be<br>
removing. TGSI is a bit different than the rest of Gallium - it's supposed to<br>
be a super-set of shader opcodes or more precisely be as expressive as<br>
possible to get the optimal translation from the original language. Besides<br>
the pack instructions that rest is actually very useful (and the ARL/ARR are<br>
absolutely mandatory, they're not at all like FLR/ROUND, since those are the<br>
only instructions that we allow to write to the address register)<br></blockquote><div><br></div></div>PS3.0 doesn't have address regs, that means there are no ARL/ARR/ARA opcodes. Are you sure these must be mandatory? Please see:<br>
<a href="http://msdn.microsoft.com/en-us/library/bb172920%28VS.85%29.aspx">http://msdn.microsoft.com/en-us/library/bb172920%28VS.85%29.aspx</a><br><br>PUSHA, POPA, and pack/unpack opcodes are not in SM3.0 either.<br><br>
Cheers.<br>
<br>-Marek<br>