[Mesa-dev] [PATCH 7/8] gallium: remove TGSI opcode SCS

[Roland Scheidegger]

Am 22.08.2017 um 16:38 schrieb Roland Scheidegger:
> Am 22.08.2017 um 15:17 schrieb Jose Fonseca:
>> On 22/08/17 12:28, Marek Olšák wrote:
>>> On Tue, Aug 22, 2017 at 1:10 PM, Jose Fonseca <jfonseca at vmware.com>
>>> wrote:
>>>> On 20/08/17 01:49, Marek Olšák wrote:
>>>>>
>>>>> From: Marek Olšák <marek.olsak at amd.com>
>>>>>
>>>>> use COS+SIN instead.
>>>>
>>>>
>>>> I don't know if any existing gallium driver leverages that, but it's
>>>> a basic
>>>> trigonometric principle that one can easily extract the sin from cos or
>>>> vice-versa.  It requires some extra care for getting the right sign. 
>>>> But
>>>> the fact is that it should be considerably cheaper to comput both
>>>> simultaneously than indepdently.
>>>>
>>>> Unfortunately GLSL/SPIR-V doesn't allow to express that.  D3D9/D3D11 and
>>>> Metal all do.  And from what I've seen from D3D9/D3D11 apps, 99% of the
>>>> times the shader wants both SIN/COS at the same time.
>>>>
>>>> If we want one opcode to rule them all, then a combined SIN+COS seems a
>>>> better choice IMO.  On SM4 the sincos has two outputs:
>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/hh447234.aspx but
>>>>
>>>> they are both optional to use.  I don't know if there's a precedent for
>>>> that.  I recall we had similar discussions about UMUL/UMUL_HI, and I
>>>> suspect
>>>> we chose not to go that route.
>>>>
>>>>
>>>> Don't GPUs allow to express the computation of both sin/cos with a
>>>> single
>>>> opcode?  If nothing else there would be a non-negligible impact of
>>>> leveraging this in llvmpipe at some point.  On the other hand, is
>>>> possible
>>>> that LLVM common-subexpression elimination optimization passes
>>>> already do
>>>> that, so we gain nothing.
>>>>
>>>>
>>>> In short, not big deal either way, but I think it's worth give it a 2nd
>>>> thought here.
>>>
>>> R300 doesn't have trigonometric functions. R500, R600 and later VLIW
>>> chips, and GCN all only have separate sin and cos.
>>>
>>> svga is the only driver that has sincos. No gallium hardware driver
>>> has that.
>>
>> I see.  Fair enough.  Considering that, plus the fact that GLSL doesn't
>> have conbined sin/cos, and that LLVM will most likely eliminate common
>> expressions generated by llvmpipe for cos/sin with same arg, there's
>> really not a significant upside left to justify keeping this around.
>>
>> FWIW the patch is
>>
>> Acked-by: Jose Fonseca <jfonseca at vmware.com>
>>
>> Jose
>>
> 
> FWIW old i965 chips had a SINCOS instruction, in addition to SIN and COS
> (those using the shared mathbox).
> However, even there the docs state for throughput "The two-output-phase
> SINCOS function is implemented as back to back SIN and COS functions."
> So it looks like the execution isn't actually faster there neither,
> albeit it would be faster due to only having to issue one send message.
> (But don't ask me how the chips actually implement this...)
> 

I forgot about this, but one reason for SCS also was that the
specification said the argument had to be in [-pi, pi] range (at least
GL spec said this, not really sure about d3d9). But if hw can't make use
of that in any case (and we didn't for llvmpipe neither) there's no point.

Roland