ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
tzimmermann has quit [Ping timeout: 480 seconds]
<zmike>
mareko: if you get a min I could use a review on !12625 to fix primconvert
<alyssa>
robclark: not sure, no.guess I should look at what macos does
pendingchaos has quit [Remote host closed the connection]
<robclark>
alyssa: I guess at least desktop macos at least uses overlays for cursors.. I would have expected ios to use it a lot more (android defn uses a lot of overlays).. otoh if you just have two planes per crtc (iirc, you mentioned that somewhere?) then maybe they stripped down the display controller compared to the iphone version
<airlied>
robclark: it's the same hw in the iapd
<airlied>
ipad
<airlied>
so doubt there's been any stripping
<robclark>
are you sure it is the same chunk of sand, and not just a tweaked derivative.. phones don't typically (for example) have eDP panels.. and the i/o and peripherals you want differs
<robclark>
if it isn't a derivative then I'd expect unused blocks, and a bunch of external bridge chips and things like that
<robclark>
which, I guess apple has the volume to not do dumb things like that
<airlied>
they stuck a whole coprocessor in, I'm guessing redundant bits isn't a big issue :-P
<robclark>
I mean, the size of something like an m3 is lost in the noise.. adreno a6xx has an extra arm core inside it for power management :-P
<zmike>
robclark: maybe also you on the primconvert MR^
pendingchaos has joined #dri-devel
Lucretia has quit []
<alyssa>
robclark: M1 is the beefed up version of the A14 which was in iphones/ipads/etc
<alyssa>
(late 2020 part)
<alyssa>
but then they released the 2021 ipad with a literal M1 on there (not an A14) so 🤷
<alyssa>
as it is ithings have more processing power than plenty of laptops, and way less software freedom
<robclark>
right, but I would have assumed they would do things like add eDP controller, and possibly delete other things.. I suppose the ipad screen is big enough that it could plausibly be eDP
<alyssa>
ipad is a macbook with digital handcuffs
<robclark>
I mean, ideal chromebook SoC != ideal phone SoC.. there are different requirements.. and apple's big advantage when it comes to things like iphone is they can include just what they need, vs someone like qcom that needs to include blocks that only a subset of it's customers will use
pnowack has quit [Quit: pnowack]
<robclark>
so either it is a phone SoC with a bunch of extra components on the pcb, or it is a variant but with differences
<robclark>
I'd be surprised if apple did the former
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
orbea1 has joined #dri-devel
bcarvalho has quit [Remote host closed the connection]
orbea has quit [Ping timeout: 480 seconds]
orbea1 has quit []
orbea has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
<alyssa>
ideal chromebook SoC includes a midgard gpu
<alyssa>
let me know when qcom has one of those
<alyssa>
🙃
idr has quit [Quit: Leaving]
lemonzest has joined #dri-devel
<robclark>
alyssa: only if you are trying to suck as much as atom/celeron ;-)
<robclark>
but more seriously, there are very different requirements in terms of display/usb/etc connectivity.. like being able to drive multiple external displays
nchery has quit [Remote host closed the connection]
<alyssa>
*nods*
<alyssa>
it should therefore come as little surprise that the first generation apple silicon macs have wacky connectivity issues like not being able to drive multiple external displays...
<alyssa>
robclark: from #asahi:
<alyssa>
01:53 <@marcan> alyssa: that explains why macOS was spitting out cropped/shifted cursor surfaces at one point...
<alyssa>
01:55 <@marcan> it just moves the cursor within the surface instead of cropping it within the src rect
<robclark>
huh, ok.. re-render the cursor.. that is one way to do it..
<robclark>
still, 32x32 granularity of plan position is kinda harsh.. or is that only on plane dimension plus the caveat that it can't extend past the edge of the screen?
Company has quit [Quit: Leaving]
<marcan>
it's min 32x32 crop src, as long as you're there you can position it anywhere on screen
<robclark>
hmm, still, that is ugly for things like video that has oddball resolutions
<robclark>
I guess if you are only ever doing *underlay* maybe that is ok
<marcan>
for a cursor I guess you could just pad it to actual cursor size + 64x64 (32px on all sides) and then it would work
<robclark>
but I kinda had higher expectations for what apple would come up with as far as display controller ;-)
<alyssa>
robclark: lower your expectations for sanity and increase them for raw perf brrrrr
<marcan>
hey at least their clocking is sane so far :p
<robclark>
I mean generally for perf and power you don't want to be constantly falling back to using the gpu
<marcan>
another weird thing is the firmware only lets you blend up to 2 sources but apparently the hardware supports 3? I'm very confused by that one
<alyssa>
and the firmware has slots for 4, of course.
<marcan>
(and the firmware interface supports expressing 4, 3 a version ago, which is even we... yeah that)
<marcan>
otoh it's not surprising this thing sucks at cursors... given it comes from iPhones where there is no cursor :p
<alyssa>
no?
<alyssa>
there should be one :-p
<robclark>
what I'm seeing on higher end android phones is way more than 4 layers.. actually the # of planes seems like a typical thing to scale back on when converting a phone SoC to a laptop SoC..
* alyssa
fondly remembers using a USB OTG mouse on Android in 2016 or so
<robclark>
(but admittedly I'm not an iThing users.. so maybe the UI doesn't benefit from as many layers or something)
<alyssa>
robclark: I'm curious what android uses so many layers for?
<alyssa>
menu bar, app .. what else?
<robclark>
alyssa: `adb dumpsys SurfaceFlinger`
<robclark>
top bar, bottom bar, scrolling of UI elements, etc, etc
<alyssa>
right..
<alyssa>
whereas I guess laptops just yeet it all on the gpu
<marcan>
yeah
<robclark>
qcom even has clever tricks to re-use same hw for overlay for multiple layers (ie. so one plane can do both bottom bar and top bar)
<airlied>
maybe the M1 is so efficient gpu yeeting is fine :-P
<marcan>
robclark: lol, like chasing the raster beam?
<robclark>
marcan: yup
<marcan>
I guess we're back to 80s 8-bit techniques
<alyssa>
that's horrifying
<robclark>
CrOS defn makes less use of overlays.. way more than desktop linux but less than android
<alyssa>
i am now thinking about sprite 0 tests
<alyssa>
i am now thinking about the sprite overflow bug
<robclark>
alyssa: horrifyingly beautiful ;-)
<marcan>
:D
<alyssa>
wrapped my cursor plane code in a TODO_with_cursor and #defined that to zero, will punt on this for now I guess
<alyssa>
much bigger fish to fry right now
<alyssa>
like the fact that I got kernel oopses or freezes or something like that when closing weston...
<marcan>
hey at least it's not the PS4, which somehow managed to keep the IP block of the *previous* generation of GPUs for the cursor... that's the only thing...
<alyssa>
oh, DCP crash, right, even better
<marcan>
(the cursor size is from southern islands, the rest of the GPU is sea islands...)
<emersion>
probably the same case as the switch one
<emersion>
C calls these "labeled statements"
<Venemo>
so this is a clang bug for these labeled statements?
<emersion>
no
<emersion>
this is C for you
<Venemo>
gcc doesn't complain, is that a gcc bug then? or what?
<emersion>
artificial spec limitation which doesn't need to exist for any reason nowadays
<emersion>
maybe gcc is more permissive, or has a GNU extension to allow it by default or something
xexaxo_ has joined #dri-devel
<Venemo>
okay
<Venemo>
so basically the variable declaration is not allowed to follow a label like that?
<emersion>
yea
<emersion>
and an empty statement is enough to fix it
<Venemo>
I can simply move the variable a bit higher up
pjakobsson has quit [Remote host closed the connection]
slattann has quit []
slattann has joined #dri-devel
shfil has joined #dri-devel
thellstrom1 has joined #dri-devel
thellstrom1 has quit []
thellstrom has quit [Ping timeout: 480 seconds]
thellstrom has joined #dri-devel
slattann has quit [Read error: Connection reset by peer]
hikiko_bsd has joined #dri-devel
kevintang has quit [Read error: Connection reset by peer]
kevintang has joined #dri-devel
kevintang has quit [Read error: Connection reset by peer]
kevintang has joined #dri-devel
tarceri__ has quit [Remote host closed the connection]
achrisan has quit []
tarceri has joined #dri-devel
hikiko_bsd has quit [Ping timeout: 480 seconds]
Terman has joined #dri-devel
vivijim has joined #dri-devel
<tagr>
robclark: regarding that IOMMU thread the other day, sorry for being so late to the discussion, but did you ever attempt to run that "keep SMMU in bypass until the driver takes over" using the DMA/IOMMU glue? that's kind of what I tried at some point, but it broke because DMA/IOMMU actually takes over the SMMU context (or address space, domain, whatever you want to...
<tagr>
... call it) *before* the driver gets a chance to get up and running
Hi-Angel has joined #dri-devel
<tagr>
robclark: in fact, it's still what we do, albeit in a bit of a platform-specific way, on Tegra chips that use the ARM SMMU so that we can avoid the fault-by-default behaviour for display in particular (we basically bypass the SMMU externally now, and then only remove the external bypass once the IOMMU has been properly set up)
<tagr>
alyssa: in your case, does the bootloader actually create SMMU mappings for display already? on Tegra it's a bit simpler in that the bootloader doesn't set up the SMMU in the first place, so all we need to do is create an identity mapping for what the bootloader has set up, which I guess is a little simpler that having to inherit an existing SMMU configuration
<tagr>
alyssa: I wonder if that binding that I proposed could be extended to support that use-case, though
<robmur01>
indeed, as I keep repeating, inheriting SMMU config is a red herring specific to a handful of specific firmware setups
<tagr>
robmur01: so are you saying we shouldn't be solving the problem of inheriting SMMU config at all and instead solve the real problem?
* robmur01
still needs to review the IORT RMR series which starts adding some of the necessary glue
<robmur01>
tagr: right, for typical cases like simple-framebuffer the firmware/bootloader is completely oblivious to IOMMUs, but when the IOMMU driver probes it's likely to break scanout by resetting the IOMMU, so it needs to somehow know that a client is (unexpectedly) active at that point. Firmware properties seem like the only reliable/generic option.
<tagr>
robmur01: what do you mean by "firmware properties"?
<robmur01>
as in explicitly describing what's being accessed by whom, like IORT RMRs or your reserved-memory proposal
<tagr>
ah... okay... I had taken a brief look at the IORT RMR spec a long time ago and recall that it seemed like exactly the thing we'd need a DT equivalent for
<tagr>
robmur01: I should probably go look at the patches to refresh my memory
<tagr>
robmur01: there's another use-case that I recently learned of where we need to represent something fairly similar in DT (my understanding is that for some SIDs we need to reserve, but not necessarily map, a certain number of regions of the address space because co-processors load their firmware into those regions)
<tagr>
so it's basically a IOMMU_RESV_RESERVED region rather than the IOMMU_RESV_DIRECT{,_RELAXABLE} that we want for the initial framebuffer
<sven>
tagr: the bootloader creates various mappings (framebuffer, buffer for crashlogs of the display controller co-processor, ...) which probably have to be preserved. (it's also an apple-custom iommu, but that doesn't matter here)
<tagr>
sven: my DT binding proposal is meant to be implementation-independent, so should work with custom implementations, too
<sven>
yeah. that was the memory-regions for identity mappings proposal, wasn't it?
<tagr>
in fact, on earlier Tegra chips we use a custom IOMMU, and I've validated that binding on those as well, it's up to the drivers to properly handle the reserved regions
<tagr>
sven: yeah, exactly
<sven>
if we can extend that to also describe iova->physaddr mappings that would be perfect for us
<tagr>
sven: the only problem that I foresee is that it's basically limited to a <region, flags> pair right now, so I don't think it could be used to convey an actual mapping
<tagr>
right, that's exactly the case that it doesn't support at the moment =)
<tagr>
robmur01: does IORT RMR support passing actual mappings? perhaps there's something we can borrow from there?
lemonzest has quit [Quit: WeeChat 3.2]
lemonzest has joined #dri-devel
Elikka has joined #dri-devel
<sven>
right, would be great if we can come up with something that can express an actual mapping :-)
<tagr>
sven: how much flexibility do you have in generating the content for this in the firmware?
<sven>
a lot. we have our own small bootloader than runs inbetween apple's iBoot and Linux
lemonzest has quit [Quit: WeeChat 3.2]
<tagr>
sven: oh good... that might make things easier
lemonzest has joined #dri-devel
<tagr>
memory-regions is an extension of the existing memory-region binding, so it basically still works with reserved-memory regions
rgallaispou has joined #dri-devel
<tagr>
if you've got a bunch of mappings that are created, maybe one possibility would be to generate an in-memory mapping table and pass that into memory-regions along with a special flag to indicate that this is not in fact a region of memory to do something with, but rather that it's a region of memory containing a mapping
<tagr>
that might be a bit over-engineered, though... perhaps another solution would be to create both IOVA and physical regions as reserved-memory regions and pass them into memory-regions with a flag to indicate whether they represent an IOVA or a physical address region
<tagr>
and then code could iterate over them and pair them up
<tagr>
that's a little brittle because you could have situations where you don't have a physical region for an IOVA region or vice-versa, but that can be fairly easily checked and flagged
<tagr>
also, we do generally have to more-or-less blindly trust the DTB content anyway
<tagr>
anyway, just throwing around some ideas
Elikka has quit []
sdutt has joined #dri-devel
<alyssa>
tagr: what sven said, basically :-p
<tagr>
hm... thinking about this some more, I think this also implies that we need a way to mark reserved-memory regions as virtual so that we can prevent the actual physical pages from getting reserved
<tagr>
oh... I have another idea, I'll ping robher on this in the old thread
<alyssa>
in our case, IIRC all the physical memory that's mapped for display controller stuff (including the initial framebuffer) is in the reserved (top?) of RAM region anyway
<alyssa>
yes, this means a few MBs of waste out of 8GB. no, I don't think Apple has a fix for that....
<tagr>
alyssa, sven : do you want me to include you on the thread?
<alyssa>
yes please
<sven>
sure, that would be great! sven@svenpeter.dev
<alyssa>
conversely the bypass mode trick won't work for display on apple socs -- the display controller uses 32-bit IOVAs but physical memory is 64-bit (well, not 64 but >32)
<alyssa>
alyssa@rosenzweig.io
pjakobsson has joined #dri-devel
Duke`` has quit []
Duke`` has joined #dri-devel
itoral has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<tagr>
alyssa, sven: I've just sent out an alternate proposal that should work for your case as well, hopefully
<tagr>
it'd be great if you could take a look (added you both and dri-devel on Cc)
<tagr>
robher: please also take a look, I think this is a lot closer to what you had in mind
<tagr>
and I think there's enough flexibility there to extend it if we need to support even more use-cases
<sven>
will take a look later, thanks!
<alyssa>
👍
<jekstrand>
Does __iomem matter on ARM? What about PPC?
<robmur01>
tagr: FWIW, no, IORT RMRs are purely about preserving access to physical memory regions - we specifically don't want to support anything more complex than that in the spec, since ACPI systems are supposed to be a lot more "standard"
<robmur01>
jekstrand: in general, yes
<jekstrand>
robmur01: For which one?
<robmur01>
definitely Arm, but most likely PPC as well AFAIK (I'm not familiar with its exact memory types off-hand, but I do know it can be even more sensitive to mismatches than Arm can)
<jenatali>
Besides VMWare, us, and the mesa-dist-win maintainer, is there anybody else I should tag for large Windows-specific changes?
mlankhorst has quit [Ping timeout: 480 seconds]
sdutt has quit []
sdutt has joined #dri-devel
iive has joined #dri-devel
mlankhorst has joined #dri-devel
<tagr>
robmur01: so for ACPI systems the framebuffer would need to be identity mapped? or require an identity mapping once the kernel boots up in case the bootloader doesn't set up an IOMMU at all
<tagr>
robmur01: I suppose for ACPI systems they'd likely be driving an EFI framebuffer, so that's probably got most of the hand-off mechanisms incorporated already
frieder has quit [Remote host closed the connection]
<robmur01>
tagr: yes, the expectation is that UEFI should usually just set up a framebuffer and/or device firmware buffers (the primary use-case) in memory and encode RMRs for them, but not mess with the SMMU itself, and so at the simplest an OS may "accommodate" RMRs by also leaving the SMMU disabled
<robmur01>
SBSA disallows weird setups like the display not being able to access physical memory directly, and ACPI is only for SBSA-compliant systems :)
<pendingchaos>
the GLSL spec doesn't mention a memoryBarrierAtomic() function
<robmur01>
so indeed the main challenge is preserving an identity mapping during SMMU reset, then until binding the proper display driver (if ever)
<shadeslayer>
pendingchaos: thanks, I guess I'll use that as a reference for my MR then
nchery has joined #dri-devel
<robmur01>
extending that to non-identity mappings (for some other firmware mechanism) would be much the same thing conceptually, but there's machinery you'd have to invent (like iommu_resv_regions which are neither identity nor "don't touch")
shfil has quit [Remote host closed the connection]
xexaxo_ has quit [Ping timeout: 480 seconds]
achrisan has joined #dri-devel
nirmoy has joined #dri-devel
<tagr>
robmur01: ah indeed... we currently have no way of storing a non-identity mapping in IOMMUs reserved regions
<robmur01>
if anything, having an active translation as in the Apple case might be simpler to deal with, because if a pagetable *has* to exist then at worst the IOMMU driver can simply scan it. All you strictly need is a way to tell whether the IOMMU state is a valid one from the bootloader, or just leftover crap from kexec/kdump
mattrope has joined #dri-devel
boistordu_ex has joined #dri-devel
shfil has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
Ahuj has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
Erandir has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
flto has quit [Read error: No route to host]
flto has joined #dri-devel
luckyxxl has joined #dri-devel
xexaxo_ has joined #dri-devel
<alyssa>
sven: ^^
<sven>
yeah, that would also work. might be a bit awkward to implement because we'd probably walk the pagetable in io-pgtbl and then somehow export the mappings for get_resv_regions to make iova allocator aware of them i guess
<robmur01>
hey, that wasn't meant to imply it was a *good* idea... :P
<sven>
:D
<robmur01>
just that that approach could be done pretty much entirely privately within the driver, without the core infrastructure needing to know much about it other than punching the holes in the IOVA allocator
<alyssa>
robmur01: Only iffy thing is that all the arm pgtbl #defines (and hence dart pgtbl defines) are private to io-pgtbl-arm.c
mlankhorst has quit [Ping timeout: 480 seconds]
<alyssa>
but if those got moved to io-pgtbl-arm.h we can do that pgtbl walk privately without duplicating all the common bit #defines
<robmur01>
in that context, io-pgtable is part of "the driver" - once you get down into the implementation details indeed the dirt will start to show (it's not like io-pgtable actually supports walking random bits of memory which it didn't allocate, for starters)
jkrzyszt has quit [Ping timeout: 480 seconds]
Ahuj has joined #dri-devel
ngcortes has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
Ahuj has quit [Ping timeout: 480 seconds]
<airlied>
agd5f: please make sure someone reads the Linus reply to my drm for 5.15-rc1 pull request
<airlied>
Venemo: I hit that same variable after a label bug last week, surprised me too :-)
<agd5f>
airlied, ack
<airlied>
agd5f: at least Linus appreciates the gpu names :P
pnowack has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
xexaxo_ has quit [Ping timeout: 480 seconds]
<Venemo>
airlied: yeah it was a suprise
Company has joined #dri-devel
pnowack has joined #dri-devel
Viciouss has quit [Ping timeout: 480 seconds]
jhli has joined #dri-devel
Viciouss has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
Peste_Bubonica has joined #dri-devel
thellstrom has joined #dri-devel
Hi-Angel has quit [Remote host closed the connection]
lstrano has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
sravn_ has quit []
sravn has joined #dri-devel
Bennett has joined #dri-devel
luckyxxl has quit []
cphealy_ has joined #dri-devel
cphealy has quit [Read error: Connection reset by peer]
gouchi has joined #dri-devel
hanetzer2 has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
cphealy_ has quit []
cphealy has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.2]
lemonzest has joined #dri-devel
lemonzest has quit []
Peste_Bubonica has quit [Quit: Leaving]
ppascher has quit [Quit: Gateway shutdown]
lemonzest has joined #dri-devel
lemonzest has quit []
pjakobsson has quit [Ping timeout: 480 seconds]
fahien2 has quit []
tomeu has quit [Quit: Ping timeout (120 seconds)]
shadeslayer has quit [Quit: Ping timeout (120 seconds)]
leandrohrb2 has quit []
padovan4 has quit []
italove has quit []
leandrohrb2 has joined #dri-devel
ppascher has joined #dri-devel
tomeu has joined #dri-devel
shfil has quit [Quit: Konversation terminated!]
fahien2 has joined #dri-devel
padovan4 has joined #dri-devel
shadeslayer has joined #dri-devel
flto has quit [Read error: No route to host]
flto has joined #dri-devel
pnowack has quit [Quit: pnowack]
gouchi has quit [Remote host closed the connection]
iive has quit []
Surkow|laptop has quit [Remote host closed the connection]
Surkow|laptop has joined #dri-devel
vivijim has quit [Remote host closed the connection]
hanetzer has joined #dri-devel
<pinchartl>
is there a way to check in userspace if two fds correspond to the same dmabuf that would be cheaper than fstat() and comparing the inodes ?
<jekstrand>
pinchartl: You can try to import them and see if you get the same gem handle
pcercuei has quit [Quit: dodo]
<pinchartl>
I don't have a display device, this is for the camera side
<pinchartl>
and I doubt GEM import would be cheaper than fstat() (but I like surprises. sometimes)
<imirkin>
pinchartl: fstat is pretty cheap
<pinchartl>
thanks
<imirkin>
(i'm sure that's news to you...)
<pinchartl>
I'll use that, if it ever becomes a performance bottleneck, I'll then figure out an alternative
<imirkin>
anyways, determining if 2 dma-bufs are the same is an annoying problem
<imirkin>
it's an annoying problem for the driver
<imirkin>
i actually don't know that fstat() works
<pinchartl>
on the driver side, you can call dma_buf_get() and compare the pointers, can't you ?