Initially TGSI used to be an union of all possible opcodes (NV/ARB fp/vp, Mesa
IR, D3D Shader Model 1.x, 2.x, more recently D3D10).
But in practice it's just too much of a hassle, and many of the opcodes were
never handled or generated. Many received little to no testing.
Particularly when implementing drivers for modern hardware that doesn't have
opcodes to match with the Shader Model 1.x and 2.x quirky semantics, they are
distractions. Furthermore the apps who used to generate them are simple by
nowadays standards and run fine on fast modern hardware.
By having a smaller set of opcodes they can be tested more easily, so one can
have more confidence that they do actually work as intended; and developing
analysis/optimization/transformation passes becomes easier too.
But I have no definite answer on which should or not be in TGSI. D3D10/11
assembly is not a bad reference, but it has some omissions It's a matter of
deciding on case by case..
Jose
________________________________________
From: ibmir...@gmail.com <ibmir...@gmail.com> on behalf of Ilia Mirkin
<imir...@alum.mit.edu>
Sent: 13 November 2014 17:13
To: Marek Olšák
Cc: Jose Fonseca; Eric Anholt; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] Removing unused opcodes (TGSI, Mesa IR)
As long as we have NAND, pretty much anything can be lowered to
that... I am, of course, not advocating keeping around every insane
instruction, but it does seem a bit arbitrary as to which ones we have
and which ones we don't... I am personally guilty of adding a bunch,
and it was never clear to me how much should be left to the backend
optimizer to un-lower and how much should be done as separate
instructions.
My take was that as long there was a state tracker providing it as
input, it made sense to keep the instruction. But perhaps there's a
different policy that'd work better.
Cheers,
-ilia
On Thu, Nov 13, 2014 at 11:40 AM, Marek Olšák <mar...@gmail.com> wrote:
> Nine can lower ARR into ROUND+ARL easily.
>
> Marek
>
> On Thu, Nov 13, 2014 at 3:33 PM, Jose Fonseca <jfons...@vmware.com> wrote:
>> It looks like ARR is generated, as
>> src/gallium/state_trackers/nine/nine_shader.c has
>>
>> #define _OPI(o,t,vv1,vv2,pv1,pv2,d,s,h) \
>> { D3DSIO_##o, TGSI_OPCODE_##t, { vv1, vv2 }, { pv1, pv2, }, d, s, h }
>>
>> [...]
>>
>> _OPI(MOVA, ARR, V(2,0), V(3,0), V(0,0), V(0,0), 1, 1, NULL),
>>
>>
>> Jose
>>
>> ________________________________________
>> From: mesa-dev <mesa-dev-boun...@lists.freedesktop.org> on behalf of Eric
>> Anholt <e...@anholt.net>
>> Sent: 13 November 2014 01:43
>> To: Ilia Mirkin
>> Cc: mesa-dev@lists.freedesktop.org
>> Subject: Re: [Mesa-dev] Removing unused opcodes (TGSI, Mesa IR)
>>
>> Ilia Mirkin <imir...@alum.mit.edu> writes:
>>
>>> AFAIK at least some of these (NRM, ARR, probably others) were being used by
>>> the d3d9 state tracker. Not sure what its status is, but I believe the hope
>>> was to eventually get it into the tree.
>>
>> They've got code for lowering NRM and CND to sanity, and no use of ARR,
>> ARA, X2D, RFL, STR, SFL, or BRA.
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AAIFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=j854NOxlaV5nq8kWcima4dP_7hhtaOc2Uj1eJJzZOUM&s=51MpEXASrETyaVvEjR8y1V-NPHxlTTfeHhX4Bb8TgKE&e=
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
