Kenneth Graunke 9d8f2c4421 intel/brw: Rework BRW_REGISTER_TYPE's representation semantics
In ancient days, we directly used the hardware register type encodings
throughout the compiler.  As more GPU generations came out, encodings
shifted, and we moved to an abstract enum that we could encode/decode
to a particular GPU's hardware encoding.  But there was no particular
meaning behind any particular value.

One downside to this approach is that we end up with switch statements
galore.  Want to know a type's size?  Switch.  Convert a unsigned type
to a signed one?  Switch.  Get a type with the same base type, but
different bit size?  Switch.  This is both inefficient and inconvenient.

In contrast, nir_alu_type takes a nicer approach - the type encoding has
certain bits representing the base type, and others encoding the size of
the type.  Switching base types or sizes is a simple matter of masking
out the relevant field and substituting a different one.

Tigerlake's encoding adopts a similar approach: two bits represent the
size as a 2-bit unsigned number n, where the bit size is (8 * 2^n).
Two more bits represent the base type.  Past encodings were a bit ad hoc
as new data types were added over time, but Gfx12 is organized (mostly).

This patch converts our brw_reg_type enum over to a new system that's
patterned after the Tigerlake style (for easy conversion) while
deviating in a few ways that make our vector immediate type size
handling simpler.  Should we add additional base types, we're likely
to continue deviating.  Still, converting is much simpler.

Type size calculations (which are performed all the time) are now a
simple mask and shift, instead of a switch.

We also adopt the name BRW_TYPE_* instead of BRW_REGISTER_TYPE_* because
it's much shorter and easier to type.  Similarly, we create new helper
functions named brw_type_* for working with these types, with a cleaner
naming convention.  Legacy names still exist but will we dropped over
the next few patches as pieces get cleaned up.

Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
2024-04-25 11:41:48 +00:00
2024-04-17 01:23:25 +00:00
2022-11-22 19:04:13 +00:00
2024-03-13 15:21:07 +00:00
2024-04-24 18:06:04 +00:00
2024-04-08 20:28:43 +00:00
2024-01-24 10:02:10 +00:00
2023-11-02 11:37:46 +00:00
2024-01-24 10:53:14 +00:00
2024-04-23 18:31:39 +00:00
2024-04-23 18:31:39 +00:00
2024-04-24 19:51:59 +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 & install
---------------

You can find more information in our documentation (`docs/install.rst
<https://mesa3d.org/install.html>`_), but the recommended way is to use
Meson (`docs/meson.rst <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 `OFTC's #dri-devel
<irc://irc.oftc.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.rst <https://mesa3d.org/bugs.html>`_).


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

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

Note that Mesa uses gitlab 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%