chibill has quit [Quit: Bridge terminating on SIGTERM]
Maja[m] has quit [Quit: Bridge terminating on SIGTERM]
Irvise_ has quit [Quit: Bridge terminating on SIGTERM]
Killy has quit [Quit: Bridge terminating on SIGTERM]
jack_rabbit has quit [Quit: Bridge terminating on SIGTERM]
chibill has joined #osdev
Irvise_ has joined #osdev
Killy has joined #osdev
jack_rabbit has joined #osdev
Maja[m] has joined #osdev
puck has quit [Excess Flood]
puck has joined #osdev
fisu has joined #osdev
<fisu>
Hi, could someone explain to me what exactly the glyph loading loop does? It seems to do a bunch of bit manipulation but there's not much on exactly what it's trying to do (https://wiki.osdev.org/PC_Screen_Font#Loading_the_font)
<bslsk05>
wiki.osdev.org: PC Screen Font - OSDev Wiki
eroux_ has quit [Ping timeout: 246 seconds]
eroux has joined #osdev
<zid>
the else if thing in the middle of psf_init? it's turning utf-8 into a codepoint, in a really ugly way
<fisu>
yeah, is there some better way to do it?
<fisu>
I don't like using code that I don't understand
<zid>
The utf-8 encoding is actually really simple.. and I swear I had some example code around here..
<fisu>
oh, figured it would've been pretty complex based on that sample...
<zid>
Yea most of the code in the wiki is hilariously bad, just.. enthusiastic
<zid>
It looks a lot better once you cram it into a helper function that can return early after processing each byte
<fisu>
Alright, by the way, isn't there an error in this tutorial https://wiki.osdev.org/Bare_Bones, shouldn't it use `-nostartfiles` or you'll end up getting the standard one?
<bslsk05>
wiki.osdev.org: Bare Bones - OSDev Wiki
<fisu>
(the standard _start)
<zid>
I'm sure it's all awful
<fisu>
Lmao, alright, good to know
<zid>
but nostdlib implies nostartfiles
<fisu>
Doesn't use that either for that matter, but any resources that you'd recommend then?
<zid>
experience :P
<fisu>
Fair enough
<zid>
I'm mad I can't find that utf8 code
<zid>
it might be in .git/ somewhere but I have no idea where..
<fisu>
Aww, it's alright, I'll just take read the wikipedia page about it and make my own
<zid>
I wanted it for me as well
<fisu>
Probably high time I knew how UTF-8 works
<fisu>
I've gotten away with not knowing it for long enough
<zid>
Just see what your byte 1 looks like, and grab the rest of the x form the other bytes and shift + or them together
<fisu>
yeah
<zid>
verify the tops of the other bytes if you wanna be 'compliant'
<zid>
if(!(c[0] & 0x80)) return c[0]; if(c[1] & 0b1110000 == 0b1100000) return (c[0] & 0b1110000)<<5 | c[1] & 0b111111; blah blah, but you can make it nice and clean if you just accumulate things into an 'uint codepoint;' or whatever
<zid>
err if(c[0] ..
<zid>
table is 1 indexed and I was reading off it, oops
<fisu>
yea
<fisu>
I think the first step though is getting the font there, I suppose I can follow the wiki for that though
<zid>
I did a gross thing
<fisu>
Hmm?
<zid>
by which I mean I stole unifont, which is just a .c file
<zid>
it's cute though
<zid>
it does #define _____XX_ 6 etc, 256 times at the top
<zid>
then draws all the glyphs in ascii art
<fisu>
I'm excited for #embed, will probably make for example adding the font a lot nicer
<zid>
I mean, not really, tbh
<zid>
it's 30 years too late
<zid>
bin2o exists
<fisu>
though at work I'll probably get to enjoy #embed when the sun stops shining
<bslsk05>
www.warp.dev: Adventures in Text Rendering: Kerning and Glyph Atlases | Warp
<zid>
PIXEL should be a macro not a type, stab them in the knee
<GeDaMo>
«TrueType systems include a virtual machine that executes programs inside the font, processing the "hints" of the glyphs, in TrueType called “instructions”.» https://en.wikipedia.org/wiki/TrueType
<bslsk05>
en.wikipedia.org: TrueType - Wikipedia
<zid>
That page I just linked is a pretty good run-down of how font rendering works, at least, once you have the glyphs in-hand
<fisu>
yeah, I took some .otb file, I hope it's usable
<zid>
Unless you wanna do SDF :P
<fisu>
I just want to have some simple renderer, no need to over-do it D:
<zid>
yea but SDF is fun, and I don't have to write all the code if I just tell you to do it
<bslsk05>
github.com: boros/vbe.c at master · zid/boros · GitHub
<zid>
ignore the slow-as-shit blending and muxing it with a hardcoded background image :P
<fisu>
:D
<zid>
oh it's 8x16 til
<fisu>
how do you get the font to the correct format (.o) though? just objcopy from some point forward?
<zid>
unifont is a .c file already
<zid>
with the funny #define system to make it all ascii-art
<fisu>
oh, then I downloaded the wrong one
<zid>
there's the hacked up version in that repo with the charmap
<zid>
looks up the 'first row' of the glyph in unifont.c's big array, draws 16 rows from that +0-15, by expanding each byte into a 'bit' via !!(glyph_byte & (1 << (8-1-i)));
<bslsk05>
github.com: boros/unifont.c at master · zid/boros · GitHub
<zid>
it made bslsk05 unhappy at least, that was a good 20 seconds
<fisu>
lmao
<fisu>
yeah, it sure took a while to open
<zid>
compile that, link against the .o and never recompile it ever, charmap[] tells you which codepoint is which glyph, unifont_bitmap[] has a glyph every 16 bytes, done
<fisu>
lmao, I'll do that then thanks
<zid>
it's all in the prep-work in this case
<zid>
like all graphics (grumble)
<zid>
it took me like an hour to convert the bmp to flat ARGB so I could use it for my bg image, who knew 'bmp3' was a thing you needed to teach imagemagick about, and channel cloning
<zid>
and swappin
srjek has joined #osdev
<fisu>
that seems difficult, how aren't fonts made more trivial D:
<GeDaMo>
Depends how simple you want to get :P
srjek|home has joined #osdev
<zid>
I mean, in terms of graphics pipelines, it's about as simple as you're going to get
<zid>
other than flat ARGB
<fisu>
True
<zid>
"expand each byte into saturated ints"
srjek has quit [Ping timeout: 250 seconds]
freakazoid332 has joined #osdev
freakazoid332 has quit [Read error: Connection reset by peer]
[itchyjunk] has joined #osdev
heat has joined #osdev
<heat>
sup noobs
<zid>
what did you make us for lunch heat?
<heat>
mcdonalds
<zid>
sick
<heat>
literally
<zid>
when is it showing up?
<zid>
I'll take a big mac meal with a coke
<heat>
you're supposed to come here
<heat>
sorry :|
<zid>
You will be sorry, when I shwo up on your door asking for my bigmac
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
rpnx has quit [Ping timeout: 246 seconds]
rpnx has joined #osdev
Raito_Bezarius has quit [Ping timeout: 248 seconds]
xenos1984 has quit [Read error: Connection reset by peer]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Raito_Bezarius has joined #osdev
Raito_Bezarius has quit [Max SendQ exceeded]
xenos1984 has joined #osdev
Raito_Bezarius has joined #osdev
ThinkT510 has quit [Ping timeout: 244 seconds]
ThinkT510 has joined #osdev
<fisu>
zid: do you happen to know how the new pixel buffer works by the way? Where exactly do you need to write to?
<fisu>
the 0xb8000 is apparently the deprecated way?
<heat>
what new pixel buffer?
<heat>
oh, your framebuffer
<fisu>
yeah
<heat>
0xb8000 is deprecated bunk that is emulated by your GPU
<heat>
it's very restricted and only works for shitty resolutions, and you may need to mess with vga crap
<heat>
your GPU is giving you a big flat framebuffer in this case
<fisu>
yeah, so I've read, what's the "new" way to do it?
<heat>
it's linear and essentially an array of pixels
<heat>
if you're asking how to get one: VESA, or UEFI GOP, but usually your bootloader
<heat>
also standard GPU drivers, etc but you're a long way off :)
<fisu>
ah I see
<fisu>
so which one should I start with?
<heat>
also 0xb8000 is text mode, 0xa0000 is vga graphical mode
<heat>
idk, tell me more about your kernel
<fisu>
I've pretty much just started, it has a basic boot file and not much more
<fisu>
is my best bet to still use the VGA one then?
<bslsk05>
wiki.osdev.org: Bare Bones - OSDev Wiki
<heat>
oh, right
<heat>
you can ask GRUB for a framebuffer
<heat>
BUT you don't need to
<heat>
if you want to go for this right now, go ahead
<heat>
you can also just use text mode for the time being
Matt|home has joined #osdev
<fisu>
hmm alright
opal has joined #osdev
Piraty has quit [Quit: -]
Piraty has joined #osdev
Piraty has quit [Client Quit]
Piraty has joined #osdev
Piraty has quit [Client Quit]
Piraty has joined #osdev
darkstardevx has joined #osdev
<fisu>
amazing, I now have my first output
<fisu>
heat: >also 0xb8000 is text mode, 0xa0000 is vga graphical mode
<fisu>
thank you
<heat>
no problem :)
<heat>
happy to help
darkstardevx has quit [Remote host closed the connection]
<fisu>
will I find the stuff about asking grub for a framebuffer in the multiboot standard?
darkstardevx has joined #osdev
<heat>
ye
<fisu>
cool thanks
<fisu>
so all my confusion about fonts a few hours wasn't really relevant yet then I suppose?
<fisu>
I was trying to figure out how to print a bitmap font like unifont
<zid>
I actually wrote a desktop program for my font code first
<zid>
./a.exe hello
<zid>
and made that spit out X_______ ________ __X____ __X____ ________\n ...
<zid>
and for graphics I made sure setting random pixels in various corners was correct etc
<zid>
I am not ashamed to know that I am likely to fuck it up if I write too much code at once
<zid>
so I religiously test small pieces in isolation
<sham1>
TDD
<mrvn>
There already is a tool for that, that prints banners.
<zid>
I thought TDD was when you used interpreted languages so you had to make "unit tests" that made sure your integers hadn't accidentally turned into strings
<zid>
They don't like "I tested it when I wrote it", because.. that genuinely happens
<zid>
types and ABIs are illegal
<mrvn>
that's how you automate the testing bit
<mrvn>
and you are supposed to test a feature first and then implement it
<mrvn>
maybe you are doing DDT - developement driven testing :)
xenos1984 has quit [Ping timeout: 268 seconds]
xenos1984 has joined #osdev
<sham1>
zid: well, TDD is also useful with static typing and the like, due to the idea that the domains of your types might still be too wide for the logic, so you test to make sure that your logic is proper
<mrvn>
Sometimes you even need the test for the static typing to find the type
<mrvn>
E.g. ocaml has a "value restríction" where you end up with a function that can take some unknown type but it always has to be the same type. And then the test throws a type at it so the compiler deduces what type the function actually takes.
epony has quit [Remote host closed the connection]
<mrvn>
Or in general the compiler might deduce a type for a function to make it compile but the type isn't what you intended. When you add the test case the compiler says: type error.
epony has joined #osdev
<zid>
yea but I do that while I write it, hopefully, and once I've tested it then never need to run *again*
divine has joined #osdev
<zid>
which I thought was the point of TDD
<zid>
that you make a suite in case some weird effect happens to break it (my example being the type inference going nuts)
<mrvn>
One point of TDD is that you still have the test after you wrote the code. So when you refactor or add other features the tests make sure the old feature still work.
<mrvn>
You test it every time you build, or at least before every release.
<dminuoso>
Of course that part has nothing to do with TDD, but with tests in general.
<dminuoso>
(Some call that regression testing)
<zid>
I'm saying TDD exists for a reason
<zid>
so I both wasn't doing it, and didn't need to do it
<bslsk05>
www.phoronix.com: A 20 Year Old Chipset Workaround Has Been Hurting Modern AMD Linux Systems - Phoronix
<geist>
ah interesting
<geist>
yeah that deep wait/no-wait/cstate stuff is an area i really dont know much about
<zid>
next week: nvidia.ko perf on linux down because of nforce4 quirk code
<geist>
we already have our own set of workarounds there, but mostly in the 'what do we do for idle' switch that's per microarch
<heat>
you're not using acpi for that?
<geist>
oh no not at all
fisu has quit [Quit: WeeChat 3.6]
<geist>
honestly no idea how that's supposed to work, since there are a multitude of idle mechanisms on x86, and it's really hard to have one implementation that works on all
<geist>
basically you end up needing N different idle thread implementations, etc
<geist>
but thats why i have deeper x86 experts to deal with it
<geist>
the acpi path may be one of them but we dont have acpi in the kernel, aside from the simple boot tables, so it'd also probably be a pain to inform the kernel how to idle after the fact, if the acpi idle looks like some sort of bytecode thing. but i have no idea
<heat>
i guess you can always use mwait
<geist>
well, except on some microarches it's worse than hlt, etc
<heat>
sure, but you have more control over the cstate
<heat>
which is exactly what you want in idle
<geist>
depends
<geist>
depends on if you're trying to get lowest power, or lowest latency, or all of the above
<geist>
it's not as straightforward an answer as you think
<heat>
which is why you'd use mwait?
<geist>
and i think we found and/or Its Known that some microarches dont do a good job with mwait
<geist>
and a simple hlt is better
<heat>
hrm
<geist>
i think for example we found that zen 1 does a better job with hlt. actually saves more power
<heat>
modern intel seems to always use mwait
<heat>
as in linux's intel_idle
<geist>
also i *think* to use mwait effectively from a power point of view you need to know what levels to ask for, and/or try to get info from the scheduler, etc
<geist>
basically the intel_idle driver probably has a bunch of per microarch magic
<geist>
so the question is if you *dont* have that logic in your driver, what's the reasonable default mwait level? is that better than hlt?, etc
<geist>
it's one of those 'unless you have it super optimized, you may be worse only going half way there' sort of things
<geist>
a problem that shows up in lots of osdevery
<bslsk05>
fuchsia.googlesource.com: zircon/kernel/arch/x86/feature.cc - fuchsia - Git at Google
<geist>
does remind me, there's another todso there to fill in that table for newer microarches
<geist>
i'll see if i can unsecret that bug. older bugs were defaulted to secret, even if they dont need to be
<geist>
there's some logic in the mwait idle loop that tries to guess which level to go to based on scheduler info, hence that table
<geist>
i didn't write any of that so it's not real clear in my mind how it all works, or how *well* it works
<heat>
ok it looks like acpi idle seems to only need tables (and optionally some info from bytecode it looks like)
<heat>
unknown_reboot_system means you can't reboot?
<geist>
possible the point of the acpi idle stuff is really to effectively provide these tables
<geist>
i think it always falls back to the PS/2 reset method
<heat>
i don't like that you're poking chipset registers directly
<heat>
it's bound to screw something up, somewhere
<geist>
agreed. there's no chipset level drivers in the kernel
<geist>
so i this case there's some assumption that microarch foo == chipset bar
<geist>
in general this code is constantly getting fiddled and updated and i'm not sure this entire mechanism is the right strategy, but it works well enough for now
<geist>
it hasn't turned out to be fatal, but it's a general maintenance burden, but then i'm not sure there's really a way to avoid a lot of the burden, because at the end of the day there's a bunch of x86 specific BS you just have to do
<geist>
so one strategy is to try to get it all in one spot, so you can fiddle with it in one spot
<geist>
it's made somewhat better in our case by simply not supporting cpus directly much before about nehalem/bulldozer/goldmont
<geist>
that simplifies the world a lot, since in general it seems that newer x86 cores are getting easier to deal with, more standard, more 'clean'
terminalpusher has joined #osdev
xenos1984 has quit [Ping timeout: 268 seconds]
xenos1984 has joined #osdev
gog has joined #osdev
<heat>
yeah
<heat>
except for s2idle or s0ix which is horrific and broken
<heat>
intel explicitly ditched S3 support since alderlake for $reasons
<heat>
and yes, the implementation of S3 was super messy. but it was mostly firmware and mostly worked
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
wootehfoot has quit [Read error: Connection reset by peer]
puck has quit [Excess Flood]
puck has joined #osdev
<mrvn>
I think idle states probably should be an extension of dynamic frequency policies. And if you can it's probably a good idea to shut down one core after the other and wake them up one after the other. No point in waking up a second core if the first isn't utilized yet.
<mrvn>
If you have bigLITTLE the decisions become even more complex.
Ali_A has joined #osdev
<mrvn>
"When I look at the news I'm not even sure I wanna take over this world."
scoobydoo has quit [Read error: Connection timed out]
<bslsk05>
'95°C is Now Normal: AMD Ryzen 9 7950X CPU Review & Benchmarks' by Gamers Nexus (00:28:50)
<geist>
also addition of AVX512
<mjg>
is that site anyg ood?
<heat>
anandtech?
<heat>
anandtech is pretty good
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
<zid>
7000 has issues with the IHS being so thick
<zid>
it's dropping *20C* on a delid
<zid>
they did it to make AM4 coolers compatible, despite having moved to LGA, which lowers the entire chip down
<heat>
that sounds horrific
<heat>
skip this gen?
<zid>
looks like it unless you wanna delid it..
<zid>
it's a shame, because the silicon itself looks great
<\Test_User>
use laptops, they're pre-delidded :P *runs*
<zid>
yea, the laptop chips will be great :D
<zid>
7950X looks like it will just be 95C under all loads, but just clock higher and higher the more you cool it
<zid>
until it hits the max multi
<heat>
what's up with x86 vendors and upping the power draw?
<zid>
The dies are getting bigger so they're more coolable
<zid>
without hitting 200C inside before the heat hits he IHS
<heat>
apple builds a sleek, efficient arm64 design
<zid>
and.. perf gains are fucked
<heat>
intel and amd draw 200W for your fucking CPU
<zid>
they're just adding more cores and more diespace and more avx
<zid>
12900k is 240W
<zid>
threadripper is 350W on the top model I think, server cpu
<heat>
i know it's disgusting
<zid>
Saying that, my sandy draws 240W too
<zid>
if I clock it to 4.8GHz instead of 3.8GHz
<heat>
at least the 12900k has the E cores too
<zid>
which.. I may have done..
<heat>
i understand perf go brrrr but I don't want a 95C vulcano at my desk
<mjg>
keep it under
<heat>
so it serves as a leg warmer? genius
<zid>
my psu says I go from 83W to 283W when I go from idle to fill tilt
<mjg>
instead of a cat
<zid>
and realtemp shows as 190W
<mjg>
also it wont walk over your keyboard
<\Test_User>
is that considering your room's AC won't handle the 240W and the whole room reaches 95C or that you won't have a proper cooler for it :P
<zid>
that's at 4.4
<geist>
yah the i7-12700k i have here does the same thing (re: run until it hits max therm and then clocks back)
<zid>
What's AC?
<geist>
with the stock cooler i have it literlly slams into 100C within like 2 seconds when running prime95
<\Test_User>
A/C I think is the proper one...
<geist>
because the stock cooler is only designed to dissapate about 65W
<zid>
yea air is *bad* for these chips
<zid>
not enough thermal mass for these crazy spike loads
<\Test_User>
air conditioning iirc is the full name
<zid>
you *really* want an aio just to absorb the shock
<geist>
but that seems to be the new norm: allow the cpu to safely hit the therm and then just dynamically scale back
<zid>
\Test_User: yes, I was saying "I don't have that"
<\Test_User>
ah
<heat>
that seems like the old intel macbook strategy
<geist>
yah it's not new for laptops, it's just now also being applied to desktop cpus
<zid>
geist: if the cpu can even modulate it fast enough, people just aren't going to connect enough copper to the chip to not hit tjmax in a few milliseconds at this rate
<geist>
and keep in mind most of these cases you only hit the max temp if you're wailing on a lot of the cores at the same time
<heat>
on desktops you don't get the free vasectomy though
<zid>
you *really* want an aio on these 250W chips, just so the water can buffer the hits
<geist>
so under normal load where maybe are only pegging a few cores for a bit you are fine
<zid>
nobody uses their desktop to run prime95 all day, an AIO's going to keep you at low temps for a LONG time, water is like.. 800W/hr to heat a degree per litre or something?
heat is now known as _Heat
<zid>
nobody uses their desktop to run prime95 all day, an AIO's going to keep you at low temps for a LONG time, water is like.. 800W/hr to _Heat a degree per litre or something?
<_Heat>
reserved identifier time
<_Heat>
fuck off
<_Heat>
that's illegal per the C standard
<_Heat>
you are not the implementation
<zid>
I am ffreestanding
<_Heat>
nooooooooooooooooooooooooooooooooooooo
<zid>
In other news, this cpu can undervolt quite nicely whilst being overclocked, as long as I keep it reasonable
<geist>
huh interesting they dropped sata from the socket altrogether
<geist>
will have to come out of the chipset
<zid>
3.2 base clock, it'll turbo to 4.2 missing a few tens of mv, 0.8V idle, 1.2V full load
<geist>
PCIe or GTFO
<geist>
(or a few usb ports)
<zid>
I have to pump some voltages that I can't really cool to go past 4.5
<zid>
plus.. power costs are a thing rn
<zid>
intel/amd are creeping up on 1.5V as 'normal' under full load
<clever>
geist: kinda makes sense, a pcie pair can push more then a sata pair?
<clever>
more bang per pin
<geist>
and in general sata is getting replaced with nvme. or the sata you do need doesn't eed to burn up pairs of stuff on the socket because it's intrinsically slower than pcie anyway
<zid>
sata on chipset does make sense to me
<_Heat>
what do you mean with "dropped sata from the socket"
<zid>
it routes better anyway
<geist>
so running sata off chipset is no problem
<geist>
_Heat: did you actually read the article i linked?
<zid>
cpu -> pch -> asmedia chip
<_Heat>
not all of it, no
<zid>
makes more sense topologically, than cpu -> (3 feet of space) -> asmedia chip
<geist>
talking about change of AM5 over AM4
<clever>
geist: i was also thinking, could you run say 16 lanes of gen4 pcie out of the cpu, but then have a motherboard chip split it up into 32 lates of gen3? if the speeds are all right?
<zid>
sata's always bottom right behind the pci-e slots, past the PCH
<zid>
clever: yea it's a PLX and they cost a fortune though
<zid>
it's partially why mobos are expensive now
<_Heat>
geist, my question was more of a "was there sata on the CPU?"
<zid>
along with intel removing the voltage regulators from the CPU
<geist>
_Heat: no
<clever>
zid: ah, and the cheaper boards are just purely passive pcie for the most part?
<geist>
er wait, was as in previous to AM5? yes/
<clever>
at the cost of fewer slots
<_Heat>
so, a "cursed yes"
<_Heat>
modern CPUs are really SoCs arent they
<zid>
clever: yea, which made mobos dumb as hell, 20 native lanes on a modern intel cpu, 16 to top slot, 4 to pch, the end
<geist>
basically the newer AM5 is DDR5 + PCIE + some usb gen 3 + 1 usb gen 2
<clever>
zid: and i expect that you also have the cheaper pcie switches, that give more lanes but create a bottleneck
<geist>
oh and vid
<zid>
but with 24 VRMs because intel removed all the regulators :D
<clever>
where its like 4 lanes in, 16 lanes out, but only 4 lanes worth of bandwidth
<zid>
new intels are like ARM SoCs
<zid>
where you have to make 20 different voltages
<zid>
sandy etc is like "I want vccin pls"
<zid>
so is amd
<clever>
what actually makes it need so many different rails?
<_Heat>
recentish AMDs are more like ARM SoCs
<_Heat>
they have typical chipset shit as MSRs
<zid>
clever: They run the cache, gpu, etc all at different voltages
<_Heat>
documented on the amd64 manual
<_Heat>
intel still does the "here's a bunch of bullshit pci devices"
<zid>
you don't want your 1.4V overclocked core-voltage also powering your memory controller and your L3, etc
<clever>
ah
vdamewood has joined #osdev
<clever>
yeah, i have seen that the bcm2835 has a seperate rail for the dram phy, but the caches and all cores run from the same rail
<_Heat>
ah see
<zid>
nod, but desktop people like to overclock, and you don't wanna cook the cache and shit while you do it
<_Heat>
bcm doesn't always pick the worst option
<zid>
so it makes sense to un-tie those voltages
<clever>
yep
<_Heat>
just 99% of the time
<clever>
so you can roast the L1, but not roast the L2/L3
<clever>
L2 is likely running at a lower clock anyways, so it needs less volts
<zid>
plus it may have fatter traces or whatever
<clever>
the 2835 has 14 seperate BGA pads just for core voltage input
<gog>
call me when there's L7 cache
* gog
pretends to be dead
<zid>
I'm dead for a week anyway
<zid>
honzuki prepub just dropped, gotta wait til monday again
* vdamewood
holds up a dead fish
<clever>
zid: the 2835 is also a bit weird, the core SMPS is in the soc itself
* vdamewood
sets down the dead fishy in front of the dead gog
<clever>
MMIO can freely change the set point, no i2c or other protocol needed
* gog
dead chomps
<_Heat>
at the end of the day the new ryzens have 510 more avx than they had before