marcan changed the topic of #asahi-gpu to: Asahi Linux: porting Linux to Apple Silicon macs | GPU / 3D graphics stack black-box RE and development (NO binary reversing) | Keep things on topic | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-gpu
zkrx has quit [Ping timeout: 246 seconds]
zkrx has joined #asahi-gpu
PhilippvK has joined #asahi-gpu
phiologe has quit [Ping timeout: 276 seconds]
<marcan>
it's pretty hard to break anything by messing with PLLs
<marcan>
you'll just crash things
<marcan>
VRM, yes
<phire>
you mean external VRMs on i2c buses?
<marcan>
that's usually where they are, though on SoCs with internal voltage control stuff that applies to internal MMIO too
r0ni has joined #asahi-gpu
phire has quit [*.net *.split]
herbas has joined #asahi-gpu
phire has joined #asahi-gpu
herbas has quit [Quit: herbas]
robinp has quit [Read error: Connection reset by peer]
Lightsword has quit [Quit: ZNC]
Lightsword has joined #asahi-gpu
akemin_dayo has quit [Ping timeout: 240 seconds]
<segher>
marcan: most PLLs don't allow crazily out-of-range settings... but running something at 4GHz instead of 3.5GHz will increase power consumpotion by 25% or so, reducing lifetime, maybe by a lot
<marcan>
segher: most things won't *run* at 4GHz instead of 3.5GHz if 3.5GHz is nominal, and unless it reduces lifetime by a million times, nobody cares; these experiments last seconds to minutes.
<marcan>
the closest I've come to damaging hardware from this kind of thing was some temporary DC bias damage done to an LCD panel, but that was because I got the power sequencing wrong (which caused it not to init properly and bias the panel), so again, power stuff
<marcan>
that cleared up within a week or so though
<marcan>
I've done the "let's crank up the clock to beyond design specs" thing too; what happened was the power circuitry couldn't handle it and the thing shut down :-)
<marcan>
if overclocking damaged things permanently (when you don't touch the voltage) people would be killing a lot of PC hardware
<segher>
most things *will* run at 6GHz instead of 3GHz even (with good cooling). and if it reduces lifetime by 10x most people will care a LOT
<segher>
and 100x makes it unsuitable during development even
<segher>
but yeah you do not mind much while just spraying the register space
<marcan>
100x doesn't matter; 100x is 10 years to 36 days
<marcan>
nobody's going to accidentally run something at 6GHz without noticing for that long :-)
<segher>
yes, so it matters a lot
<segher>
unless you can do bringup activities in under a month?
<marcan>
I can certainly figure out a PLL in under a month
<segher>
yeah, but that does not matter
<segher>
13:25 <@marcan> if overclocking damaged things permanently (when you don't
<segher>
touch the voltage) people would be killing a lot of PC hardware
<marcan>
I generally don't make a habit of running code that randomly pokes registers I do not understand without a specific goal in mind :)
<segher>
guess what.
<marcan>
I don't think anyone does that there either
<marcan>
the people doing 6GHz are doing it to set a record on liquid nitrogen, for 5 minutes
<marcan>
not to actually use the things
<segher>
hrm, you live in a different world i guess :-)
<marcan>
I organize spain's largest lan party, and overclocking competitions have been a thing here; I have some personal experience :)
<marcan>
I think I only ever saw one guy with a phase-change cooler that might've had any chance of seeing normal use
<segher>
yes, you look at hobbyists only
<marcan>
I also worked for google and I can tell you they don't overclock their servers :P
<marcan>
(OTOH, Intel sometimes does, *cough* l*****v *cough*)
<marcan>
(I still regret losing the link to that one OEM advisory that I was certain was a reference to that incident)
snalty has joined #asahi-gpu
<segher>
who is talking about overclocking? i am not
<marcan>
I'm not entirely sure what you're talking about; we somehow went from "accidentally misconfiguring a PLL during MMIO experiments" to "people supposedly running chips at 2x their rated clock"
<segher>
heh, let's drop it
<JTL>
re overclocking: I think I read an article awhile ago that discussed the risk of electromigration getting worse with overvolting and higher transistor density based CPUs
<JTL>
(i.e on 32nm and newer nodes)
<JTL>
but otherwise, yeah...
<marcan>
if you overvolt, yeah, definitely
<marcan>
and people who do that on consumer stuff better know they are reducing the lifetime of their hardware
<marcan>
but just bumping up clocks is a lot less dangerous
<marcan>
and it definitely doesn't matter for experiments
<JTL>
right right
<marcan>
incidentally, the M1 GPU firmware has some messages about temperature trips and such, so I expect that we won't be cooking any M1s by accident
<marcan>
there should be safeties around all that
<JTL>
good
<segher>
only by ignoring the messages (or having a non-working console ;-) )
<JTL>
marcan: I built a 3700x workstation last year and dealt with many defective parts (covid factory QC issues anyone?) and in my testbench testing with janky heatsink mounting I never fried anything lol
<JTL>
</sidenote>
<ar>
i was surprisingly lucky with my workstation/desktop i built late last year, as nothing was defective, and i managed to fit it everything in the tiny case i got for it…
<JTL>
heh
<JTL>
cool me old fashioned, but I prfer rackmount or (reasonable) desktop tower cases in terms of clearences
<JTL>
:)
<JTL>
ar: this was around circa July/August, and date codes from some parts showed around April/May manufacturing dates
<ar>
i have other machines i want to rackmount, but i would need to get new cases for them
<JTL>
fair
<JTL>
I have a similar planned project in this area, but that's not going to happen for a while and should be taken to #-offtopic later
<JTL>
:P
<marcan>
segher: no, it will throttle or shut down
<marcan>
it's not just warning messages
<marcan>
that's the point
<marcan>
nobody reads messages :P
<ar>
speaking of "nobody reads messages". i got a m1 mbp13 from the company i work for now, and dmesg on it is full of weird stuff
Lightsword has quit [Quit: ZNC]
Lightsword has joined #asahi-gpu
choozy has joined #asahi-gpu
akemin_dayo has joined #asahi-gpu
grange_c has quit [Quit: Ping timeout (120 seconds)]
grange_c has joined #asahi-gpu
<bloom>
macOS has dmesg?
<marcan>
it does
<marcan>
and yes, there is a *ton* of spam
<konradybcio>
It might be a dumb question.. but could the perf loss because of all the logging hurt performance in an unsignificant way on older machines?
<ar>
one of the weirdest things that i found there, were some spi dumps
<konradybcio>
Afaict macos is still not on android level of spamming logs but it's pretty up there
<dottedmag>
konradybcio: Very unlikely. logd never shows up as eating any significant amount of CPU or IO
<bloom>
is macOS dmesg distinct from Console.app?
<ar>
looks about the same
<ar>
except for dmesg being non-gui
<ar>
and dmesg on macos not having -w and -T flags, so it cannot automatically follow new entries, and timestamps aren't human-friendly
<dottedmag>
bloom: dmesg shows up in Console as "pid 0 messages", but non-kernel messages aren't posted to dmesg.
<dottedmag>
Console chiefly displays whatever was posted by os_log(3) -- and I have no idea how is it different from syslog(3) -- and these messages end up in /var/db/diagnostics. Probably through logd or syslogd
<dottedmag>
ar: there's log(1) for that
pthariensflame has joined #asahi-gpu
pthariensflame has quit [Client Quit]
DarkShadow44 has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]