<pq>
alyssa, the kernel in general is "anything can happen any time", so maybe you need to ask a more specific question :-)
<alyssa>
pq: in kernel, yeah
<alyssa>
Well, in Mesa we have strong guarantees, e.g
<alyssa>
pipe_context can only be accessed by a single thread at a given time, whereas pipe_screen/pipe_resource may be accessed concurrently from arbitrary threads
<alyssa>
(so you try to move as much state from pipe_screen to pipe_context as you can, anything left on screen needs a mutex but context state never needs a mutex)
<alyssa>
What are the rules for DRM kernel drivers about when things can happen and where?
<pq>
kernel is a whole different land from userland - everything is always by default multithreaded, concurrent and reentrant, unless you explicitly protect stuff with locks etc.
<alyssa>
(If it's truly "anything can happen any time", that would suggest needing to lock absolutely everything..)
<alyssa>
Icky.
<alyssa>
and.. sketchy
<alyssa>
what happens if two different processes try to swap two different frames on-screen at the same time?
<alyssa>
(or two threads in one misbehaved process)
<pq>
many different processes may be calling your ioctls at the same time, etc. so your code better be reentrant and thread-safe
<alyssa>
undefined but I can't crash and must pick one of them to show?
<alyssa>
also, probing -- a device can only be probed once so for the duration of probe() there's no multithreading concerns ?
<alyssa>
(handwaving PROBE_DEFER for a moment)
<alyssa>
(so a configuration data structure that is immutable once probed needs no locks)
<pq>
alyssa, oh but there are things like device hot-unplug
<alyssa>
...platform device probing then 😉
<pq>
if not physically, then via sysfs triggers
<pq>
I'm sure there are DRM locking rules (what lock to take and when), but I have no knowledge of those.
<alyssa>
Okay...
<robmur01>
if you have multiple instances of the device, assume they can probe in parallel ;)
<alyssa>
robmur01: ...pathological
<sven>
aren't there two DCPs on these machines?
<robmur01>
also assume your probe routine can be preempted by anything else
<tagr>
alyssa: typically only one process (i.e. the DRM master) will be allowed to swap frames on-screen, so there's usually not much of a multi-threading problem for purely KMS
<jenatali>
zmike: Re: primconvert, did you already have a plan for a way to avoid us taking an edge flags regression from switching to having st/mesa do it for us?
<pq>
tagr, I'd say that's not something to trust on.
<jenatali>
I don't remember if we settled on something
<alyssa>
sven: yes, there are.
<tagr>
pq: I thought the kernel enforced it
<alyssa>
sven: Although I expect they are two different instances of the driver, too?
<alyssa>
I.e. two unrelated apple_dcp private structures. So no locking between them
<pq>
tagr, the simple counter-example is a multi-threaded process doing KMS calls from multiple threads on the same device. DRM master won't protect from that.
<pq>
tagr, it's not a program design that would do any good, but it also must not be able to crash the kernel.
<sven>
yeah. i just don't know what your probe routine does or if it relies on something shared between these two
<alyssa>
...or crash the copro in this case
<zmike>
jenatali: no, still sort of brainstorming; I think what's probably needed is to start injecting gs in st_program during atom updates
<tagr>
pq: alyssa was specifically saying "two processes", that's what DRM master should protect from
<jenatali>
zmike: Ack. Is that something you're looking at?
<tagr>
but yes, if you've got two threads trying to call KMS that's a different story
<alyssa>
The dcp has the fun interface where you send to a given channel and then sometime later the device acks it.
<alyssa>
..and if you send anything to a channel before a previous message is acked, the copro crashes irrecoverably and the whole machine needs a reboot.
<alyssa>
Isn't that delightful!
<zmike>
jenatali: not urgently? I've been doing a lot of big gallium refactors over the past months and got a bit burned out on it
<jenatali>
zmike: We've got a new senior dev on our team who's going to be ramping up here and I was thinking tackling your primconvert request might be a good starting point, but I'd prefer not to take a (long-lived) regression if possible
<jenatali>
That's fair
<zmike>
I think moving your thing to st_program wouldn't be too much work and could be a good starting point?
<jenatali>
Yeah, might be doable
<zmike>
it's just 1) check supported primtypes 2) check user edgeflags existence 3) check for existing gs 4) inject gs
<zmike>
could even try to hook up a gpu version of primconvert while you're in there :p
<jenatali>
Hah now that's asking for a lot :P
<jenatali>
But yeah we can take a look at that
co1umbarius has joined #dri-devel
<alyssa>
---Wait, speaking of multiple instances.
<jenatali>
zmike: If you're burned out on gallium refactors, does that mean you're not looking to immediately make more primconvert improvements? Or should we still try to get this done soon?
columbarius has quit [Ping timeout: 480 seconds]
<alyssa>
Suppose you have two display controllers, /dev/dri/card0 and /dev/dri/card1. They are each driving their own monitor (say, one HDMI and the other DP). You use a stacking window manager in a two screen view, and drag a window across the seam, so the left half is on HDMI and the right half is on DP.
<zmike>
jenatali: well I've still got MrCooper pounding on my door about glxgears, so at some point soon I'm gonna have to do something
<alyssa>
All of the needed logic, I guess that's the compositors' responsibility?
<tagr>
alyssa: typically you'd expose the two display controllers via a single DRM device
<alyssa>
(The window is some dma-buf, it gets imported to both cards independently and cropped in userspace?)
<jenatali>
zmike: What's wrong with glxgears...? Is that flat shading provoking vertex?
<pq>
alyssa, imports, yes. Crops are for the driver to check that it can handle them (or lack of).
<alyssa>
tagr: ...groan. right. to make my silly example sillier then, what if they are totally independent hardware? like, you connected two separate PCI cards
<jenatali>
Ah, I see
<alyssa>
(from different vendors, to make it spicier)
<alyssa>
(That's not the case here but I do presume it should work.)
<pq>
tagr, display controllers, really? CRTCs yes, but controllers? Do I misunderstand terminology?
<MrCooper>
zmike: I hope you're joking :) I don't really care about this, just happened to notice it
<jenatali>
zmike: Yeah I want that too - I've heard of perf problems with GLOn12 from a similar thing, an app using 8-bit index buffers has terrible perf, switching to 16 improved hugely
<alyssa>
pq: I don't know the terminology myself
agd5f has quit [Read error: Connection reset by peer]
<tagr>
alyssa: right, in that case they'd be separate devices and its up to userspace to do the right thing, the kernel doesn't know about how you use these two devices together
<alyssa>
nod
<tagr>
pq: display controller == CRTC
<tagr>
for me at least
agd5f has joined #dri-devel
<pq>
tagr, so what do you call the whole IP block or chip that has several CRTCs?
<tagr>
pq: it depends... typically you'd call in "the device"
<alyssa>
pq: tagr: In my actual case, the entire display hardware is duplicated on the chip. There are two DCP blocks, two display blocks, respective HDMI/DP encoders, etc. Each DCP has a single CRTC. It would be convenient to write a driver for a single DCP with a single CRTC and just probe two instances of it as specified in the device tree.
<alyssa>
Apple's device tree has everything duplicated, it's literally duplicated silicon. dcp/disp0/dart-disp0 and dcpext/dispext0/dart-dispext0. Thank iPhones.
<tagr>
on most SoCs there will be multiple IP blocks that make up a functional "display device" and you have to compose them in the DRM driver to turn them into something that has CRTCs and encoders/connectors
<pq>
alyssa, I'm no kernel dev, but from userspace point of view it probably doesn't make much of a difference if you expose one or two device nodes. Unless you're running something like Weston which does not know to open more than one KMS device yet.
<tagr>
yeah, I'd recommend trying to cram as much into one device node as possible, because most people will write their software on desktops and expect that the GPU and the scanout devices will be the same
<MrCooper>
yeah, unless there's a good reason for exposing each DCP as a separate KMS device, it'll be easier to expose them as a single device with two CRTCs instead
<tagr>
the whole renderonly infrastructure in Mesa had to be invented to make discrete scanout + discrete GPU look like one so that software could continue to work under the standard assumptions
<MrCooper>
well, maybe not easier in the kernel driver, but everywhere else :)
<tagr>
it depends a bit on the hardware, really
<tagr>
for example some earlier generations of Tegra had some bits of the display controllers coupled, so that the "primary" one had to be enabled (i.e. out of reset and it's module clock enabled) if the "secondary" one was being used
<tagr>
no good way to deal with that kind of dependency if they were two separate KMS devices
<alyssa>
hm, okay
<alyssa>
I haven't looked at the second DCP yet since I only have one (now zero..) monitors and no macbooks but the apple device tree suggests it's 100% independent
<sven>
yeah, i'm pretty sure they literally copy/pasted the entire silicon here and created two entirely independent display controller
<alyssa>
^ as a related implication, the two display controllers have independent IOMMUs
<alyssa>
which complicates drm_framebuffer allocation for a single KMS device with two CRTCs
<alyssa>
this could be worked around by tying the disp0 and dispext0 iommus together, not sure if that would have fallout
Ahuj has quit [Ping timeout: 480 seconds]
<tagr>
alyssa: if you use the DMA API strictly, the IOMMUs should be handled entirely transparently, much the same way they would if they were separate KMS devices
<tagr>
even with explicit IOMMU API usage this should be fairly easy to implement within a single KMS device
hansg has joined #dri-devel
<tagr>
also, even if the two display pipelines are completely independent, that doesn't mean they have to be separate KMS devices
<MrCooper>
multiple CRTCs in a single device are mostly independent as well (in HW designed this millenium that I'm familiar with)
<MrCooper>
in current AMD display HW it's literally identical register sets at different offsets
<tagr>
well, there's still likely some sort of shared resources, if nothing else then at least video memory will be shared
<MrCooper>
indeed
frieder has joined #dri-devel
<tagr>
that stuff is easier to control if it's all within one DRM device because then you don't have to synchronize across multiple devices
<tagr>
especially in SoCs there's plenty of things that need to be synchronized with already
<tagr>
in any case, I don't think combining multiple identical display pipelines into a single DRM device would be significantly different from having multiple DRM devices
<tagr>
but the big benefit is that it'll "just work", as opposed to multiple DRM devices that really just don't work with existing userspace
<tagr>
s/significantly different/significantly more complicated/ is perhaps a better way of putting it, it'll actually be significantly different
<daniels>
alyssa: your 'multiple DCP' is quite common, and the general pattern is that your asahi_drm_drv.c instantiates as many asahi_drm_dcp as you have available to you, bringing them under the same driver instance as disjoint CRTCs/planes/connectors/encoders/whatever
<alyssa>
daniels: 👍
<daniels>
alyssa: re userspace concurrency, yes multiple threads are a threat, but CRTCs are scoped to a single drm_file
mattrope has joined #dri-devel
<daniels>
in the general case, you'll have one DRM master controlling the whole device space; with DRM leases, you can assign CRTCs (with planes+connectors bundled) to separate drm_files, but those resource groups are independent
<daniels>
e.g. you don't have to worry about two processes competing to flip stuff on the same CRTC
<alyssa>
👍
<daniels>
so your locking tends to fall out pretty nicely if you start from the PoV of atomic state
<robmur01>
for controllers-as-CRTCs with their own IOMMUs look no further than good ol' RK3399
<alyssa>
robmur01: ha! fair enough
<robmur01>
(quite possibly some Exynoses too, per my other example by email)
<alyssa>
👍
<alyssa>
robmur01: I sort of wish there was an API in "between" DMA and IOMMU
<daniels>
also look there if you want to see 'we can save 0.002c on the BoM if we only have a single AFBC decoder per-CRTC, so whilst all planes are independently capable of AFBC, only one of them can do it at a time, anyway good luck userspace, I'm sure you'll figure the optimal thing out'
<alyssa>
since the bump in complexity needed to use IOMMU directly is significant and boilerplatey, it feels like
<alyssa>
daniels: RIP
<alyssa>
macOS uses a linear BGRA surface for the cursor (but a compressed planar framebuffer)
<alyssa>
which suggests there might be the same limitation here..
<robmur01>
huh, I thought only VOPB supported AFBC and VOPL couldn't do it at all?
<alyssa>
(OTOH there's probably little benefit to compressing a fixed cursor anyway)
<daniels>
right, cursor is almost uniformly linear
<daniels>
when you say BGRA, I assume you mean GL BGRA i.e. DRM ARGB?
<alyssa>
Yeah
<daniels>
robmur01: I think that one was RK3288, and 3399 supports it on both VOPs but only one decompression unit per VOP
<daniels>
alyssa: phew :)
frieder has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
alatiera has quit [Ping timeout: 480 seconds]
Peste_Bubonica has joined #dri-devel
thellstrom has joined #dri-devel
gouchi has joined #dri-devel
orbea has quit [Ping timeout: 480 seconds]
orbea has joined #dri-devel
camus has joined #dri-devel
Danct12 has quit [Quit: Quitting]
achrisan has joined #dri-devel
sdutt has joined #dri-devel
nchery has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
aravind has joined #dri-devel
oneforall2 has joined #dri-devel
Peste_Bubonica has quit [Quit: Leaving]
aravind has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
JohnnyonFlame has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
sagar_ has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
jessica_24 has joined #dri-devel
<jenatali>
Oof, triple flake in one pipeline run
<robmur01>
alyssa: waaaitaminute... how come the "dedicated steam" for PIODMA isn't simply owned by the DCP device in the first place? Wouldn't that be an awful lot simpler?
ngcortes has joined #dri-devel
Peste_Bubonica has joined #dri-devel
<alyssa>
jenatali: Impressive
<alyssa>
robmur01: yeah still figuring out how to deal with the piodma thing but yes
<alyssa>
I mean
<alyssa>
well, there are two stupid things in the current PIODMA handling
<alyssa>
1) is that dma api wants a device and the laziest way to get the demo working was to add a stub driver just so I could have some device in the DT with the right iommu/stream. this hack needs to disappear regardless.
<imirkin>
alyssa: fwiw nvidia also uses linear surfaces for cursors, with alignment requirements that make 32x32 cursors unrenderable on the hardware (but 64x64 and up would be renderable)
<Lyude>
I think they're not the only ones, although I know on intel the requirements for the cursor plane are a lot more lax (you're still required to do linear surfaces however)
<imirkin>
(i guess my point, without reading the rest of your conversation, is that "cursors are often special")
mlankhorst has quit [Ping timeout: 480 seconds]
* pinchartl
wishes there were less special things
<pinchartl>
no later than yesterday I heard about a "key differentiating factor" that was "present on all devices on the market today"
<pinchartl>
marketing people are special
<pinchartl>
(and on a side note, when technical requirements are driven by "but all people want to have this photo effect on instagram", I get a bad misanthropy relapse)
<imirkin>
pinchartl: you must love advanced blend equations then
<pinchartl>
depends which part of them
<pinchartl>
the math side is fine. the people side is what I have trouble with :-)
<imirkin>
the part where that extension exists
<imirkin>
:)
<imirkin>
might as well call it GL_KHR_instagram i guess?
gouchi has quit [Remote host closed the connection]
<alyssa>
robmur01: got sidetracked before I finished that meessage, uh
<alyssa>
2) is a bunch of questions around how we allocate the PIODMA stream itself.
<alyssa>
^from
<alyssa>
as far as I understand, the API is that "allocate_buffer" allocates DCP memory and "map_buf" maps it for PIODMA
<alyssa>
but it's probably possible to tie the DCP iommu to the PIODMA stream in the DT and make map_buf a no-op that returns the DCP iova
<alyssa>
(cross-device tying with a locked DART needs more patches as sven said on the ML, but it's theoretically doable)
<alyssa>
whether that's desireable from a security/robustness POV, I dunno. not sure what the PIODMA buffers are used for yet, they're for the firmware's use (Linux just has to allocate, map, and in theory unallocate them when the fw says so)
<alyssa>
(=> I don't know whether mapping every DCP buffer for PIODMA use is opening a security hole)
<pinchartl>
there's a firmware that can control the screen while Linux is running ?
<alyssa>
yes
<alyssa>
I mean firmware is a eupehism
<alyssa>
it's a full fledged coprocessor running a proprietary RTOS with what we assume is a fork of older iPhone's display driver
<alyssa>
all Linux gets to see is a mailbox and shmem
<alyssa>
(I am unhappy about this but have mostly made my peace with it..)
<alyssa>
(I don't like free software being denied access to hardware, but what can you do in this case?)
<pinchartl>
lovely
<alyssa>
not really :(
<pinchartl>
I know what I'd do ;-)
<alyssa>
r/e the firmware?
<alyssa>
or sell the Mac and buy another rockchip?
<pinchartl>
not buy an apple machine :-)
<alyssa>
or that
<pinchartl>
they have enough money
<sven>
exploit the co-processor and run linux on there as well :-P
<alyssa>
sven: it only takes one jump table in DCP memory and one page of DCP memory marked executable :-P
<alyssa>
(skip the latter if you want to seem fancy and use ROP)
<pinchartl>
out of curiosity, how are you r/e this ? dumping the mailbox messages when running macos ?
<sven>
pretty much
<Lyude>
alyssa: I mean, nvidia also does display just like this (e.g. where we rarely interact with the hardware directly and just talk to firmware), which means we pretty much just have a command stream we can send
<sven>
these coprocessor also have a syslog and they are pretty chatty when you do something you're not supposed to
<pinchartl>
any idea why it was designed that way, without access to the display controller for the macos kernel driver ?
<robmur01>
the (possibly wrong) impression I got is that PIODMA is just some function of the DCP, which implies that describing it as a separate device sharing memory with the rest of the DCP appears unnecessarily overcomplicated
Emantor_ has joined #dri-devel
Emantor has quit [Read error: Connection reset by peer]
<sven>
i also have that impression, but i've tried to avoid looking at DCP too much for my own sanity
jernej_ has joined #dri-devel
<sven>
pinchartl: your guess is as good as mine. on previous SoCs this used to be a normal kernel driver but then they cut it in half and moved one half to a separate co-processor.
thellstrom has quit [Remote host closed the connection]
* pinchartl
wonders how they have implemented the camera
<Lyude>
latency may be part of the reason
lemonzest has quit [Quit: WeeChat 3.2]
<Lyude>
I know a lot of power management on nvidia GPUs was moved over to firmware mostly for that reason, since it's much faster to be doing power management from a microprocessor on the GPU then it is from the host's CPU
nsneck has joined #dri-devel
<pinchartl>
for the GPU I could possibly understand that. for the display controller... I suppose it depends whether the GPU and the display controller are separate or implemented as a single device
jernej has quit [Ping timeout: 480 seconds]
<robmur01>
but who wants to write complicated kernel drivers when you could keep the platform-specific details in the platform itself? VESA BIOS anyone? :D
<pinchartl>
if you want to cut clocks during h/v blank, doing it in hardware seems a better idea than in firmware (especially for hblank)
<pinchartl>
robmur01: pretty much anyone who has ever dealt with a firmware :-)
<dcbaker>
Everyone just wants to push hard problems up the stack, hardware people say "Solve it in firmware!", fimware people say "solve it in software!", software people say "Solve it in userspace!", and userspace people just complain bitterly :D
<robmur01>
true, but I still like to keep the dream alive!
<Lyude>
pinchartl: an easy example I can think of for where it would make sense with display controllers actually comes from Intel hardware where they don't do this, and it is kind of painful. Like for Intel GPUs (at least during the CML era and earlier) they don't really have a controller display-side to manage watermarks, so you have to try to program them within the timespan of the
<Lyude>
start of the vblank for each frame in order to avoid tearing
Peste_Bubonica has quit [Quit: Leaving]
Peste_Bubonica has joined #dri-devel
<Lyude>
which, works fine until the scheduler isn't in your favor. if they handled that display-controller side though, the vblank deadline would be dramatically easier to hit consistently
<pinchartl>
anything that requires hitting the vblank in the kernel is pretty much game over, yes. not a very good hardware design :-S
Peste_Bubonica has quit []
<Lyude>
(not for -each- frame, there's specific requirements when you need to do this as in some places the hardware is kind enough to have triple buffered mmio registers, but still
<pinchartl>
robmur01: I dream of, one day, telling the hardware people that I have a bug in my driver and that they have to work around it in hardware
<pinchartl>
just to make them feel the pain
<Lyude>
pinchartl: we actually do OK with hitting the vblank deadline for this! I had to do a bunch of work on that for some other stuff on nouveau (nouveau has, a very unusual way of doing CRC readback)
<Lyude>
*nvidia has
<robmur01>
come to think of it, from what I've seen the Mediatek CMDQ is a bonkers counterexample of something in this area which probably ought to be hidden behind firmware but isn't
<Lyude>
it definitely can still be flakey under system load though
<Lyude>
which, is basically as good as we can get
<robmur01>
pinchartl: well, if your "bug" is a speculation exploit... ;)
<pinchartl>
:-)
heat has joined #dri-devel
gouchi has joined #dri-devel
<milek7>
>I don't like free software being denied access to hardware
<milek7>
wasn't there alternate macos driver that pokes hardware directly without DCP?
<alyssa>
yeah, but doing that on linux is impractical (at least for now)
frieder has quit [Ping timeout: 480 seconds]
sagar_ has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
gouchi has quit [Remote host closed the connection]
gouchi has joined #dri-devel
Stary_ has joined #dri-devel
Stary is now known as Guest6209
Stary_ is now known as Stary
<Lyude>
what happened to the rest of the kernel using patchwork?
<Lyude>
(as in, outside drm)
Guest6209 has quit [Read error: Connection reset by peer]
gouchi has quit [Remote host closed the connection]
alatiera has joined #dri-devel
alatiera is now known as Guest6211
gouchi has joined #dri-devel
Company has joined #dri-devel
jewins has joined #dri-devel
<cyrozap>
robmur01: Interesting. I haven't really looked at the CMDQ stuff much--why do you say that it should probably be hidden behind firmware? It's just really complicated/timing sensitive?
JTL has quit [Quit: WeeChat 2.9]
JTL has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
<airlied>
Lyude: don't think there are plan for the "kernel", some parts might use patchwork
ngcortes has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
ngcortes has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
frieder has quit [Remote host closed the connection]
Guest6211 is now known as alatiera
Duke`` has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
gouchi has quit [Remote host closed the connection]