Roland Scheidegger
0064baeaa5
We are using different llvm type depending on the cpu supporting f16c instructions or not. The reasoning behind this was that we really couldn't do anything with f16 values and had to cast them to some int type anyway, plus IIRC originally this actually predates llvm even supporting a half type in the first place (or if it did, at the very least it was not able to do anything useful with it). There are now bugs with lavapipe when the cpu doesn't support f16c, since while we don't expose f16 capabilities in this case, we can still hit f16 conversion functions for the likes of unpack2x16float and quantizeToF16, and we're just straight calling fpext/fptrunc functions, not touching our own code for half conversion (I believe our own code might still be faster as llvm de-vectorizes it if it's not supported by the cpu, but don't quote me on that - could depend on llvm version, and also for trunc the rounding is actually different since our own functions implement rounding according to d3d10 requirements (mostly used for f16 render targets)). This only seems to be a problem for vulkan, not GL, since glsl has its own lowering pass if the half float packing instructions aren't supported by the driver. Ideally we'd fix this by just always using llvm half type for f16, however still not all llvm backends can handle it. So instead do some hacky bitcasts around the fpext/fptrunc calls with f16, which works on x86 even when not supporting f16c. Other llvm backends not really supporting halfs will still crash there as before (albeit it should be a "cleaner" crash as the IR is now correct...), but at least keeps them running for more ordinary things such as f16 texture sampling / render targets (which they wouldn't if we'd use llvm half type everywhere). Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13807 Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13865 Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37344>
`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.