9d8f2c442120c98532dac8e5055c06efe0942c5f
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>
`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.
Description
Languages
C
75.5%
C++
17.2%
Python
2.7%
Rust
1.8%
Assembly
1.5%
Other
1%