#Tag
it’s getting there! help us at https://icm.museum to support the Thinking Machines Connection Machine re-animation journey!
#hypercube #supercomputer #ai #bigdata #retrocomputing #vintagecomputing #gpu
it’s getting there! help us at https://icm.museum to support the Thinking Machines Connection Machine re-animation journey!
#hypercube #supercomputer #ai #bigdata #retrocomputing #vintagecomputing #gpu
GamersNexus's documentary on GPU smuggling into China, showing literally every step of the supply chain with people on camera willing to talk, is BACK ONLINE after Bloomberg's attempt to silence them via a bogus copyright claim.
It's here! Watch it, because it's sat at 0 views for two weeks thanks to Bloomberg News. Even if you just play it in the background, let's get this thing showing up in YouTube's algorithm again:
https://www.youtube.com/watch?v=1H3xQaf7BFI
Spread the word! Tell everybody, make it go!
#GamersNexus#GPU #smuggling#china#tech #technology #news #TechnologyNews #nvidia
GamersNexus's documentary on GPU smuggling into China, showing literally every step of the supply chain with people on camera willing to talk, is BACK ONLINE after Bloomberg's attempt to silence them via a bogus copyright claim.
It's here! Watch it, because it's sat at 0 views for two weeks thanks to Bloomberg News. Even if you just play it in the background, let's get this thing showing up in YouTube's algorithm again:
https://www.youtube.com/watch?v=1H3xQaf7BFI
Spread the word! Tell everybody, make it go!
#GamersNexus#GPU #smuggling#china#tech #technology #news #TechnologyNews #nvidia
Hasard, coïncidence, je ne pense pas ...
Huawei enters the GPU market with 96 GB VRAM GPU under 2000 USD, meanwhile NVIDIA sells from 10,000+ (RTX 6000 PRO)
https://www.alibaba.com/product-detail/New-Huaweis-Atlas-300I-DUO-96G_1601450236740.html
ARM is adding dedicated neural accelerators to its GPUs starting in 2026, bringing support for features like Neural Super Sampling, an AI upscaler that can reduce GPU workloads by rendering 540p content and upscaling to 1080p in as little as 4ms. https://newsroom.arm.com/news/arm-announces-arm-neural-technology#Arm#GPU#Upscaling#NeuralAccelerator #graphics
Found updated NFB (New Feature Branch) of #nvidia #GPU driver sets 575.64.03.
Filed PR for #FreeBSD #ports as Bug 287984
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287984
and opened corresponding review D51144
https://reviews.freebsd.org/D51144
Patch there is for "-devel" variant of ports like x11/nvidia-driver-devel.
Runnign on stable/14, amd64 until last night without new issue for me.
But as my GPU on hand is old (Quadro P1000 notebook), cannot confirm that the new version solves any of known problems on GPUs with GSP in them by myself.
Can you program GPUs and do you want to become a HERO? #linuxphone
community needs your help.
We are trying record video, and have most pieces working, but one is
missing: fast enough debayering. That means about 23MB/sec on #librem5.
Debayering is not hard; camera images have subpixels split on two
lines, which need to be corrected. They also use different color
representation, but that's fixable by some table lookup and two matrix
multiplies.
Librem 5 has Vivante GPU, 4 in-order CPU cores and 3GB RAM. My feeling
is that it should be fast enough for that. If task is for some reason
impossible, that would be good to know, too.
Image data looks like this
RGRGRG...
xBxBxB...
.........
.........
Task is to turn that into usual rgbrgb.... format. rgb = RGB * color
matrix, with table lookups for better quality. I can fix that once I
get an example.
I'm looking for example code (#pinephone would work, too), reasons it
can not be done... and boosts if you have friends that can program
GPUs. #gpu#opensource
Can you program GPUs and do you want to become a HERO? #linuxphone
community needs your help.
We are trying record video, and have most pieces working, but one is
missing: fast enough debayering. That means about 23MB/sec on #librem5.
Debayering is not hard; camera images have subpixels split on two
lines, which need to be corrected. They also use different color
representation, but that's fixable by some table lookup and two matrix
multiplies.
Librem 5 has Vivante GPU, 4 in-order CPU cores and 3GB RAM. My feeling
is that it should be fast enough for that. If task is for some reason
impossible, that would be good to know, too.
Image data looks like this
RGRGRG...
xBxBxB...
.........
.........
Task is to turn that into usual rgbrgb.... format. rgb = RGB * color
matrix, with table lookups for better quality. I can fix that once I
get an example.
I'm looking for example code (#pinephone would work, too), reasons it
can not be done... and boosts if you have friends that can program
GPUs. #gpu#opensource
Review D50697 for -devel versions of #nvidia #GPU #driver sets (latest NFB 575.64) on #FreeBSD now landed on main branch of #ports tree as commit c7cde11f842b33bb36b85b91400bec795430c421.
From now on, whichever the newer version of NFB (New Feature Branch) and Production branch is tracked on -devel branch. Beta Branch is not planned to be tracked, and just being a trigger to preparing for upcoming NFB or Production Branch.
Note that as I'm not an insider of nvidia, I cannot start investigating until nvidia releases new driver sets.
Opened review for #FreeBSD Bug 287268 on Phablicator as Differential Revision D50697, which adds latest New Feature Branch (NFB) of #nvidia#GPU drivers as x11/nvidia-driver-devel, x11/linux-nvidia-libs-devel and graphics/nvidia-drm[|-510|-515|-61|-66]-kmod-devel.
Once accepted and landed, it would track the latest version of whichever NFB or Production Branch of drivers. Beta Branch of drivers wouldn't be tracked.
https://reviews.freebsd.org/D50697
💾 Quick HomeLab Update 💾
As a follow up to this morning's iGPU 512M GART debugging (re: drm-61-kmod memory leak on amdgpu.ko), here are some pics. Reluctantly, the "ok fine" method for testing the memory leak allocation aspects involves using a non-integrated GPU which requires the same driver, for which this low-TDP single-slot AMD W7500 was acquired. Sometime tomorrow it will be installed in my workstation, which is the third chassis from the bottom (4U) situated above the two 5U chassis (HCI private cloud for GPU compute VMs).
More to follow...
Panic most recently used by lkpikmalloc ...
Well, that was fast... didn't even get a mouse cursor of a full MATE Desktop menu system load. Was yet to connect kgdb to COM1 (need to swap from minicom to do so)... makes me want a PCIe RS232 card (for "comconsole_pcidev") so that I have a few more COMs to play with on redirects. Gotta love these iGPU tash-bins eh? "It's better than not having a GPU right?" ... not really.''
Closed bug report from the drm-515-kmod, discussing amdgpu memory leak. so, maybe a new one in drm-61-kmod, would not be surprised.
- https://github.com/freebsd/drm-kmod/issues/258
Short term revision of approach:
----
1. Today via post arrives, an AMD Radeon Pro W7500 (single slot 8GB, Navi-whatever gen)
2. I'll block off the iGPU during loader.conf sequence, using a "pptdev" blackhole (not for VM pt, but maybe an experiment for a 14.1 VM with the known-good amdgpu version).
3. Known as: throw money at the problem?
Some hardware notes:
----
1. This is not a Nvidia GPU situation; there are several generations of cards in the room which have been cycled through the workstation during "hardware isolation" and "process of elimination" sequences. I know those are stable, and which gen cards require which nvidia driver versions for stability purposes.
2. This is not a FreeBSD kernel issue, nor a Xorg "Plain Jane FrameBuffer" situation. The kernel (14.0, 14.1, 14.2) is stable and fine, and the basic vt driver for non-4K display-port functionality works fine. I can work all day in a series of tmux windows with some fifty or so panes, but that's not quite the optimal experience.
3. The AMD iGPU (Raphael) maxes out default to 512MB GART VRAM, and it can handle 240Hz @ 4K all day with no issues as long as that 512M doesn't get used up... that is until the latest amdgpu kmod drm, which crashes whenever it feels like it.
Michael... yes yes, I do have a lot of hardware, but this issue has surpassed the Sunk Cost Fallacy and has become a consumate knowledge-requirement process. I must know where this is failing so horrendously, otherwise the operating rule of "if it doesn't fulfill its hardware destiny, it will get the hammer and flames"... and the hardware is too nice for that - plus I could involve Supermicro support since it's still in warranty, but a replacement motherboard or CPU for the iGPU isn't going to solve a kernel module issue.
In the interim, laptop life and tablet meetings are getting me by, mostly decently.
Debug items of interest:
----
intsmb0: at device 20.0 on pci0
intsmb0: Could not allocate I/O space
device_attach: intsmb0 attach returned 6
drmn0: Fetched VBIOS from VFCT
amdgpu: ATOM BIOS: 102-RAPHAEL-008
drmn0: Trusted Memory Zone (TMZ) feature not supported
drmn0: PCIE atomic ops is not supported
drmn0: VRAM: 512M 0x000000F400000000 - 0x000000F41FFFFFFF (512M used)
[drm ERROR :amdgpu_bo_init] Unable to set WC memtype for the aperture base
Loader items of usage:
----
# Multi-Console Output
# boot output primary: TTY, standard monitor via UEFI
# boot output secondary: COM1 RS232 Redirect (physical)
# boot output tertiary: COM2 RS232 Redirect (BMC SoL)
ipmi_load="YES"
boot_mute="NO"
boot_verbose="YES"
verbose_loading="YES"
boot_multicons="YES"
boot_serial="YES"
console="efi,comconsole,comconsole"
comconsole_port1="0x3F8"
comconsole_speed1="115200"
comconsole_port2="0x2F8"
comconsole_speed2="115200"
hw.uart.console="io:0x3f8,br:115200 io:0x2f8,br:115200"
#amd #gpu #drm616kmod #freebsd #debugging #engineering #4amlife #5amlife #debuggingForever#tiredOfDebugging#goddamnMemoryLeaks#linuxDriversByAssociation#moreTerminals #rs232#tiredNowGoNap #friday
💻 FreeBSD CUDA drm-61-kmod 💻
"Just going to test the current pkg driver, this will only take a second...", the old refrain goes. Surely, it will not punt away an hour or so of messing about in loader.conf on this EPYC system...
- Here are some notes to back-track a botched/crashing driver kernel panic situation.
- Standard stuff, nothing new over the years here with loader prompt.
- A few directives are specific to this system, though may provide a useful general reference.
- The server has an integrated GPU in addition to nvidia pcie, so a module blacklist for the "amdgpu" driver is necessary (EPYC 4564P).
Step 1: during boot-up, "exit to loader prompt"
Step 2: set/unset the values as needed at the loader prompt
unset nvidia_load
unset nvidia_modeset_load
unset hw.nvidiadrm.modeset
set module_blacklist=amdgpu,nvidia,nvidia_modeset
set machdep.hyperthreading_intr_allowed=0
set verbose_loading=YES
set boot_verbose=YES
set acpi_dsdt_load=YES
set audit_event_load=YES
kern.consmsgbuf_size=1048576
set loader_menu_title=waffenschwester
boot
Step 3: login to standard tty shell
Step 4: edit /boot/loader.conf (and maybe .local)
Step 5: edit /etc/rc.conf (and maybe .local)
Step 6: debug the vast output from kern.consmsgbuf logs
#freebsd #nvidia #cuda #gpu #engineering #terminal #saturday
A space for Bonfire maintainers and contributors to communicate
