arek o sofcie

Różności na temat tworzenia oprogramowania

Ciekawa niespodzianka po aktualizacji kernela z 6.14 na 6.17.

Mój pecet nie ma obsługi ReBAR, co znaczy, że CPU miał okno komunikacji z VRAM ograniczone do 256MB.

Okazuje się jednak, że kernel 6.17 potrafi zignorować braki informacji z UEFI i samodzielnie odgadnąć potrzebę przemapowania zasobów na PCI. dmesg pokazuje serię powtarzających się komunikatów o alokacji zasobów PCI poprzetykana wpisami typu

[    0.356844] PCI: No. 4 try to assign unassigned res

I czwarta próba zakończyła się powodzeniem.

LM Studio bez problemu obsłużyło model gtp-oss:20b.

Dodatkowo libva zaczęło funkcjonować poprawnie i w końcu mam sprzętowe dekodowanie video av1.

Jak się okazuje, Linux naprawdę pozwala przywrócić do użycia stare pecety.

#linux

@ark_r

Kupiłem sobie kartę Arc Pro B50, żeby zastąpić starą kartę 1070 NVidii. Na razie chyba trzeba powiedzieć sobie, że w przypadku Linuxa jest trochę za wcześnie na ten sprzęt.

Problemy

Kartę wziąłem, bo ma 16GB VRAM, była tania i pobiera tylko 70W. Wydawało się OK na mój stary Dell Inc. XPS 8930.

Ale: * Przydałaby się obsługa ReBAR, żeby CPU miał większe okno dostępu pamięci karty – mam tylko 256MB, a mogłoby być 16GB, * Wygląda na to, że zderzenie PCIe 3.0 płyty z kartą PCIe 5.0 skończyło się tym, że komunikacja jest na jednej linii – LnkSta: Speed 2.5GT/s, Width x1. Trochę słabo.

Kolejny problem: libva nie działa. Ściągnąłem najnowsze biblioteki Intela z PPA, ale nawet uruchomienie vainfo kończy się crash-em. Żegnaj akceleracjo sprzętowa :)

Ciekawa sytuacja z chrome pod wayland: gdy Gnome wygasi ekran, desktop wywala się podczas ponownego włączania ekranu.

W przeglądarce widać pewne artefakty graficzne przy niektórych animacjach.

Wygląda na to, że sterownik xe w wersji 6.14.0-37-generic kernela nie jest jeszcze dopracowany.

Pozytywy

Akceleracja 3D (OpenGL, Vulkan, WebGL, WebGPU) działa. Wydajność jest całkiem przyjemna.

Dało się odpalić ollama w trybie OLLAMA_VULKAN=1. Wydajność nie jest powalająca, mimo że model w całości jest obsługiwany przez GPU. Może będzie się to poprawiać.

Pewnie i tak będę zmieniał komputer (jak ceny RAMu spadną :) ) i zobaczymy co będzie dalej.

Na Windows karta działa całkiem OK, mimo starej płyty głównej. Nawet Cyberpunka z Light Tracing odpaliłem.

Nie lubię zakupów sprzętu.

@ark_r

W teorii zrobiłem już wszystko i tag powinien działać.

Może to trochę spam, ale inaczej tego nie sprawdzę.

@ark_r

Tak, pewna niespodzianka, ale blog wiąż żyje. Chociaż nie mam czasu, żeby coś pisać.

Ale zrobiłem aktualizację i piszę posta, żeby sprawdzić, czy faktycznie nowe funkcje zadziałają.

Na pewno działają “lajki” – tj. gdy ktoś da fava np. na mastodonie, to widać to w artykule.

A teraz jeszcze kwestia taga fediverse:creator.

Ale to muszę dopiero ogarnąć. Może zadziała, a może nie.

Edit... no jakoś “creatora” nie ma.

#writefreely

@ark_r

Przy którejś aktualizacji kernela (gdzieś między 5.19, a 6.1) mój pecet nabył ciekawego problemu: wyłączanie kończyło się jak lata temu na windows, gdzie użytkownika żegnał napis “Teraz możesz wyłączyć komputer”.

Cała procedura shutdown-u przechodziła, ale na samym końcu, gdy kernel wywołuje acpi_poweroff, proces się zawieszał i musiałem wyłączać zasilanie przytrzymując kilka sekund przycisk na obudowie.

Przy okazji – usypianie (sleep/suspend) również przestało działać, ale tego akurat nie używałem zbyt często, więc przeszkadzało mi znacznie mniej.

