ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
kunal_10185[m] has joined #dri-devel
Mershl[m] has joined #dri-devel
YHNdnzj[moz] has joined #dri-devel
koki23[m] has joined #dri-devel
dantob has joined #dri-devel
dabrain34[m] has joined #dri-devel
tomba has joined #dri-devel
cwfitzgerald[m] has joined #dri-devel
jasuarez has joined #dri-devel
MotiH[m] has joined #dri-devel
K0bin[m] has joined #dri-devel
gnustomp[m] has joined #dri-devel
daniliberman[m] has joined #dri-devel
talcohen[m] has joined #dri-devel
znullptr[m] has joined #dri-devel
ofirbitt[m] has joined #dri-devel
fkassabri[m] has joined #dri-devel
dhirschfeld2[m] has joined #dri-devel
swick[m] has joined #dri-devel
neobrain[m] has joined #dri-devel
tuxayo has joined #dri-devel
devarsht[m] has joined #dri-devel
konstantin has quit [Ping timeout: 480 seconds]
yshui` has joined #dri-devel
T_UNIX has joined #dri-devel
tintou has joined #dri-devel
konstantin has joined #dri-devel
zamundaaa[m] has joined #dri-devel
iive has quit [Quit: They came for me...]
knr has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
KunalAgarwal[m][m] has joined #dri-devel
alanc has quit [Remote host closed the connection]
jhli has joined #dri-devel
Guest6892 is now known as DemiMarie
maxzor has quit [Ping timeout: 480 seconds]
jfalempe has quit [Remote host closed the connection]
jfalempe has joined #dri-devel
luben has joined #dri-devel
alanc has joined #dri-devel
Aura has joined #dri-devel
krumelmonster has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
flynnjiang has joined #dri-devel
krumelmonster has joined #dri-devel
<jenatali>
And there's 4.4 merged and 4.5 ready to go :)
aissen has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
heat_ has quit [Ping timeout: 480 seconds]
pjakobsson_ has joined #dri-devel
pjakobsson has quit [Ping timeout: 480 seconds]
Kayden has quit [Quit: home]
luben has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
aravind has joined #dri-devel
<Lynne>
by the way, ffmpeg 6.1 has been released with vulkan video support, so I invite those bored to run with RADV_PERFTEST=video_decode to cause troubles for me and airlied
luben has joined #dri-devel
Kayden has joined #dri-devel
luben has quit [Ping timeout: 480 seconds]
flynnjiang1 has joined #dri-devel
flynnjiang has quit [Remote host closed the connection]
konstantin has quit [Ping timeout: 480 seconds]
konstantin has joined #dri-devel
airlied has joined #dri-devel
flynnjiang1 has quit [Read error: Connection reset by peer]
YuGiOhJCJ has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
oneforall2 has quit [Remote host closed the connection]
sima has joined #dri-devel
oneforall2 has joined #dri-devel
fab has joined #dri-devel
Duke`` has joined #dri-devel
GreaseMonkey has quit [Remote host closed the connection]
GreaseMonkey has joined #dri-devel
itoral has joined #dri-devel
fab has quit [Quit: fab]
Duke`` has quit [Ping timeout: 480 seconds]
co1umbarius has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
fab has joined #dri-devel
jsa has joined #dri-devel
macslayer has quit [Remote host closed the connection]
kzd has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
Company has joined #dri-devel
glennk has joined #dri-devel
mvlad has joined #dri-devel
tursulin has joined #dri-devel
Ahuj has joined #dri-devel
fab has quit [Quit: fab]
<mripard>
sima, emersion: I don't think using the global CMA heap will work. You might have additional, device-specific, requirements when it comes to where the buffer is that the CMA heap won't address (and won't even know about), so it needs to be tied to the device somehow
<emersion>
can you elaborate on these requirements?
<mripard>
well, it can be as simple as things like the device can only access the lower 128MB of RAM or whatever
<mripard>
so your buffer needs to be within that range to be useful
<emersion>
and that restriction is specific to scanout capability?
<emersion>
what about render and video?
<emersion>
no restriction there?
<mripard>
you can have the same story there
<mripard>
it's all device specific, really
<mripard>
like on Allwinner SoC, the codec is in that situation and can only access the lower 256MB of RAM
<emersion>
if we're talking specifically about vc4 and v3d?
<mripard>
(the older ones)
sgruszka has joined #dri-devel
<mripard>
I don't think vc4 and v3d have those kind of restrictions
<emersion>
ok, so some split render/display SoCs have this
<emersion>
and some not
<emersion>
i see
<mripard>
yeah
<mripard>
so I think your driver-specific heap makes sense
<emersion>
alternatively, we could have a new heap created outside of the driver based on dt info for these "lower than $addr" regions
<mripard>
because then you can tie that to the device that will allocate the memory buffers and make sure that it can access the buffer it allocates
<mripard>
all those constraints are abstracted away by the DMA API
<mripard>
when you call dma_alloc_* it will already make sure those constraints are met
<emersion>
but we will want to express the compat links between heaps and devices at some point
<mripard>
so doing that all over again seems like a huge duplication to me
yyds has quit [Remote host closed the connection]
<mripard>
(even more so since they aren't all expressed in DT)
<mripard>
so you really need the struct device to make your allocation
<mripard>
and for the like between heap and device, the idea swick[m] (I think?) had to make it a sysfs link sounds good to me?
<emersion>
no, sima had this idea
<mripard>
that way you can discover it easily, there's no risk of a name clash, etc.
<mripard>
oh, sorry
yyds has joined #dri-devel
<emersion>
but then you need to draw links between all devices' heaps
<emersion>
instead of between all devices and the central heaps
<emersion>
each device comes with its own heaps, and each device needs to know about each other possible device to advertise the links
<mripard>
yeah, it's kind of the discussion I started in my mails. If you want to completely solve the buffer placement issue, it's much more difficult than just adding heaps
<mripard>
like, there's no guarantee that the producer device and the scanout have the same requirements
<emersion>
it is indeed
frieder_ has joined #dri-devel
<mripard>
and you don't even have a guarantee (aside from HW designers sanity) that the range they can access are overlapping
<mripard>
so you need to aggregate all the constraints of all the devices involved and allocate a buffer there
<mripard>
and we don't have an API for that
<mripard>
also, KMS kind of assume that the DRM device is *one* device when it comes to allocation
<emersion>
sima said that if we have placement constraints via heaps we shouldn't be too far
apinheiro has joined #dri-devel
<emersion>
there is the full buffer constraints proposal sent a few years back by James Jones, but it's pretty complicated and uses heaps anyways
<mripard>
but ARM devices will typically have different devices to access DMA, and again there's no guarantee that all the hardware devices that can access RAM have the same constraintns
frieder has quit [Ping timeout: 480 seconds]
<mripard>
(it's also true for IOMMU mapping)
<mripard>
so we would need a new allocation API that would be finer-grained than the one we have right now
<mripard>
so I really don't think we should aim at fixing that
<mripard>
it's going to be a nightmare
<mripard>
and from a practical PoV, what we have works well enough as it is
<emersion>
this goal is pretty much the reason i'm working on this, fwiw
<mripard>
(or maybe not :D)
<emersion>
if the DMA heaps we create are no better than dumb buffers, maybe we can just stick with dumb buffers
<emersion>
(and tell people running headless or systemd-less to just chmod their primary node lol)
<mripard>
so, yeah, I really think your solution is sound, works well enough to address your immediate needs, and would be a good stopgap measure until we have that discussion again in 5 years :)
<emersion>
aha, because now i think my solution is pretty much unsound :P
<mripard>
is it perfect? No. Do we need perfection? Also no
<mripard>
as long as we provide some way for userspace to discover which heap it should use for a particular device
<mripard>
we can revisit later and change whatever we want beneath it
<mripard>
(famous last words)
<mripard>
but seriously, everything that we would need could be done on device (getting the allocation constraints) or heaps (providing a hint to where the buffer should be allocated)
<swick[m]>
Isn't the question really about what a heap should represent? If it's about encoding all the device constraints etc then you need a heap for almost all devices, bit if it's just about the placement then it's fine to have way fewer heaps but we need to communicate the constraints another way in the fituret
<emersion>
heaps are not designed to represent each and every constraint
<emersion>
they are only designed for placement
<mripard>
oh, right
<emersion>
so stuff like stride or addr align is out of scope for instance
<emersion>
addr lower than given value is a bit of a weird case
<mripard>
constraints should definitely be expressed for a given device, and once we have "hinting" for heaps, then we can just use a global one
<swick[m]>
A specific address range seems like a placement issue to me
<swick[m]>
what's hinting in this context?
<emersion>
in our proposal with James Jones, constraints included a set of heaps
<swick[m]>
I'm still not sure what you actually want to build here...
<mripard>
swick[m]: asking for the buffer to be allocated within a given range
<swick[m]>
So allocating on a specific heap?
yyds has quit [Remote host closed the connection]
<swick[m]>
Oh, hinting to the heap which range to allocate in
<javierm>
but right now it seems that people just create different variants of dma-buf heaps, like the uncached / WC dma-buf healp I shared that Android uses
<emersion>
yeah the discussion there is quite similar to the one we're having now
<javierm>
I also see that vendor trees have other dma-buf heaps that are tailored to the constraints on these platforms
<mripard>
I think we can have something workable if we have something like a) device access constraints in sysfs b) a lib to resolve the constraints of devices we want to "link" together c) some way to tell heaps to allocate a buffer in a particular range
Mary has quit [Ping timeout: 480 seconds]
Rayyan has quit [Ping timeout: 480 seconds]
V has quit [Ping timeout: 480 seconds]
<mripard>
I think Lucas Stach also made some work in this area some time ago
<mripard>
(not sure if he's on IRC)
<javierm>
mripard: I was wondering the other day at what point the DRM/KMS subsystem will need something like the media controller framework that media/v4l2 has
<mripard>
I seriously hope we never do
<javierm>
with kmsro, multiple display and render nodes, dma-buf heaps with constraints, etc
<mripard>
and the media controller API doesn't address that either
pcercuei has joined #dri-devel
<MrCooper>
mripard: AFAIK Lucas' nickname is lynxeye, doesn't seem here right now though
<mripard>
"With version 3, framebuffers are stored in a dedicated contiguous
<mripard>
memory area, with a base address hardcoded for each layer."
<emersion>
... ouch
glennk has joined #dri-devel
kem has joined #dri-devel
mauld has quit [Quit: WeeChat 3.6]
<javierm>
mripard: /dev/dma_heap/fixed_$addr :P
<javierm>
mripard: combining that with a codec like the one you mentioned Allwinner has that requires a dma-buf below a given address would be interesting
<mripard>
like I said, even though we don't always like to admit it, HW designers are sane :)
<mripard>
but in one of those cases, I don't think how you can solve it without a memcpy (assuming the source buffer is accessible by the CPU)
donaldrobson has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
<javierm>
mripard: pretty sure that HW engineers don't consider SW engineers sane looking at all the layers of complexity that create :)
<mripard>
haters gonna hate :)
<javierm>
:D
<enunes>
emersion itoral so I'm finding it quite hard to pass information all the way from the wsi wayland layer to the device specific vulkan allocation, it seems that mesa even uses its own small vulkan extension just to differ wsi allocations from regular vulkan memory allocations
<emersion>
indeed
<enunes>
I think first I'm going to submit a patch just removing wl_drm usage but still relying on the master fd opened at device initialization, that fixes the bug
<emersion>
yeah sounds good
<enunes>
but it still doesn't make use of the dmabuf feedback info
<emersion>
ideally also gracefully handle missing master FD, by degrading to regular allocations
<enunes>
it's a shame because the dmabuf feedback info is right there with the correct device to use, I'm still probably missing something on how it should ideally be used
<dj-death>
jenatali: hey, I tried your suggestion of opt_memcpy for CL structures but that didn't really help
<pinchartl>
javierm: a DMA heap linked to a DT reserved memory region would make sense
<dj-death>
jenatali: most of the variables keep getting lowered to scratch load/store
<pinchartl>
the problem is to figure out what heap to use
<dj-death>
jenatali: if you have any suggestion on how to solve this kind of issue I would be interested to hear them :)
<javierm>
pinchartl: yeah, I didn't know that devices could have constraints as mripard explained
<pinchartl>
javierm: something we've seen for cameras is the requirement for Y and UV planes to be located in different DDR banks
<pinchartl>
to increase memory bandwidth
<mripard>
javierm: to some extent, you did :) the ssd130x driver is so constrained that you have to memcpy from a random buffer into the actual one
<mripard>
(also, not mappable)
<emersion>
pinchartl: oh that's a fun one...
<pinchartl>
emersion: I could imagine a display device having similar constraints
<mripard>
I'm not sure
<mripard>
YUV isn't as prevalent as it is for v4l2 for example
<pinchartl>
it makes more sense for cameras though, as display bandwidth tends to be lower
<mripard>
and multi-planar RGB doesn't really make much sense
<pinchartl>
8k @300fps displays are not that common :-)
<pinchartl>
(yet)
<MrCooper>
javierm: FYI, that simpledrm patch cover letter with no subject being shown in a separate thread is a gmail issue, a decent MUA will show it in a single thread with the patch and follow-ups
jlawryno has joined #dri-devel
<javierm>
mripard: re: ssd130x - hehe, you are correct :)
YuGiOhJCJ has quit [Remote host closed the connection]
<javierm>
MrCooper: it may well be. I use as MUA emacs-notmuch and fetch the email using mbsync, but it could be that gmail mangles the emails and the pulled thread is already broken
YuGiOhJCJ has joined #dri-devel
pcercuei has quit [Quit: brb]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
cmichael has joined #dri-devel
<MrCooper>
the e-mail headers have all the information for proper threading, Thunderbird showed them in a single thread
<javierm>
MrCooper: weird
<MrCooper>
(not using gmail in any way)
<javierm>
there's something wrong though, because mripard has a script to get the emails threads from lore and that failed too for me
<javierm>
but maybe that's a consequence of my MUA breaking the thread
<mripard>
stop telling everyone about the bugs in my scripts :'(
<javierm>
mripard: there's no bug in your script. The threading is what's broken
<mripard>
mutt doesn't follow the threading either though
<mripard>
but In-Reply-To and References are set properly
<mripard>
so it looks fine by me?
<mripard>
but somehow it confuses multiple tools
<mripard>
(lore, gmail and mutt)
<MrCooper>
most likely due to the empty subject?
glennk has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
sgruszka has quit [Remote host closed the connection]
<javierm>
tzimmermann: great and you understood correctly that the goal was to effectively disable damage handling if page flip with a new framebuffer plus damage
<javierm>
but that's the best we can do until there is buffer age or similar buffer damage accumulation tracking
airlied has quit [Ping timeout: 480 seconds]
unerlige has quit [Ping timeout: 480 seconds]
lstrano has quit [Remote host closed the connection]
<jenatali>
dj-death: If you want to paste a nir_print dump, I'd take a look at it. My psychic powers of deduction aren't giving me any more ideas right now though
<tzimmermann>
those links in patch 5 were helpful, thanks
Namarrgon has joined #dri-devel
<dj-death>
jenatali: will try to give an example :)