Create accountLogin

Recent searches

No recent searches

Search options

Not available on horrorhub.club.
horrorhub.club is one of the many independent Mastodon servers you can use to participate in the fediverse.
A Mastodon server for Horror fans.

Administered by:

Server stats:

68
active users

horrorhub.club: AboutProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.3.4

#amd

1 post1 participant0 posts today
Replied in thread
Public *
Cosmic Cleric

@otherdog Unfortunately ridiculous seems like the new norm.

I was really hoping with Intel entering the GPU Market that there would be more competition and pricing adjustments, but that doesn't seem to be happening.

Having said that, if you can wait, not purchase right away, and if everyone does that, then the market will adjust down, because at some point they need to actually sell the hardware.

#AMD#Intel#GPU
Public
♡ Eva Winterschön ♡

💾 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...

#gpu #amd #ai #homelab #freebsd #linux #

Public
Mika

Done this with the #AMD 5600G's iGPU, now testing #Jellyfin hardware transcoding with my #Intel #ArcA380 GPU - one question though, is it normal for CPU usage to be rather high at least in the early parts of streaming (while transcoding), even with hardware transcoding?

I'm just trying to figure out if it is actually hardware transcoding - I'm assuming it is, bcos on the admin dashboard I'm seeing that it's transcoding as AV1 and I'm sure my Ryzen 7 1700 would not be able to do/handle that, esp considering that I'm testing with 4 streams playing concurrently? but the CPU usage is rather high the first minute or two or more from when the stream starts, it does lower down afterwards - the video playback is perfectly fine, no stuttering or anything like that.

My method of passthrough is the same as I did with the 5600G, that is a simple passthrough to the #LXC container, then to the #Docker container running Jellyfin. I don't think I noticed this high CPU usage when testing the 5600G, and the only minor configuration difference between the two was I'd used #VAAPI with the 5600G and disabled #AV1 encoding (since idt it supports it), while on the Arc A380 GPU I'm using Intel's #QSV and have enabled AV1 encoding.

Am I correct to assume that hardware transcoding is indeed working? Cos again, I'm quite certain my Ryzen 7 1700 would definitely be able to handle this lol esp since I only give the LXC container 2 cores.

Screenshot of a terminal window showing htop on the top half, and docker logs at the bottom. Htop shows high CPU usage running multiple ffmpeg processes.
Playback info message on Jellyfin admin dashboard of one of the 4 streaming sessions, saying that it's 'Transcoding', and that 'The media is being converted into a format that is compatible with the device that is playing the media.' The format its transcoding seems to be '420 Kbps MP4 AV1 AAC'. The reason it gave for transcoding says, 'The number of audio channels is not supported. The video's bitrate exceeds the limit'.
Continued thread
Public
♡ Eva Winterschön ♡

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.
- github.com/freebsd/drm-kmod/is

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: <AMD FCH SMBus Controller> 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
Public
Benjamin Carr, Ph.D. 👨🏻‍💻🧬

#AMD splits #ROCm toolkit into two parts – ROCm #AMDGPU drivers get their own branch under Instinct #datacenter #GPU moniker
The new #datacenter Instinct driver is a renamed version of the #Linux AMDGPU driver packages that are already distributed and documented with ROCm. Previously, everything related to ROCm (including the amdgpu driver) existed as part of the ROCm software stack.
tomshardware.com/pc-components

Tom's Hardware · AMD splits ROCm toolkit into two parts – ROCm AMDGPU drivers get their own branch under Instinct datacenter GPU monikerBy Aaron Klotz
Public
t3rminus

Well, it woke up this morning after being in sleep mode all night. I'm calling this “likely fixed”. Huzzah!

The solution, for anyone with an ASUS ROG Strix B550-I (or similar boards from ASUS) motherboard that won't wake up from sleep:

echo XHC0 > /proc/acpi/wakeup

In theory, all this does is prevent USB3 devices on XHC0 from waking the system (kb and mice are USB2 so shouldn't be affected). Why this would prevent the system from waking properly is a mystery.

#linux#amd#acpi
ExploreLive feeds
About