Historia poszukiwania rozwiązania jest nudna jak flaki z olejem (ale sporo ciekawych rzeczy o ACPI można się dowiedzieć), więc od razu przejdę do rozwiązania (a przynajmniej czegoś, co u mnie to zadziałało).

Zgodnie z https://www.kernel.org/doc/Documentation/Intel-IOMMU.txt mój oparty na CPU Intela pecet może obsługiwać IOMMU dzięki stosownemu modułowi i zdaje się, że właśnie w kernelu 6.x dostarczanemu z Ubuntu ta funkcjonalność została włączona.

Pecet ma zintegrowaną grafikę Intela (której nie używam) i dodatkowo kartę NVIDIA. I chyba coś z tą nieużywaną grafiką Intela szwankowało.

We wskazanym dokumencie można przeczytać:

Graphics Problems?
------------------
If you encounter issues with graphics devices, you can try adding
option intel_iommu=igfx_off to turn off the integrated graphics engine.
If this fixes anything, please ensure you file a bug reporting the problem.

I właśnie owo intel_iommu=igfx_off rozwiązuje problem. Wartość off również, ale podobno iommu poprawia bezpieczeństwo (i przydaje się, gdy się uruchamia maszyny wirtualne).

W każdym razie – zadziałało. Po dodaniu do parametrów kernela w grub problem ustąpił i shutdown -P wyłącza zasilanie.

#linux #poweroff #iommu

@ark_r

Blog działa na komputerku z procesorem w architekturze ARM64, a writefreely ostatnio nie publikował buildów dla architektury innej niż ADM64.

Na szczęście ich problemy się rozwiązały i mogłem zrobić aktualizację.

Z większych zmian... z tego co widzę, to można już bez sztuczek obsłużyć weryfikację identyfikatora mastodon (rel="me), co niniejszym uczyniłem.

Aktualizacja sprowadza się do rozpakowania archiwum i wykonania

./writefreely db migrate

Do ogarnięcia :)

@ark_r

Z jakiś powodów zapragnąłem ustawić w Linuksie limity na użycie dysku. Pominę opis poszukiwania informacji w Internecie, ale w skrócie – z nieznanych mi powodów w zdecydowanej przewadze opisywane są jakieś starocie. W artykule pokrótce jak to wygląda w aktualnych wersjach jądra.

Czytaj dalej...

Czasami zdarza się, że zatwierdziłem jakieś zmiany, ale coś tam jednak wymaga poprawy. Pewnie skorzystam z git rebase -i, tym niemniej po takich poprawkach uporządkowanie commitów wymaga trochę pracy i tu z pomocą przychodzi opcja --fixup.

Czytaj dalej...

Albo “o co chodzi benchmarkach”.

Istnieje sobie portal benchmarksgame-team.pages.debian.net, który na przykładzie kilku algorytmów pozwala porównać wydajność wydajność implementacji w różnych językach.

W swojej historii pisałem w wielu różnych językach i niejednokrotnie mam możliwość wybrania języka dla realizowanego projektu. Takie porównania są więc interesujące, bo w sytuacji, gdy gdzieś kluczowa jest wydajność, dobrze jest wiedzieć, czy wybrałem właściwe narzędzie albo jak bardzo mój wybór jest nieoptymalny.

Z różnych powodów interesuje mnie porównanie wydajności języków Java i Go. Wchodząc pod ten adres https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go.html można się przekonać, że Go jest ogólnie porównywalny z Javą albo nawet szybszy, poza jednym przypadkiem: Binary trees!

Wydajność benchmarku binary-trees dla implementacji w Java i Go

Przypadki, gdy coś jest 10% szybsze albo wolniejsze, coś oczywiście mówią, ale w realnych programach najprawdopodobniej takie zyski rozmyją się w natłoku innych, niezbędnych i nieuniknionych elementów programu. W praktyce oprogramowanie, które piszę, co chwila coś wysyła po sieci, albo czeka na rezultaty z sieci i sekunda więcej na obliczeniach (choć ważna) nie boli tak bardzo. Zawsze można dodać CPU lub kolejną maszynę wirtualną i ogólna wydajność systemu spełni wymagania.

Ale w tym wypadku jest dramat: implementacja w Go jest 5,6 razy wolniejsza.

Czytaj dalej...

Tym razem coś o kwestii obsługi znaków i stringów. Na początek zagadka: co wypisze ten program?

RegExp

Czytaj dalej...