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

Ilia Mirkin imirkin at alum.mit.edu
Wed Nov 19 13:17:01 PST 2014

On Wed, Nov 19, 2014 at 3:45 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
> On 19/11/14 19:45, Ilia Mirkin wrote:
>> On Wed, Nov 19, 2014 at 2:32 PM, Eric Anholt <eric at anholt.net> wrote:
>>> Eric Anholt <eric at anholt.net> writes:
>>>> This series removes a bunch of unused opcodes, mostly from TGSI.  It
>>>> doesn't go as far as we could possibly go -- while I welcome discussion
>>>> for future patch series deleting more, I hope that discussion doesn't
>>>> derail the review process for these changes.
>>>> I haven't messed with the subroutine stuff, since I don't know what
>>>> people
>>>> are planning with that.  I also haven't messed with the pack/unpack
>>>> opcodes in TGSI, since they might be useful for some of the GLSL packing
>>>> stuff.
>>>> Testing status: compile-tested ilo/r600/softpipe, touch-tested softpipe.
>>> Lots of "looks good", no Reviewed-by (other than Ian on the Mesa side).
>>> I'm probably going to push soon anyway if somebody doesn't actually give
>>> Reviewed-by or NAK.
>> st/nine got merged. It uses ARR. And at the very least references
>> TGSI_OPCODE_NRM even if it doesn't use it. It also has code that uses
>> CND and DP2A although it's presently disabled via #define's.
> The patch attached should do it.
>> I'm pretty sure that your series will cause st/nine to fail compiling.
> BTW, given it's not trivial to compile nine state-tracker, I think it might
> be better to not obfuscate which opcodes or symbols it uses with macros.  It
> pays off to be upfront with these things, so that `git grep foo` finds
> everything that should be found.

Hmmm... why is it not easy to build st/nine? I haven't looked at that
in detail yet, but whatever's hard about it should get fixed. [Not
Eric's problem, of course.]

More information about the mesa-dev mailing list