ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
jhan has quit [Ping timeout: 480 seconds]
kitley has quit [Quit: kitley]
kitley has joined #asahi-dev
kesslerd has quit [Ping timeout: 480 seconds]
<chadmed>
jannau: re dcp firmware versioning i think it makes sense to only support 13.2 if it makes your life significantly easier. it's probably also a good releng test case for adding firmware bundle upgrade support to the installer
<chadmed>
on a different topic now that we are getting closer to speaker release it's probably a good idea to merge the codec suspend workaround patches, even if just for tas2764
<chadmed>
it would be silly to regress s2idle because we dont have shared gpio (yet) and even sillier to block speaker support on something so big now that most of the other pieces are in place
<chadmed>
supposedly it still doesnt work on some tas2770 machines but i have no machines with that codec so i cant look into it
nyilas has quit [Remote host closed the connection]
robinp has quit [Ping timeout: 480 seconds]
aomizu has joined #asahi-dev
alyssa has joined #asahi-dev
<alyssa>
chadmed: down the line I think I'm going to want 13.x firmware for AGX
<alyssa>
which introduces the primitives needed to implement geometry/tessellation/mesh shaders properly
<alyssa>
well. "properly"
robinp has joined #asahi-dev
<chadmed>
thats pretty big boon
<chadmed>
its worth investigating while we have the luxury of not having any of this stuff upstreamed i think
robinp has quit [Ping timeout: 480 seconds]
kesslerd has joined #asahi-dev
nuh^ has joined #asahi-dev
kesslerd has quit [Ping timeout: 480 seconds]
<alyssa>
chadmed: by "primitives" i mean "a hack to let compute kernels dynamically allocate memory"
<chadmed>
alyssa: i figured you meant "less hacks" and not "no hacks" :P
<alyssa>
yepyep
<alyssa>
still no geom/tess/mesh support in hw
<alyssa>
but lowering those to compute (sanely) requires a temporary buffer sized according to the # of vertices drawn
<alyssa>
and with indirect draws, that # isn't known at draw call time
<chadmed>
so apple just emulate mesh shaders in metal?
<alyssa>
Yep
<alyssa>
I haven't installed 13.x yet so I haven't seen it in action
<alyssa>
but I took a sneak peek and yeah it doesn't look pretty
<chadmed>
they seem to get decent-ish performance out of it all things considered
<alyssa>
yeah, I mean
<alyssa>
the M1 GPU's whole deal seems to be "just throw a shitton of compute power at it" >.>
<chadmed>
theres no force quite like brute force!
<alyssa>
I sorta expect that a future GPU (maybe M4) will redo the geometry pipeline to allow implementing mesh more efficiently
<alyssa>
given that they're committing to the bit
<alyssa>
AFAICT, that won't come in M3 though
jhan has joined #asahi-dev
<alyssa>
but maybe hardware raytracing in M3
<chadmed>
from what theyve said publicly theyre attempting to be taken seriously as a gaming platform
<alyssa>
hahaha
<alyssa>
yeah, and Mali Chromebooks are a serious gaming platform too (~:
<alyssa>
chadmed: as for brute force... my philosophy for GL/VK features right now is "just implement em all, whatever the cost, because if you don't implement them games won't work, but if you do the hardware is so fricking fast that it'll be just fine"
<chadmed>
i wouldnt be surprised if they slapped all that shit on top of metal 2 so they could go "hey guys look at us wheee" to entice devs and just said "eh we'll do it properly later"
<alyssa>
spent way too long on the commit message lmao
<alyssa>
to quote robher
robinp has joined #asahi-dev
<alyssa>
"How's performance? Great, because I haven't tested it"
<alyssa>
:~)
<chadmed>
hehe
<chadmed>
i mean it is pretty great (except webgl) all things considered
<chadmed>
and theres no point worrying about fastidious optimisation while theres stuff that just like... doesnt work at all
<alyssa>
yep
<chadmed>
"oooh we dropped 3 cycles in the culling pipeline" okay but tetris is a pink rectangle
<alyssa>
which is why I'm kinda motivated to just plough through geometry shaders and get us to GL 3.3 even though GS will suck
<alyssa>
GL 4.0 will be blocked on tessellation though
<alyssa>
tess is going to suuuuck
<alyssa>
not impossible, hell Metal does it, but suck
<alyssa>
not planning to plough through tess, GL 3.3 is the point when I switch gears to Vulkan
<alyssa>
and hopefully get AGXV far enough along that Zink+AGXV is also at GL 3.3 :^)
jhan has quit [Ping timeout: 480 seconds]
<chadmed>
yeah that makes sense, especially with zink
<chadmed>
and aiui vulkan should be a better map to the hardware anyway (geometry and tessellation notwithstanding)?
<chadmed>
or is it much of a muchness
<alyssa>
honestly? AGX is a special snowflake of an architecture
<alyssa>
none of the APIs map closely to the hardware
<alyssa>
not GL, not VK, not D3D, and no, not Metal.
<chadmed>
maybe glide would be a good fit!
<alyssa>
Lol
<alyssa>
AGX is its own API
<alyssa>
:p
<alyssa>
We do something stupid things in the GL driver, we're gonna do some other stupid things in the VK driver, and yeah, Apple does some stupid things in the Metal driver
<alyssa>
but it works out, I mean, the gears spin really fast
<chadmed>
as long as it goes brrrrr i think people will be happy
<alyssa>
yep :)
<chadmed>
hell mine goes brrrr enough to cause coil whine during some glmark2 tests
<alyssa>
even if we have to do some really silly things to get there, we'll be able to implement modern APIs on this chip
<alyssa>
Vulkan 1.3, GL 4.5, OpenCL, whatever
<alyssa>
and via DXVK and VKD3D get the suite of Direct3D apis
<alyssa>
and yeah, even with silly things to get there, the games should run just fine :)
<TellowKrinkle>
64-bit atomics might be pretty painful
<alyssa>
TellowKrinkle: that's definitely an area of silliness yes
<alyssa>
not in GL, optional in CL, fwiw
<alyssa>
and optional in VK
<alyssa>
if we do want to emulate.. I mean, do a mutex... it sucks, but
jhan has joined #asahi-dev
ddi has joined #asahi-dev
<alyssa>
quite frankly atomics can be expected to be so slow (everywhere) that if they're even slower ... meh ...
<alyssa>
this is presumably the logic Apple has in exposing float atomics on M1 as a convenience too
robinp has quit [Ping timeout: 480 seconds]
<alyssa>
(correctly implementing mutexes on GPUs is tricky -- it's really easy to get deadlocks due to the divergence handling -- but not impossible)
kesslerd has quit [Quit: Konversation terminated!]
aomizu has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
jhan has joined #asahi-dev
robinp has quit [Ping timeout: 480 seconds]
zef has joined #asahi-dev
jhan has quit [Ping timeout: 480 seconds]
robinp has joined #asahi-dev
zef_ has quit [Ping timeout: 480 seconds]
robinp has quit [Ping timeout: 480 seconds]
aomizu has joined #asahi-dev
robinp has joined #asahi-dev
robinp has quit [Ping timeout: 480 seconds]
jhan has joined #asahi-dev
jhan has quit [Remote host closed the connection]
robinp has joined #asahi-dev
<alyssa>
uff, but you need to have a common bit of memory associated with the atomic memory to actually spin on
<alyssa>
and since in general you can do atomics on any memory you want.. you need a general mapping of memory to lock
robinp has quit [Ping timeout: 480 seconds]
<alyssa>
although, again assuming the divergence rules work out so you don't deadlock, it should be ok to reuse locks for multiple pieces of memory
<alyssa>
"ok" in the sense of "sound", at the cost of performance obviously
<alyssa>
i.e. it would correct (if terribly inefficient) to have one big global lock to update any int64 atomic
<alyssa>
Or, a bit more generously, hash the address and index into an array of locks accordingly
<alyssa>
seems like there's prior art for doing that anyway
jhan has joined #asahi-dev
<alyssa>
oh but ugh the other issue there is going to be concurrent non-atomic loads
<alyssa>
MSL cheats here
<alyssa>
for full Vulkan shaderInt64 i'd have to check the spec
<alyssa>
yeah I don't feel good about emulating this. is shaderInt64Atomics actually needed? :(
<alyssa>
SM 6.6, bleh
<alyssa>
not needed for DXVK at least
<alyssa>
disappointing that Apple didn't throw in an int64 cmpxchg instruction
aomizu has quit [Max SendQ exceeded]
robinp has joined #asahi-dev
jhan has quit [Ping timeout: 480 seconds]
robinp has quit [Ping timeout: 480 seconds]
jhan has joined #asahi-dev
<alyssa>
(obviously can't prove a negative but yeah)
<chadmed>
is that something youd be able to catch by writing a metal shader that _should_ use a cmpxchg and then decompiling it to see what it's doing?
<alyssa>
no
<alyssa>
(t likely)
<alyssa>
it's not something you can emulate like that
jhan has quit [Ping timeout: 480 seconds]
jhan has joined #asahi-dev
jhan has quit [Ping timeout: 480 seconds]
robinp has joined #asahi-dev
jhan has joined #asahi-dev
robinp has quit [Ping timeout: 480 seconds]
jhan has quit [Ping timeout: 480 seconds]
robinp has joined #asahi-dev
robinp has quit [Ping timeout: 480 seconds]
robinp has joined #asahi-dev
jhan has joined #asahi-dev
<TellowKrinkle>
chadmed: Metal currently supports exactly one int64 atomic operation (min/max), and it ICE's the M1 shader compiler. The MSL spec says "check the feature support doc for information on what GPUs support this operation" and the feature support doc doesn't mention anything about int64 atomics.
robinp has quit [Ping timeout: 480 seconds]
<alyssa>
TellowKrinkle: someone on github seems to think it's added in M2
<TellowKrinkle>
Indeed. I guess I should look into how to run the offline compiler that targets systems that aren't yours
robinp has joined #asahi-dev
robinp has quit [Ping timeout: 480 seconds]
robinp has joined #asahi-dev
<alyssa>
wired up indirect dispatch
<alyssa>
works like a charm
<alyssa>
it's nice working with decent hardware for a change :D
<alyssa>
(and by "just works" I mean "I knew it was coming and architectured a chunk of the driver accordingly which was a PITA to get right but now that's there and indirect dispatch is nice and easy!")
robinp has quit [Ping timeout: 480 seconds]
robinp has joined #asahi-dev
jhan has quit [Remote host closed the connection]
robinp has quit [Ping timeout: 480 seconds]
robinp has joined #asahi-dev
jhan has joined #asahi-dev
robinp has quit [Ping timeout: 480 seconds]
jhan has quit [Remote host closed the connection]
snowcra5h has quit [Quit: WeeChat 3.8]
robinp has joined #asahi-dev
robinp has quit [Ping timeout: 480 seconds]
robinp has joined #asahi-dev
robinp has quit [Ping timeout: 480 seconds]
jhan has joined #asahi-dev
psykose has quit [Remote host closed the connection]
psykose has joined #asahi-dev
robinp has joined #asahi-dev
jhan has quit [Remote host closed the connection]
c10l has quit [Ping timeout: 480 seconds]
robinp has quit [Ping timeout: 480 seconds]
jhan has joined #asahi-dev
jhan has quit [Remote host closed the connection]
jhan has joined #asahi-dev
lewurm`` has joined #asahi-dev
lewurm has quit [Read error: Connection reset by peer]
DarkShadow4444 has quit [Read error: Connection reset by peer]
DarkShadow44 has joined #asahi-dev
DarkShadow44 has quit []
DarkShadow44 has joined #asahi-dev
DarkShadow44 has quit []
DarkShadow44 has joined #asahi-dev
DarkShadow44 has quit []
DarkShadow44 has joined #asahi-dev
DarkShadow44 has joined #asahi-dev
robinp has joined #asahi-dev
robinp has quit [Ping timeout: 480 seconds]
<chadmed>
re schedutil interactivity i dont think there are any real gains to be had anymore just by tweaking CFS and schedutil. the last "big" thing was arm working on util_est to help offset the effects of util decay
aomizu has joined #asahi-dev
<chadmed>
amd are brute forcing their way around this on windows with a driver that just makes non-vcache clusters unavailable when it thinks youre running cache-heavy loads and vice versa which is... an interesting approach
<chadmed>
but one i think is absolutely unacceptable when we have mitigation tools that are yet to be exhausted
<chadmed>
maybe we should talk to the kde eco folks, this seems like something theyd be interested in
altf4_ has joined #asahi-dev
<chadmed>
i also think we're an interesting case in that our cores arent _that_ asymmetrical in terms of performace but are in terms of power consumption
<chadmed>
typically you see ecores at ~half the performance of the pcores but we retain ~70% of the performance
<chadmed>
so the scheduler goes "eh good enough" and throws everything at them
<chadmed>
id like to see what kind of effect EAS has on interactivity on socs with 4 ecores, since theres double the ecore capacity
<chadmed>
the detrimental effect of EAS is very noticeable on m1 pro since the two ecores just end up crammed with tasks
<chadmed>
well, i say "very" in the sense that its noticeably slower but its still snappier than any other machine ive owned
<chadmed>
but basically the only way to fix this is for userspace to start communicating its needs to the scheduler in a more precise way than not at all
aomizu has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<jannau>
those function-pcie_port_control contain just two phandles, to the pcie controller and to the port (pcie-bridge)
<jannau>
I still have found no way to reset pcie ports
robinp has joined #asahi-dev
aomizu has joined #asahi-dev
<sven>
have you tried turning the power on and off? :D
<sven>
sounds like a joke but that’s literally how acio can be reset
spikerguy has joined #asahi-dev
<spikerguy>
Hello Everyone :)
robinp has quit [Ping timeout: 480 seconds]
altf4_ has quit [Remote host closed the connection]
<jannau>
only in u-boot, results in a SError
<jannau>
spikerguy: hej
<spikerguy>
Hi Jannau, Thank you for the irc links
<spikerguy>
Finally I received my Mac Mini M2 :D
<spikerguy>
Now I am looking for debugging tool or diy bom to make one myself. but sadly in my regions components are very diffucult to get.
robinp has joined #asahi-dev
grrowl has joined #asahi-dev
<marcan>
chadmed, jannau: re 13.2, I'm not opposed to forcing people to upgrade, buuut 1) it increases the releng workload, and 2) it's just kicking the can down the road, we *can't* drop firmware version support once upstreamed.
robinp has quit [Ping timeout: 480 seconds]
<marcan>
so I would much prefer if we can support both versions side by side to prove that works
<marcan>
and I would in fact consider it a requirement for upstreaming that we can prove we can handle that
<jannau>
afk/epic looks slighly different in 13.2, shouldn't be a problem to support both but it's annoying
<marcan>
there's always RiiR :D
<jannau>
still considering reimplemnting dcp in rust
<kettenis>
please don't
<marcan>
^ I'll take that as that we should, if only to encourage the BSD guys to start supporting rust ;)
<jannau>
are you planning to reimplement the gpu driver in C? if not I don't see much of a difference between one or two rust drm drivers
<kettenis>
yes, I plan to reimplement the GPU driver in C
<ChaosPrincess>
so, some weird bikeshedding, but why is the dcp driver in drivers/gpu/drm/apple, and the gpu is in drivers/gpu/drm/asahi ?
eiln has joined #asahi-dev
<kettenis>
because they're separate drivers
<marcan>
kettenis: good luck
<chadmed>
different drivers for different hardware blocks
<chadmed>
and alyssa called the mesa driver asahi so it makes sense to keep the kernel driver nomenclature the same
<chadmed>
(also apple was taken by the dcp driver)
<marcan>
there is precedent for calling community reverse engineered GPU drivers (both mesa and kernel side) by project names
<marcan>
(panfrost, etnaviv, nouveau, and now asahi)
<ChaosPrincess>
its more like why not /drivers/gpu/drm/apple OR asahi/{gpu,dcp}
<marcan>
because they are separate drivers
<marcan>
nominally the next level after drm is the driver/module name
<marcan>
it's /drivers/gpu/drm/{i810,i915}, without an "intel" level. Same with radeon and amd (though amd is actually amdgpu but whatever).
<marcan>
and panfrost isn't under "arm"
<kettenis>
traditionally graphics hardware has combined the display controller and GPU in a single chip
<jannau>
adds only another level without having any benefit
<kettenis>
but display controler and gpu are (largely) independent blocks
<kettenis>
and SoC vendors often combine a "standard" GPU (such as ARM's mali GPU) with their own display controller block
<chadmed>
i feel like drilling this distinction into peoples' heads is going to be the hardest part of any hypothetical transition away from the IBM-compatible
<marcan>
I'm tired of repeating it over and over...
<chadmed>
in fact i dont even remember when we stopped calling them "graphics cards" and started calling the whole thing the GPU
<chadmed>
it was some time in the 2010s though
<marcan>
kettenis: we already have 2 display controllers on these machines (missing mipi-dsi for the touch bar) even
<Tramtrist>
we did?
<ChaosPrincess>
in our case its more that it is unlikely that someone will mix a agx with something that is not apple-flavored-mipi or dcp
<chadmed>
i havent heard anyone say "graphics card" in a long time
<chadmed>
they always say "GPU" to mean the entire card
<marcan>
ChaosPrincess: people are already doing it.
<ChaosPrincess>
?
<marcan>
displaylink.
<ChaosPrincess>
oh
<ChaosPrincess>
true
<marcan>
but also the drivers literally have zero in common with each other
<ChaosPrincess>
thanks for reminding me that this cursed thing exists :P
<marcan>
there is zero shared code, zero direct interaction
<marcan>
they know nothing about each other
* sven
really needs to finish display over type c support so that people don’t have to use displaylink :D
<ChaosPrincess>
im more thinking from the point that there is 2, maybe 3 apple drivers at the root level
aomizu has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<marcan>
just like there are several intel, AMD, and ARM drivers
<chadmed>
yeah it doesnt really matter, they are functionally distinct pieces of hardware
<chadmed>
who cares who makes them
<chadmed>
when eiln is done there will be three apple drm drivers!
<ChaosPrincess>
they are doing?
<chadmed>
neural engine
<kettenis>
99% of the transistors on the modern AMD or nVIDIA chips are probably dedicated to the GPU functionality ;)
<ChaosPrincess>
isnt that accel now?
<marcan>
technically not drm, accel framework :p
<marcan>
(which sure is based on drm)
<eiln>
chadmed: i do think it'll get moved to accel though
<chadmed>
oh that happened, neat
<marcan>
kettenis: you underestimate how chonky media encode/decode stuff, general memory interface, etc can be
<marcan>
on M1 Pro, memory+cache+AVE+scaler+APR are significantly larger than the whole GPU by area
<chadmed>
especially now as vendors are starting to tack on AV1 support to all these blocks
<marcan>
(memory/SLC being most of that, but even just display+media stuff is ~half the size of the GPU)
<chadmed>
iirc nvidia cards have two encoding blocks too
<kettenis>
well, media encode/decode is blurring the lines a bit ;)
<marcan>
I measure 56% GPU, 44% everything else
<kettenis>
but I'd say that is graphics processing
kesslerd has joined #asahi-dev
<marcan>
kettenis: bottom left on that navi10 shot is PCIe PHYs, all the wide top/bottom white blocks are RAM interface, lighter blocks along the mid left are probably display PHYs, etc
<marcan>
lots of non-GPU stuff
<chadmed>
maybe we can call navi 31 a true gpu since (most of) the non-shader core stuff got offloaded to the chiplets
<chadmed>
though the infinity fabric phys are pretty big themselves
<marcan>
chadmed: internet says the chiplets are just cache and everything else (GPU+media+phys+etc) is still in a single chip?
<chadmed>
cache and gddr phys yeah, mb
* jannau
needs to finish m2 mac mini hdmi out so we can see how much of the external display out is to be blamed on tipd
<eiln>
i was looking up accel userspace drivers for backend inspo
<sven>
I’m probably gonna bypass that typec altmode subsystem mess and just do what chrome-ec or however it’s called does and manually set the typec muxes
<chadmed>
eiln: i mean thats just begging for an MR adding all that stuff in after reverse engineering it
djorz has quit [Quit: Gateway shutdown]
grrowl has quit [Ping timeout: 480 seconds]
robinp has joined #asahi-dev
robinp has quit [Ping timeout: 480 seconds]
<alyssa>
13:16 < chadmed> and alyssa called the mesa driver asahi so it makes sense to keep the kernel driver nomenclature the same
<alyssa>
13:16 < chadmed> (also apple was taken by the dcp driver)
<alyssa>
chadmed: admittedly I'm responsible for BOTH of those naming choices ;p
<chadmed>
i thought as much :P
<alyssa>
basically just mirroring the split from my chromebook
<alyssa>
rockchip/panfrost
<alyssa>
display controller drivers are boring, just use the vendor name
<alyssa>
3D drivers are spicy, branding matters a lot more, use your project name
<alyssa>
which gives apple/asahi as the split for display/3d
<alyssa>
Possibly it would've made more sense to go with a BSD flavoured "appledcp" name
<alyssa>
frankly when I started typing the drivers (DCP and Mesa) i had bigger problems than the names
<sven>
so you finally admit to writing DCP again? :>
<alyssa>
i mean uhhhhhhhhh
<alyssa>
when JANNAU and SVEN started writing the DCP driver and they asked me, a linux gfx veteran, how names should be chosen
<alyssa>
i responded with what the convention already used for arm socs
<alyssa>
(~:
<marcan>
:D
<ChaosPrincess>
is dcp _that_ cursed
<marcan>
yes.
<alyssa>
yes
<ChaosPrincess>
and is it a bad choice for studying how to write a drm display driver
<chadmed>
i gave up trying to read it very very quickly so yes
<alyssa>
ChaosPrincess: 100%
<alyssa>
try maybe vc4, just ignore the 3D bits
<alyssa>
(vc4 is a combined display+3D driver, except then v3d is 3D-only and uses vc4 as the display half on the newer raspberry pis)
<marcan>
I was going to suggest one of the more recentish bare metal mipi/whatever drivers
<ChaosPrincess>
oh, i tried to go for radeon at first, and dcp was much simplier in comparison :P
<marcan>
okay yeah dcp is a bad choice and radeon is worse
<alyssa>
radeon is the worst choice
<alyssa>
oh, i know
<alyssa>
meson
<chadmed>
radeon first? the one where every patch is like 400,000 lines of autogenerated register definition headers?
<alyssa>
meson is the way to go, I think
<ChaosPrincess>
ty
<alyssa>
display only, straightforward hardwarw
<marcan>
driver from 2016, not *too* ancient
<alyssa>
there's also tinydrm
<marcan>
and seems to actively be getting patches
<alyssa>
but that's not really an option for something like dcp :p
<alyssa>
drm/tiny/
<alyssa>
single file drm drivers
<alyssa>
(e.g. cirrus)
<marcan>
if MIPI panel stuff is involved (which it likely is if this is a bare metal MIPI PHY display controller), you probably want to look at other MIPI drivers and panel stuff for common code, and then you should end up with two drivers (MIPI controller + panel)
<marcan>
quick search suggests rcar-du for a reasonable driver with MIPI
<marcan>
oh actually
<marcan>
kmb? TIL that's a thing
<marcan>
even smaller, seems to only do MIPI
<marcan>
whole driver is ~4400 lines
<marcan>
(1/3 of that is DSI because lol MIPI)
<marcan>
but also given MIPI specs are unobtainium, divining MIPI-isms from other drivers is probably a good idea too
<marcan>
ChaosPrincess: ^
robinp has joined #asahi-dev
<marcan>
alyssa: does that sound reasonable?
<ChaosPrincess>
ok, yea, kmb looks okay
<marcan>
I would expect the actual display controller portion to be fairly dumb, if they only intended it for the touch bar (single plane, no scaling, etc.), though who knows
<marcan>
so there's a good chance most of the work will be the MIPI junk
<ChaosPrincess>
lol
<ChaosPrincess>
nah, it looks to be just a copypasted iphone primary display controller
<marcan>
oh huh... well then... err... isn't that what DCP drives behind the scenes?
<marcan>
or is this like a much older display controller?
<ChaosPrincess>
apple calls it H13G-DFR, while the primary is H13G-DCP, so looks that way
<marcan>
H13G is just the soc codename
<marcan>
there is a driver for disp0 without DCP
<marcan>
it is *much* larger than the touch bar DFR driver
<kettenis>
and gpu/drm/bridge/synopsys/dw-mipi-dsi.c
bisko has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<alyssa>
I once sat next to a Synopsys employee on a commercial flight. He apologized to me on behalf of hardware engineers everywhere.
bisko has joined #asahi-dev
<sven>
:D
robinp has joined #asahi-dev
bisko has quit []
<marcan>
:D
nyilas has joined #asahi-dev
<alyssa>
(Toronto-Boston, apparently Synopsys is based in Boston?)
<alyssa>
nope, Bay Area
<alyssa>
maybe an office there then
robinp has quit [Ping timeout: 480 seconds]
<eiln>
mountain view next to some other techies -- lived near there
<marcan>
ChaosPrincess: I have a suspicion drm/msm/dsi/dsi_phy_7nm.xml.h and nearby files are related to that synopsys core, going by a few apple strings (there aren't many to go by though)
<marcan>
maybe start there
<ChaosPrincess>
thanks
<marcan>
there's also this "slow adaptive clocking" thing which might be an apple thing
<ChaosPrincess>
yea, that sounds apple
<ChaosPrincess>
whatever IOSlowAdaptiveClockingFamily is
<marcan>
oh also lol drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c is a thing.
<marcan>
and yeah okay that matches even better
<marcan>
apple strings: "ST0" "ST1" "DSIM_CORE_PHY_STATUS" from that file: "DSI_INT_ST0" "DSI_INT_ST1" "DSI_PHY_STATUS"
<ChaosPrincess>
whats st0/st1?
<marcan>
status0/status1 I assume, IRQ flags
<ChaosPrincess>
oh
robinp has joined #asahi-dev
<marcan>
so I guess if you're lucky you can use that driver mostly as-is for the MIPI stuff, described in the device tree as a bridge
<marcan>
and then put the apple pipe stuff in front
<marcan>
see also rockchip/dw-mipi-dsi-rockchip.c which is where that came from apparently
<eiln>
just measured 0.0004 sec for 1024x1024 matmul ooo wee
<eiln>
"we have amx at home"
<eiln>
jk it's only really worth it for 100+ dim
spikerguy has quit [Remote host closed the connection]
<ChaosPrincess>
#define HWVER_1310x31333100/* IP version 1.31 */
<ChaosPrincess>
#define DSI_VERSION0x00
<marcan>
nice :)
<ChaosPrincess>
if they haven't broken the impl in some different way compared to rockchip's implementation, then we might just reuse everything
<alyssa>
brave assumption
<alyssa>
have you seen rockchip?
<alyssa>
have you seen APPLE?
<ChaosPrincess>
i own a rk3588 sbc :P
<alyssa>
oof, I'm so so sorry
<ChaosPrincess>
well, aside from the wtf-kernel that radxa ships, it isnt taht bad
<marcan>
FWIW, I've seen a patch on the rockchip list that generalizes basically every register and specializes it per hwver because apparently that driver might just be quite broken depending on the version :p
<alyssa>
it is to me
<marcan>
you may want to do some patch archaeology and see what never got upstreamed
robinp has quit [Ping timeout: 480 seconds]
<ChaosPrincess>
well, its the same hwver
<ChaosPrincess>
the lowest byte is masked out
<marcan>
that HWVER is not an expected HWVER
<marcan>
it is a threshold
<marcan>
to change certain behavior in the driver
<marcan>
but apparently those conditionals may not be sufficient to be strictly correct
<sven>
I love how just everyone runs into things that are pretty broken :p
eiln has quit [Remote host closed the connection]
<ChaosPrincess>
kinda weird - they are only sending backlight control commands over that mipi link
djorz has joined #asahi-dev
robinp has joined #asahi-dev
robinp has quit [Ping timeout: 480 seconds]
amarioguy has joined #asahi-dev
jhan has quit [Remote host closed the connection]
robinp has joined #asahi-dev
jhan has joined #asahi-dev
user982492 has joined #asahi-dev
jhan has quit [Ping timeout: 480 seconds]
robinp has quit [Ping timeout: 480 seconds]
jhan has joined #asahi-dev
kesslerd has joined #asahi-dev
jhan has quit [Ping timeout: 480 seconds]
___nick___ has quit [Ping timeout: 480 seconds]
jhan has joined #asahi-dev
Z751 has joined #asahi-dev
jhan has quit [Ping timeout: 480 seconds]
___nick___ has joined #asahi-dev
robinp has joined #asahi-dev
kesslerd_ has joined #asahi-dev
Z751 has quit []
kesslerd has quit [Ping timeout: 480 seconds]
alyssa has quit [Quit: leaving]
robinp has quit [Ping timeout: 480 seconds]
jhan has joined #asahi-dev
robinp has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
robinp has quit [Ping timeout: 480 seconds]
jeffmiw has quit [Remote host closed the connection]
jhan has quit [Ping timeout: 480 seconds]
jeffmiw has joined #asahi-dev
luc has joined #asahi-dev
luc has quit []
robinp has joined #asahi-dev
robinp has quit [Ping timeout: 480 seconds]
jhan has joined #asahi-dev
D-Spirits has joined #asahi-dev
user982492 has joined #asahi-dev
jhan has quit [Ping timeout: 480 seconds]
jhan has joined #asahi-dev
nopeslide1 has quit []
robinp has joined #asahi-dev
jhan has quit [Ping timeout: 480 seconds]
nopeslide1 has joined #asahi-dev
robinp has quit [Ping timeout: 480 seconds]
amarioguy has quit [Ping timeout: 480 seconds]
jhan has joined #asahi-dev
jeffmiw has quit [Ping timeout: 480 seconds]
jhan has quit [Ping timeout: 480 seconds]
jhan has joined #asahi-dev
robinp has joined #asahi-dev
robinp has quit [Ping timeout: 480 seconds]
jhan has quit [Ping timeout: 480 seconds]
nyilas has quit [Remote host closed the connection]