[Mesa-dev] Removing unused opcodes (TGSI, Mesa IR)

Jose Fonseca jfonseca at vmware.com
Thu Nov 13 12:03:31 PST 2014


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: ibmirkin at gmail.com <ibmirkin at gmail.com> on behalf of Ilia Mirkin <imirkin at alum.mit.edu>
Sent: 13 November 2014 17:13
To: Marek Olšák
Cc: Jose Fonseca; Eric Anholt; mesa-dev at 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 <maraeo at gmail.com> wrote:
> Nine can lower ARR into ROUND+ARL easily.
>
> Marek
>
> On Thu, Nov 13, 2014 at 3:33 PM, Jose Fonseca <jfonseca at 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-bounces at lists.freedesktop.org> on behalf of Eric Anholt <eric at anholt.net>
>> Sent: 13 November 2014 01:43
>> To: Ilia Mirkin
>> Cc: mesa-dev at lists.freedesktop.org
>> Subject: Re: [Mesa-dev] Removing unused opcodes (TGSI, Mesa IR)
>>
>> Ilia Mirkin <imirkin at 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 at 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=


More information about the mesa-dev mailing list