Created attachment 226612 [details] Screenshot showing heavy image corruption from the video player "mpv" FreeBSD shows heavy artifacting and texture corruption on i915 hardware with mesa's new Gallium3D driver "Crocus". This issue is tracked as a mesa issue here: "Crocus on GM45: texture corruption, bad memory reads and GPU Hangs" ( https://gitlab.freedesktop.org/mesa/mesa/-/issues/5093 ) It has been suggested by a mesa dev, that the cause may be on FreeBSD's side due to "missing some interfaces [...]". That's why I cross-post this as a bug here. TL;DR: With a Laptop with a GM45 chipset, the GMA 4500 MHD iGPU, on the latest kernel, with the latest drm-fbsd13-kmod and the latest mesa-devel, using crocus as the graphics driver to launch any graphical program results in heavy artifacting when a texture is displayed. Attached is a screenshot of the videoplayer "MPV", which shows heavy corruption of the image. Be it Video game or browser, everything shows this corruption, if crocus is used.
Can you reproduce the issue with the lastes non-devel mesa version?
(In reply to Niclas Zeising from comment #1) Neither mesa-dri nor mesa-libs, from pkg or ports deliver Mesa 21.2, which is the version where crocus is supplied. So it is not possible to compare. pkg latest gives version 20.2.3 and ports gives 21.1.5. Only mesa-devel is up-to-date to the latest mesa git master and builds crocus by default. (Big-ups to the maintainer btw, that is some exellent work)
So this is a problem with a non-default non-release version of mesa?
(In reply to Niclas Zeising from comment #3) Well... soon to be default replacement 3D-Driver from Gen4 to haswell iGPUs. But yes, as of right now it concerns a non-default driver and Mesa 21.2 is on it's second release candidate and thus technically non-released.
We do want to move to mesa 21.2 when it is released, so I think you should work with upstream and Jan to see if you can figure out what is going on here. We may not necessarily be able to or need to support crocus with the initial ports bump, Hopefully we'll be able to see how other *nix distributions handle this as well for inspiration, there are some changes that will affect packagers like the 'amber' LTS release which will allow the legacy drivers to be used for compatibility like this.
So it seems that this was resolved upstream. For the other problem that you're seeing it could also still be problem upstream. So I'm closing this PR now and if you find that this is a problem specific to FreeBSD please open a new PR.