Timothy Arceri 34dffcf913 nir: add support for removing redundant stores to copy prop var
For example the following type of thing is seen in TCS from
a number of Vulkan and DXVK games:

	vec1 32 ssa_557 = deref_var &oPatch (shader_out float)
	vec1 32 ssa_558 = intrinsic load_deref (ssa_557) ()
	vec1 32 ssa_559 = deref_var &oPatch@42 (shader_out float)
	vec1 32 ssa_560 = intrinsic load_deref (ssa_559) ()
	vec1 32 ssa_561 = deref_var &oPatch@43 (shader_out float)
	vec1 32 ssa_562 = intrinsic load_deref (ssa_561) ()
	intrinsic store_deref (ssa_557, ssa_558) (1) /* wrmask=x */
	intrinsic store_deref (ssa_559, ssa_560) (1) /* wrmask=x */
	intrinsic store_deref (ssa_561, ssa_562) (1) /* wrmask=x */

No shader-db changes on i965 (SKL).

vkpipeline-db results RADV (VEGA):

Totals from affected shaders:
SGPRS: 7832 -> 7728 (-1.33 %)
VGPRS: 6476 -> 6740 (4.08 %)
Spilled SGPRs: 0 -> 0 (0.00 %)
Spilled VGPRs: 0 -> 0 (0.00 %)
Private memory VGPRs: 0 -> 0 (0.00 %)
Scratch size: 0 -> 0 (0.00 %) dwords per thread
Code Size: 469572 -> 456596 (-2.76 %) bytes
LDS: 0 -> 0 (0.00 %) blocks
Max Waves: 989 -> 960 (-2.93 %)
Wait states: 0 -> 0 (0.00 %)

The Max Waves and VGPRS changes here are misleading. What is
happening is a bunch of TCS outputs are being optimised away as
they are now recognised as unused. This results in more varyings
being compacted via nir_compact_varyings() which can result in
more register pressure when they are not packed in an optimal way.
This is an existing problem independent of this patch. I've run
some benchmarks and haven't noticed any performance regressions
in affected games.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
2018-11-13 15:19:36 +11:00
2018-11-12 13:22:54 +00:00
2018-10-31 19:15:50 +00:00
2016-08-30 16:44:00 -04:00
2017-09-06 17:48:50 +01:00
2018-11-01 00:05:43 +00:00
2018-11-12 13:29:00 -08:00
2018-08-16 13:52:56 -07:00
2018-11-01 18:54:02 +00:00

`Mesa <https://mesa3d.org>`_ - The 3D Graphics Library
======================================================


Source
------

This repository lives at https://gitlab.freedesktop.org/mesa/mesa.
Other repositories are likely forks, and code found there is not supported.


Build status
------------

Travis:

.. image:: https://travis-ci.org/mesa3d/mesa.svg?branch=master
    :target: https://travis-ci.org/mesa3d/mesa

Appveyor:

.. image:: https://img.shields.io/appveyor/ci/mesa3d/mesa.svg
    :target: https://ci.appveyor.com/project/mesa3d/mesa

Coverity:

.. image:: https://scan.coverity.com/projects/139/badge.svg?flat=1
    :target: https://scan.coverity.com/projects/mesa


Build & install
---------------

You can find more information in our documentation (`docs/install.html
<https://mesa3d.org/install.html>`_), but the recommended way is to use
Meson (`docs/meson.html <https://mesa3d.org/meson.html>`_):

.. code-block:: sh

  $ mkdir build
  $ cd build
  $ meson ..
  $ sudo ninja install


Support
-------

Many Mesa devs hang on IRC; if you're not sure which channel is
appropriate, you should ask your question on `Freenode's #dri-devel
<irc://chat.freenode.net#dri-devel>`_, someone will redirect you if
necessary.
Remember that not everyone is in the same timezone as you, so it might
take a while before someone qualified sees your question.
To figure out who you're talking to, or which nick to ping for your
question, check out `Who's Who on IRC
<https://dri.freedesktop.org/wiki/WhosWho/>`_.

The next best option is to ask your question in an email to the
mailing lists: `mesa-dev\@lists.freedesktop.org
<https://lists.freedesktop.org/mailman/listinfo/mesa-dev>`_


Bug reports
-----------

If you think something isn't working properly, please file a bug report
(`docs/bugs.html <https://mesa3d.org/bugs.html>`_).


Contributing
------------

Contributions are welcome, and step-by-step instructions can be found in our
documentation (`docs/submittingpatches.html
<https://mesa3d.org/submittingpatches.html>`_).

Note that Mesa uses email mailing-lists for patches submission, review and
discussions.
S
Description
No description provided
Readme 538 MiB
Languages
C 75.5%
C++ 17.2%
Python 2.7%
Rust 1.8%
Assembly 1.5%
Other 1%