Bug#1006202:
I second this. Intel Gen 2 (Extreme Graphics) for example are now without hardware OpenGL. Also see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034571 -- The Gallium implementation for Intel (Crocus) does not have the same stability as the old i915 driver yet, in my opinion.
Bug#1034571: Temporary solution
For those interested in a temporary, botched, solution, here is a script (run as root): #!/usr/bin/env bash set -e mkdir -p "/tmp/i965" mkdir -p "/usr/lib/i386-linux-gnu" mkdir -p "/usr/lib/x86_64-linux-gnu" curl "http://ftp.us.debian.org/debian/pool/main/m/mesa/libgl1-mesa-dri_20.3.5-1_i386.deb; | dpkg-deb -x - "/tmp/i965" cp "/tmp/i965/usr/lib/i386-linux-gnu/dri/i915_dri.so" "/usr/lib/i386-linux-gnu/dri/i965_dri.so" curl "http://ftp.us.debian.org/debian/pool/main/m/mesa/libgl1-mesa-dri_20.3.5-1_amd64.deb; | dpkg-deb -x - "/tmp/i965" cp "/tmp/i965/usr/lib/x86_64-linux-gnu/dri/i915_dri.so" "/usr/lib/x86_64-linux-gnu/dri/i965_dri.so" rm -rf "/tmp/i965" This will install the old i915 driver, with i965 support. To use it, do 'MESA_LOADER_DRIVER_OVERRIDE=i965 your-application'.
Bug#1034571: Gallium unstable on Gen 5 (likely also Gen 4), need legacy driver
Package: libgl1-mesa-dri Version: 22.3.6-1+deb12u1 Severity: important I think the Gallium driver for older Intel graphics is a bit undercooked, and should not be considered a silver bullet (stable) yet. I've been experiencing issues with WineD3D, like flickering, bad performance and application crashing that I didn't have before. Wine Nine did not help my situation. When I've curiously tried these drivers on another distro before (this was year or two ago, when this driver was experimental), I was able to use MESA_LOADER_DRIVER_OVERRIDE=i965, to fall back to the legacy driver. However this isn't possible on Debian: > libGL error: MESA-LOADER: failed to open i965: /usr/lib/dri/i965_dri.so: > cannot open shared object file: No such file or directory (search paths > /usr/lib/i386-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri) > libGL error: failed to load driver: i965 I've tried 'apt-file search i965_dri.so', but it gave me no result. I think this driver should be shipped with Debian, and perhaps (?) even be preferred over Gallium for Gen 5 and probably Gen 4. The Gallium driver just didn't have the years upon years of fixings that the i965 driver had. I suspect i965 is part of mesa-amber now.
Bug#973414: rustc: produces non-baseline opcodes for compiler_builtins::int::udiv::__udivmoddi4 on i386
* In terms of efficiency: I believe that if people are on the hunt for efficiency on CPUs at the top-end of x86, they shall use distros that target Pentium 4 explicitly. There are a few of them out there, now. Archlinux32 for example carries packages for i486, i686 and Pentium 4 where possible, and lets you enable the architectures that suit you best. * In terms of confusion: I think using the Rust i586 toolchain, and building for i586 with Rust might be less confusing, because altering the i686 definitions for rustc will make it act differently compared to other platforms. People could compile code for i686 on Debian, get working code, but then if someone else does the same on another distro, the produced binary would not work on the same devices. Although, I think changing the i686 definition down, like you did, is the most accurate way to achieve the goal, and is what I personally think should be mainline. If the accurate definition proves itself on Debian, it might find itself in mainline Rust, too, which would be awesome. Thank you for your continued interest in this topic.
Bug#973414: rustc: produces non-baseline opcodes for compiler_builtins::int::udiv::__udivmoddi4 on i386
@jay - I hope this helps you: - issue 1: i386, i486, i586, i686 are considered as Pentium 4 in LLVM, which might be relevant if Rust is compiled with it: https://github.com/llvm/llvm-project/issues/61347 - issue 2: Rust considers i686 as Pentium 4, and i586 as Pentium: https://github.com/rust-lang/rust/issues/82435 So, what I'm thinking is: - When building the Rust toolchain itself, if Debian uses LLVM for it, it might be a good idea to set the CPU target explicitly to pentiumpro in LLVM's flags (fix issue 1) (It could also be a good idea to set this for LLVM in general if possible, if not already done so). -- Also compile the i586 Rust toolchain, not the i686 one (fix issue 2). - For Rust programs, I'd probably recommend setting the target for all (?) of them to i586 (fix issue 2). One can also try to add "-C target-cpu=pentiumpro -C target-feature=-mmx -C target-feature=-sse -C target-feature=-sse2" to RUSTFLAGS, if the above doesn't work. Most of this is assumptions, but I hope it brings some progress. Best of luck and thank you.
Bug#973414: libmozjs-78-0: invalid opcodes when launching GDM on AMD Geode
Debian 12* -- Sorry! On 3/9/23, Fierelier OwO wrote: > I'm not sure if this is too late to change for Debian 13 by now, I'd > still love to see it happen. >
Bug#973414: libmozjs-78-0: invalid opcodes when launching GDM on AMD Geode
What smcv said is probably the right idea. The Rust toolchain should be compiled in i586, and Rust programs should be compiled to i586 as well (I'm not sure of the specifics here). The Rust team has been expressing issues with adapting the correct processor definition for their i686 build, see: https://github.com/rust-lang/compiler-team/issues/548#issuecomment-1439976916 -- It is unlikely we will see them change it now, hence the pull that Martin linked will most likely never be merged. I'm not sure if this is too late to change for Debian 13 by now, I'd still love to see it happen.