Bug#1006202:

2023-04-22 Thread Fierelier OwO
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

2023-04-19 Thread Fierelier OwO
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

2023-04-18 Thread Fierelier OwO
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

2023-04-03 Thread Fierelier OwO
* 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

2023-03-28 Thread Fierelier OwO
@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

2023-03-09 Thread Fierelier OwO
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

2023-03-09 Thread Fierelier OwO
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.