Alyssa Rosenzweig 59a3e12039 panfrost: do not push "true" UBOs
Panfrost supports pushing uniforms to hardware uniform registers (RMU/FAU for
Midgard/Bifrost respectively). Since OpenGL uniforms are lowered to UBO #0, it
does this with a pass that pushes UBOs. That's good!

The pass also pushes 'true' OpenGL UBOs, since they look the same in the backend
at this point. This is where the trouble comes in:

- True UBOs are allocated in GPU BOs, not CPU allocated buffers. That means it's
  write-combine memory, which we cannot read from efficiently (at least
  depending on coherency details that were never plumbed through panfrost.ko and
  unlikely to be replumbed now that panthor is the new hot stuff). So, pushing
  true UBOs reduces GPU overhead at the cost of tremendous CPU overhead. This is
  dubious... When I benchmarked this on MT8192 in early 2023, this pushing
  improved FPS in SuperTuxKart but hurt FPS in Dolphin.

- True UBOs can be written on the GPU. In OpenGL, we have batch tracking
  infrastructure to sort this mess out in theory. What this means is that
  pushing UBOs requires us to flush writers AND STALL at draw-time. If this is
  ever hit, our performance is utterly trashed. But it gets worse.

- True UBOs can be written in the same batch that reads them. For example, we
  could bind a buffer as a transform feedback buffer, do a draw with XFB, then
  rebind as a UBO and do a draw reading. This is where we collapse -- our logic
  will flush the writer, which is the same batch we were in the middle of
  enqueueing a draw to. When we try to push words, we'll crash with theatrics.
  This could be solved by smartening the batch tracking logic but it's not
  trivial by any means.

So, pushing true UBOs on the CPU is broken and can hurt performance. Stop doing
it!

Long term, the solution will be to push on the GPU instead. This avoids all of
these issues. This can be done with a compute kernel or with CSF instructions.
The Vulkan driver will likely have to do this for performance, since pushing
UBOs from the CPU is utterly broken in Vulkan for the above reasons.

I have a branch somewhere doing this on v9 but I'm doing this on NIR time to
unblock a core change that was crashing piglit due to this pile of unsoundness.
Let's fix the correctness issues first, then someone can look at recovering
performance later when we're not blocking unrelated work.

Fixes corruption in Piglit test
gles-3.0-transform-feedback-uniform-buffer-object, which writes a UBO with
transform feedback. (I suspect the test still doesn't pass for the same reason
it's broken on other tilers. But that's a better place to be than oodles of
memory corruption.)

According to CI, fixes spec@arb_uniform_buffer_object@rendering{-dsa}-offset.

Cc: mesa-stable
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34193>
2025-04-10 08:05:21 +00:00
2022-11-22 19:04:13 +00:00
2025-02-23 00:31:59 +01:00
2025-04-09 14:21:37 +00:00
2025-04-08 17:05:58 -04:00
2025-04-08 16:44:27 +00:00
2025-04-09 20:25:49 +00:00
2025-01-08 20:37:51 +00:00
2025-04-10 08:05:21 +00:00
2025-02-09 08:13:27 +00:00
2023-11-02 11:37:46 +00:00
2024-05-13 14:32:12 +00:00
2025-02-19 21:57:26 +00:00
2025-02-23 00:31:59 +01:00
2025-04-09 23:16:42 +00:00
2025-04-09 23:16:42 +00:00
2024-11-18 22:29:14 +00:00
2025-01-30 19:02:37 +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://docs.mesa3d.org/install.html>`_), but the recommended way is to use
Meson (`docs/meson.rst <https://docs.mesa3d.org/meson.html>`_):

.. code-block:: sh

  $ meson setup build
  $ ninja -C build/
  $ sudo ninja -C build/ 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://docs.mesa3d.org/bugs.html>`_).


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

Contributions are welcome, and step-by-step instructions can be found in our
documentation (`docs/submittingpatches.rst
<https://docs.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%