<oneforall2>
from what I can track down so far LLVMgold.so has it U LLVMInitializeBPFTarget U LLVMInitializeBPFTargetInfo. was like that for mesa-21.1.7 also
YuGiOhJCJ has joined #dri-devel
slattann has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Duke`` has joined #dri-devel
slattann has quit []
rasterman has joined #dri-devel
Lucretia has joined #dri-devel
gouchi has joined #dri-devel
mlankhorst has joined #dri-devel
danvet has joined #dri-devel
cef is now known as Guest5042
cef has joined #dri-devel
Guest5042 has quit [Ping timeout: 480 seconds]
<sravn>
airlied, danvet - regarding the "Convert to SPDX identifier" patches on dri-devel. I am not confident in the area of licenses to verify if they are correct, as I am not sure what to look for. Any hints or someone you guys take care of?
<danvet>
I've just ignored them thus far
<danvet>
the entire thing landed through backroom channels, and no one yet explained to me why I sould care :-)
<HdkR>
`ioctl(206, DRM_IOCTL_SYNCOBJ_WAIT, 0xe90fa10) = -1 ETIME (Timer expired) ` oops, game just kept trying :P
Company has joined #dri-devel
pcercuei has joined #dri-devel
gouchi has quit [Remote host closed the connection]
gouchi has joined #dri-devel
lemonzest has quit [Quit: Quitting]
slattann has joined #dri-devel
lemonzest has joined #dri-devel
iive has joined #dri-devel
slattann has quit []
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
slattann has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
<sravn>
danvet, yeah, then I will ignore them too for now. There are enough patches in my backlog for actual code changes anyway should I get bored...
slattann has quit []
<danvet>
sravn, yeah as long as we don't run out of actually useful stuff to do I just don't see the point much in more paperworks
thellstrom has joined #dri-devel
mlankhorst has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
gouchi has joined #dri-devel
slattann has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
ayaka_ has left #dri-devel [#dri-devel]
DPA- has joined #dri-devel
DPA has quit [Ping timeout: 480 seconds]
slattann has quit []
DPA has joined #dri-devel
heat has joined #dri-devel
DPA- has quit [Ping timeout: 480 seconds]
slattann has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
slattann has quit []
JTL has quit [Remote host closed the connection]
JTL has joined #dri-devel
shfil has joined #dri-devel
ced117 has quit [Remote host closed the connection]
ced117 has joined #dri-devel
slattann has joined #dri-devel
heat has quit [Remote host closed the connection]
xexaxo_ has joined #dri-devel
camus has quit []
gpoo has quit [Ping timeout: 480 seconds]
gpoo has joined #dri-devel
orbea has quit [Quit: You defeated orbea! 2383232 XP gained!]
orbea has joined #dri-devel
lemonzest has quit [Quit: Quitting]
<robclark>
karolherbst: I'm tinkering with clover (again, finally).. test_basic hostptr is failing because, afaict, clEnqueueCopyImage() is copying from an initialized image.. from the driver side, I see it do a blit but it never transfer_map's the src of the blit.. and because clover is written in a foreign language, I'm failing to see where the hostptr passed to clCreateImage() is supposed to get uploaded.. any hint? Does this test
<robclark>
actually pass on some other pipe driver(s)?
<imirkin_>
robclark: not up on all the latest C++1y features? :)
<alyssa>
shmem vs cma vs neither uhhh
<robclark>
imirkin_: I don't do a lot of C++.. but AFAICT clover tries to use every possible new shiny feature in ways that confound and confuse ;-)
<imirkin_>
robclark: i'm not disagreeing :)
<pinchartl>
imirkin_: do you mean C++-23 ? :-)
<pinchartl>
robclark: I'm reasonably fluent in C++17, but have no experience with clover. if it's just about C++ I can have a look if you point me to the sources
<imirkin_>
robclark: so i'm not sure what your question is
<imirkin_>
robclark: the stuff that code is doing seems to make sense
<imirkin_>
robclark: it receives a cl_mem thingie for the src/dst, and then queues up an op that uses them
<robclark>
pinchartl: well, it is kinda about how clover is all wired together, rather than a "what do these few lines do".. there is much C++ified indirection
<robclark>
imirkin_: so, the src for the copy gets created from root_resource::root_resource().. which *looks* like the place that would upload the user ptr.. but data_ptr==NULL
<pinchartl>
alyssa: you're more than welcome
<imirkin_>
robclark: can you share the full program (or a fragment which identifies the commands you care about)?
<imirkin_>
i.e. the CL program
<pinchartl>
happy to hear you found it useful. sorry to hear that you had to work with DMA and IOMMU though, as it's painful ;-)
<imirkin_>
i don't see why copy image would do a transfer map
<karolherbst>
imirkin_: I think the emulation path is also broken..
<imirkin_>
well, clearly it doesn't use the original host ptr
<imirkin_>
so it can't work *that* well
<karolherbst>
imirkin_: the issue is synching the GPU and host side
<karolherbst>
and I think they can desync at some point
<alyssa>
I'm trying to get a dma_addr_t for my framebuffer.
<alyssa>
There is an IOMMU.
<alyssa>
This should not be this complicated.
<alyssa>
T_T
<karolherbst>
robclark: userptr UAPI is probably the best idea here
<karolherbst>
it's a useful feature anyway
<robclark>
it's a useful feature.. with many dragons ;-)
<karolherbst>
you should be able to map random RAM into your GPUs VM :p
<karolherbst>
robclark: could be
<karolherbst>
anyway.. afk for... probably 2-3 hours or so :D Anyway.. looks like you got your answers though (roughly)
<robclark>
yeah, I guess the answer is to move on to the next test ;-)
<karolherbst>
:)
<imirkin_>
robclark: you wouldn't be the first to reach that conclusion
<karolherbst>
robclark: you can specify the flag for the image tests
<imirkin_>
i believe that's how the current situation arose ;)
<karolherbst>
outside of test_basic
<karolherbst>
and just use something else
rpigott has quit [Remote host closed the connection]
rpigott has joined #dri-devel
* airlied
added hostptr to llvmpipe to pass some host ptr tests recently with imgs disabled
<airlied>
so the emulation is incomplete
<airlied>
even for buffers
<alyssa>
dma_map_sgtable with drm_gem_shmem_get_sg_table maybe ?
<alyssa>
I mean get_pages_sgt
<airlied>
alyssa: do i we want to know why you need it?
sdutt has joined #dri-devel
<alyssa>
airlied: Display is behind an IOMMU. I need GEM allocations to have contiguous IOVAs but not necessarily physically contiguous allocations. Unified memory.
<alyssa>
It's my understand the shmem helpers handle this case (as opposed to CMA which is for the physically contiguous is a must case)
<alyssa>
So, great, I use the default shmem helpers to implement gem create. How do I actually get the IOVA for the object out?
<alyssa>
(Ignoring GEM, if I just dma_alloc_coherent that does what I want)
<alyssa>
Am I... totally misunderstanding how shmem helpers work?
<imirkin_>
i think this is why cma exists... not an expert by any means though.
<alyssa>
imirkin_: as i understand, CMA is when you /don't/ have an IOMMU so you need the allocation to be physically contiguous, which is a harder requirement
sylware has joined #dri-devel
<sylware>
m haanz ping!
Company has quit [Read error: No route to host]
<imirkin_>
alyssa: yes. CMA is contiguous, which you don't need. shmem is, otoh, entirely in cpu memory
<imirkin_>
alyssa: so you need a sgmem variant or something
<imirkin_>
i could be wrong
<imirkin_>
and shmem could be compatible with "proper" iommu's and so on
<imirkin_>
like i said... not an expert
slattann has quit []
Company has joined #dri-devel
<airlied>
alyssa: drm_gem_shmem_get_pages_sgt is correct
<robclark>
alyssa: I think you are looking for sg_dma_address()
<alyssa>
imirkin_: it's unified memory so we can map CPU memory to the device with the illusion of continguous IOVAs
<alyssa>
airlied: ack
<sven>
just fwiw, a sgtable is not guaranteed to be mappable to a single contiguous IOVA allocation
<alyssa>
robclark: ruh roh
<alyssa>
*sven
<imirkin_>
alyssa: ok. afaik you need to be slightly careful when allocating dma-friendly memory. but perhaps shmem helpers are doing that anyways.
<alyssa>
🤷
<imirkin_>
(cache settings, etc)
<alyssa>
yeah idk i'm a kernel noob
<alyssa>
and apparently mesa chops don't trnaslate
<sven>
if you have a sg table with n entries you're only guaranteed that you will get <= n entries after dma_map_sg. and you'll have to use sg_dma_address and sg_dma_length on each of them and feed those to your device
* alyssa
crawls back to userspace
<robclark>
hmm, are there really no other kms drivers using iommu + dma-api?
<airlied>
robclark: not that I can spot using the helpers
<airlied>
at least not for scanout
<robclark>
I guess you can do what drm/msm does and bypass the dma-api.. but I would have hoped that most of the reasons I needed to do that wouldn't apply for simple scanout device
<robclark>
airlied: I think you'd have to look at the dts to know.. since normal iommu <-> dma-api hookup is magic behind-the-scenes thing
<sven>
can't you just use dma_alloc_coherent? that will magically get you an allocation that's contiguous in kernel and device address space and can be scattered all over the place in physical memory
<robclark>
maybe most of the other arm SoC's don't follow qcom's iommu's for everyone approach..
<alyssa>
sven: maybe? I'd have to implement gem_create/map/etc myself then which seems .. odd
sdutt has quit [Read error: Connection reset by peer]
<airlied>
sven: seems suboptimal, if you have an iommu for display
<airlied>
alyssa: I assume this is for the M1?
<sven>
airlied: dma_alloc_coherent will use the iommu
<robclark>
sven: right but shmem helpers don't use that.. they use shmem for allocating pages..
<sven>
hrm :/
<alyssa>
airlied: Yeah
<alyssa>
I thought this would be a good babystep to warm up to KMS but uhhh
<alyssa>
giant baby i guess
<alyssa>
or just very large feet
<mattst88>
I wonder how completely out of date my how-to-write-a-kms-driver tutorial is
<mattst88>
written in 2010
<alyssa>
mattst88: why is this so much harder than how-to-write-a-gallium-driver
<alyssa>
("sunk cost fallacy")
<mattst88>
alyssa: all the reboots :)
<alyssa>
mattst88: oh right
<mattst88>
I'm sure people experienced with kernel development have much more effective workflows than I did
<alyssa>
drm_fb_cma_get_gem_addr seems exactly what I want except.. it's CMA
<mattst88>
but it was just constant rmmod/modprobe cycles for me
<mattst88>
and lots of printk debugging :)
<airlied>
that's pretty much all there is, rmmod/modprobe vs reboot is the biggest call sometimes :-P
* airlied
wasted a lot of time on rmmod/modprobe cycles once when I'd hosed something unrelated, that only a reboot fixed
<airlied>
alyssa: so what does the hw take to scanout from a single VA address in the iommu space?
<alyssa>
"take"?
<airlied>
yeah what's the hw API here
<airlied>
or even the RPC call for M1
<alyssa>
not touching the copro yet
<alyssa>
for the real driver, there's a "swap_framebuffers(planes = [], plane_addresses = [])" call
<alyssa>
which makes atomic updates trivial
<alyssa>
where the plane addresses are I/O VAs
<alyssa>
allocated against a special IOMMU just for framebuffer memory
<alyssa>
(for my toy warm-up driver, I just want to bitbang the plane address register and skip the copro. ALl the allocation issues are identical.)
<airlied>
my expectation here which is possibly wrong because arm, is that
i-garrison has quit []
<alyssa>
I have this IOMMU modeled in the device tree. `dma_alloc_coherent` and setting that dma_addr to the plane address reg already works
<airlied>
drm_gem_shmem_get_pages_sgt should return a single sg entry in that case
<airlied>
if it doesn't then you will need to consider dma_alloc_coherent I guess
<alyssa>
Weee
<alyssa>
I guess I'm v surprised no other driver has to deal with this?
<airlied>
but yeah sven might be right in that it gives you an sg_table with multiple entries which isn't useful for what you want
<alyssa>
IOMMU for framebuffers seems like an obvious setup
<airlied>
alyssa: msm is likely the only one so far
<airlied>
though tegra should as well
<robclark>
alyssa: ignore the CMA in the name.. it is what you need
<airlied>
I think it's more no driver using shmem helpers
<alyssa>
robclark: Oh?
<robclark>
you need contiguous memory in device address space.. the fact that dma_alloc_coherent is using iommu and discontiguous pages vs CMA carveout is all hidden behind dma api
<alyssa>
Ahhhhh
<alyssa>
*that* makes sense
<alyssa>
thank you :)
<alyssa>
will try that
<alyssa>
this is what I get for reading documentation, I guess
<alyssa>
In that case I should figure out this WARN_ON when using CMA
<sven>
ah.. yup. robclark is right :)
<airlied>
so you need the cma helpers then?
<sven>
yeah. just from reading the code they were written under the assumption that there's no iommu
<sven>
but that's fine. the dma-iommu will take care of all that
<robclark>
possibly the CMA helpers should be renamed
<robclark>
to make it more clear it is about contiguous device addresses
<pinchartl>
robclark: I'd really like that. it's indeed not about CMA
<pinchartl>
in V4L2 the contiguous backend for the memory allocator is called dma-contig
<pinchartl>
not sure if it's a good name
Duke`` has quit [Ping timeout: 480 seconds]
<robclark>
"dma-contig" or "device-contig" seems reasonable.. maybe go with "dma-contig" if v4l2 already uses that naming
<alyssa>
device-contig emphasizes it's not about phys contig
<alyssa>
dma-contig does not so clearly
<robclark>
kernel does call device addresses `dma_addr_t`.. so once you have that little factiod dma-contig makes sense
<alyssa>
fair enough
<robclark>
I guess which name makes more sense is path dependent.. did you start out as kernel dev or mesa dev ;-)
<alyssa>
got me! :p
<alyssa>
Technically I wrote my first line of kernel display driver before mesa.
<alyssa>
Technically.
<alyssa>
We don't talk about that driver.
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
<alyssa>
still floating around on the lkml... haunting me...
<airlied>
so it seems you use cma helpers for scanout engines and shmem helpers for render node side
<airlied>
and dma-buf between them
<alyssa>
airlied: sure
<alyssa>
two totally separate IOMMUs so
<airlied>
don't make a single driver on arm for M1 then :-)
<alyssa>
:)
rando25902 has joined #dri-devel
rando25892 has quit [Ping timeout: 480 seconds]
<alyssa>
modetest works
<alyssa>
weston segfaults, wee
sylware has quit [Quit: sylware]
<alyssa>
...why do I not have /dev/input
<icecream95>
alyssa: IIRC that comes from udev
<alyssa>
ack
<alyssa>
gentoo wiki
gouchi has quit [Remote host closed the connection]
<alyssa>
evdev was missing whoops
<alyssa>
now weston starts
<alyssa>
is llvmpipe on M1 faster than panfrost on Mali T860? this is embarassing
i-garrison has joined #dri-devel
<icecream95>
llvmpipe on MT8183 isn't actually that bad compared to its G72 either...
<alyssa>
alas
<alyssa>
I can already see the headline, "Linux on Apple M1 supports OpenGL 4.5 with Mesa drivers"
<alyssa>
It is /technically/ true ;_p
<icecream95>
Is it not 4.6 yet? Maybe you should try Zink + lavapipe?
<robclark>
alyssa: for things that are purely memory bandwidth limited, I could believe that llvmpipe on M1 does better (because moar bandwidth.. and the CPU should hopefully be able to saturate that)
<kisak>
OpenGL 4.5 on llvmpipe sounds accurate
<alyssa>
alas
<sven>
alyssa: fwiw, you're probably running on the efficiency core or a performance core that's still running a very low clock speed
<alyssa>
sven: delightful.
<alyssa>
and probably true, corellium's cpufreq driver didn't cherrypick cleanly
<robclark>
llvmpipe should attempt to be using all-the-cores, fwiw
<sven>
iirc the underclocked performance core is *slow* than the efficiency core at this stage
<sven>
*slower
<robclark>
for UI workloads, all that matters is that you can saturate memory bandwidth (and that memory is sufficiently clocked up.. if you are doing any scaling on that end of things)
<alyssa>
vmware's llvmpipe 2D renderer should help too once that hits distros
nsneck has quit [Remote host closed the connection]
<alyssa>
So, dumb question .... how does page flipping work with atomic KMS?
<alyssa>
Like, are there two drm_framebuffer objects with their own gem allocs, and then plane_update is called every frame to swap?
<alyssa>
okay, that's what I thought.. because I'm not seeing that called every frame (only every mode set change), so I was wondering if I'm confusing myself here
<alyssa>
oh, ok. I see it being called for weston every frame
<alyssa>
fbcon just doesn't do double buffering
<alyssa>
i guess
<robclark>
fbcon is front buffer rendering.. if you thought x11 was crusty, you haven't looked at fbcon yet ;-)
<alyssa>
Oof
<alyssa>
Oh and apparently I'm hitting a WARN_ON every frame. Yayy
<ccr>
it's just a flesh wound!
ppascher has joined #dri-devel
shfil has quit [Ping timeout: 480 seconds]
<alyssa>
heh
rasterman has quit [Quit: Gettin' stinky!]
<alyssa>
robclark: The trouble will be for DCP (the coprocessor) which wants a swap command in its mailbox for every frame
<alyssa>
even if no parameter changed (single-buffered logically, still need an explicit page flip
<alyssa>
(I guess in effect Weston on DCP would be triple buffered)
<alyssa>
I guess any driver that uses shadow buffers has this problem too, so I assume there's a config option I need
<alyssa>
"deferred I/O" is what the KMS docs call it I think?
<oneforall2>
was a coyple of revert patches for mesa to use cmakde instead of conf-tool. I looked at the patch in one tab and org file in the other and it looked like it was patched . but nope o.O
aissen has quit [Read error: Connection reset by peer]
aissen has joined #dri-devel
<robclark>
alyssa: setup a timer to expire ~1ms before next deadline, and flip to the current frame again if you didn't get a new frame in time?
<alyssa>
robclark: smells like a hack :-p
<robclark>
don't you be dissing on apple like that :-P
<alyssa>
how is this apple's fault...?
<robclark>
they defined the fw interface ;-)
<alyssa>
truth
<alyssa>
there's no deadline... if nothing changes on screen, no swap is needed
pcercuei has quit [Quit: dodo]
<robclark>
so, some types of displays (namely dsi cmd mode.. but also kinda edp psr) need you to "push" frames to them for front buffer rendering
<robclark>
I guess you aren't too concerned about supporting iphones at this point
<robclark>
so you can possibly ignore it
<alyssa>
iphones? the m1 macs are big fat iphones.
<robclark>
I'm not aware of any dsi panels big enough for laptop.. and the signal routing wouldn't work.. so I'd expect they are eDP panels
<alyssa>
Oh, fair
<alyssa>
I just have a mac mini so it's all (dp->)hdmi
iive has quit []
<airlied>
alyssa: btw how did ye RE the display regs from behind the DCP copro?
V has quit [Ping timeout: 480 seconds]
rpigott has quit [Remote host closed the connection]
<airlied>
alyssa: it's likely it just keep scanning out the current framebuffer
<airlied>
without needing to send a swap event
<airlied>
except for as robclark says maybe some wierdass dsi panels
rpigott has joined #dri-devel
<robclark>
I wonder how much the fw/coproc does as far as PSR? But w/ hdmi output you should't have to care
<airlied>
I also wonder if the DCP has some interface for dirty rects on current display if even only for fw stuff
<airlied>
MrCooper: tried present from mit-shm backed pixmaps, seems have a stride issue that I don't see with the same pixmap and copy image
<airlied>
oh fixed that one, so we can reuse a lot of the dri3 paths for the "faster" sw path
<airlied>
the question is I suppose of that is going to be best in the cases we care about where we have no hw
macromorgan is now known as Guest5100
macromorgan has joined #dri-devel
Guest5100 has quit [Read error: Connection reset by peer]