ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
shashanks__ has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
kts has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
yyds has joined #dri-devel
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
camus has joined #dri-devel
kts has joined #dri-devel
gildekel has quit [Quit: Connection closed for inactivity]
kts has quit [Ping timeout: 480 seconds]
yuq825 has joined #dri-devel
crabbedhaloablut has joined #dri-devel
veryclosed has joined #dri-devel
Dark-Show_Pi4 has joined #dri-devel
<veryclosed>
I remember graphitemaster saying how monkeys will eat each other , first of all i am not even considered a monkey with all the offshore science, they studied my bones and their shapes always looked a bit different than for others, and the blood group is also likely a- which is more of an alien genotype, but i have different theory about that, third of all those were male obnoxious stalker abuse bullies, yet horrible at
<veryclosed>
any performance who cause they whole tourism island to bleed empty, and really they are much hated as of now, by anyone. And such blokes will get physical treatment anyway. They were harassing all my friends and businesses. Khmers do not like that their high end tourism magnet islands stay out of business. So first thing they will look at is to get abusers out of there, who distract tourists, i am just clapping hands for
<veryclosed>
it, totally mind ill people i faced there doing just that. Khmer military there might be quite strong, accounted that when a large conflict happens they will ally with vietnam and thailand and myanmar even and lao and such. They did already aimed guns out anyhow to major nasty folks disturbing tourism.
loki_val has joined #dri-devel
crabbedhaloablut has quit [Read error: Connection reset by peer]
veryclosed was kicked from #dri-devel by ChanServ [You are not permitted on this channel]
<kode54>
I remember one channel I was once in banned the entire city of Toulouse from their forum because of one ban evader
<kode54>
just, up and grabbed all the IP ranges for the city wide ISP and added them all to a huge ban block
<airlied>
we used to ban all of estonia
<Dark-Show_Pi4>
zmike: Commit 2978b85789cb1d5847c88c17dc6ce8fdaa1e8cfd has broken zink support on the Pi4 with "ZINK: vkCreateDevice failed (VK_ERROR_FEATURE_NOT_PRESENT)" removing the lines added with that commit re-enables support.
youresuicidal has joined #dri-devel
bmodem has joined #dri-devel
<youresuicidal>
I generally remind you, how all your trash got banned from freenode, hahaaa, all your birth bully abortion leftovers, literally all. I would not say those words, you still halt the worlds computing cause your skills and behaviour is not something considered high end class.
youresuicidal has quit [Quit: Leaving]
yogesh_mohan has quit [Ping timeout: 480 seconds]
hch12907 has joined #dri-devel
<hch12907>
I think the spamming has gotten worse lately
pekkari has joined #dri-devel
alarumbe has quit [Ping timeout: 480 seconds]
Danct12 has quit [Quit: What if we rewrite the code?]
Danct12 has joined #dri-devel
Daanct12 has joined #dri-devel
<kode54>
you can probably ban that whole /64
Danct12 has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
fab has joined #dri-devel
Danct12 has joined #dri-devel
yyds has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
yuq825 has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
aravind has joined #dri-devel
itoral has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
tzimmermann has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
sgruszka has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
mvlad has joined #dri-devel
habernir has joined #dri-devel
habernir has quit []
Dark-Show_Pi4 has quit [Quit: Leaving]
pekkari has quit [Ping timeout: 480 seconds]
pekkari has joined #dri-devel
pochu has quit [Ping timeout: 480 seconds]
Dark-Show_Pi4 has joined #dri-devel
novaisc has quit [Remote host closed the connection]
grillo_0 has quit [Remote host closed the connection]
tales-aparecida has quit [Remote host closed the connection]
gcarlos has quit [Remote host closed the connection]
tonyk has quit [Remote host closed the connection]
mairacanal has quit [Remote host closed the connection]
sima has joined #dri-devel
qyliss has quit [Quit: bye]
pochu has joined #dri-devel
qyliss has joined #dri-devel
qyliss has quit []
qyliss has joined #dri-devel
i-garrison has quit []
kzd has quit [Ping timeout: 480 seconds]
i-garrison has joined #dri-devel
An0num0us has joined #dri-devel
Dark-Show_Pi4 has quit [Quit: Leaving]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
yogesh_mohan has joined #dri-devel
tursulin has joined #dri-devel
vliaskov has joined #dri-devel
Daanct12 has joined #dri-devel
mvlad has quit [Remote host closed the connection]
rasterman has joined #dri-devel
ndufresne has quit [Quit: Ping timeout (120 seconds)]
nuclearcat2 has quit [Quit: Ping timeout (120 seconds)]
sre has quit [Quit: Ping timeout (120 seconds)]
nuclearcat2 has joined #dri-devel
ndufresne has joined #dri-devel
sre has joined #dri-devel
<MrCooper>
soreau: both drmModeAddFB calls use the same handle, so both FBs reference the same underlying BO
<MrCooper>
to be clear, they need to reference BOs for page flipping to have any effect
<MrCooper>
*different BOs
lynxeye has joined #dri-devel
pcercuei has joined #dri-devel
pcercuei has quit []
pcercuei has joined #dri-devel
<soreau>
MrCooper: thanks for the clarification
pekkari has quit [Ping timeout: 480 seconds]
bnieuwenhuizen has quit [Quit: Bye]
bnieuwenhuizen has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit []
mvlad has joined #dri-devel
Dark-Show_Pi4 has joined #dri-devel
<pq>
FB is a wrapper with some metadata and points to a BO, which points to the piece of memory containing the pixels.
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
<linkmauve>
Are BO and GEM handle synonymous? I recently wrote a DRM client which didn’t use gbm at all and didn’t encounter the BO terminology anywhere.
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
<pq>
linkmauve, depends on the context
<tzimmermann>
javierm, jfalempe, do you have comments on https://lore.kernel.org/dri-devel/20230920142535.19321-1-tzimmermann@suse.de/T/#t ? i've updated the format helpers with an extra argument that stores the internal buffer; including preallocation. this might improve performance slightly, but most of all it allows to avoid kmalloc during in drm_panic. with the right setup, it will also be possible to blit glyphs directly into the
<tzimmermann>
scanout buffer. only a minimal amount of tmp memory will be required for drm_panic
<pq>
linkmauve, here we are talking about a GBM app, so a BO is a gbm_bo, and a detail unmentioned is that you get a GEM handle out of the BO to create a DRM FB.
<lynxeye>
linkmauve: A GEM handle is the userspace reference to a GEM object, which is what is usually called a buffer object or BO for short in kernel context
<jfalempe>
tzimmermann, I'm still protyping the changes to make drm_panic draw line per line.
<linkmauve>
I have read that text, but I’m still not sure about the lifetimes of either object. The fd will be usable until I close() it, but is the handle’s lifetime tied to the fd’s in my process?
<pq>
no, the handle needs to be closed explicitly
<jfalempe>
tzimmermann, I'm also considering doing in-place conversion, as I need a buffer to write xrgb8888 data, and if the destination format is 32bits or less, it would be better to convert in place.
<linkmauve>
drmCloseBufferHandle() under it?
bbrezillon_ has joined #dri-devel
<tzimmermann>
jfalempe, ok. glyph-by-glyph might easier
bbrezillon_ has left #dri-devel [#dri-devel]
<pq>
linkmauve, yes. But drmCloseBufferHandle() simply closes the handle without any reference counting.
<jfalempe>
tzimmermann, Also I planned to call directly line functions like drm_fb_xrgb8888_to_rgb565() because I don't have framebuffer or clip objects in drm_panic.
Dark-Show_Pi4 has quit [Ping timeout: 480 seconds]
<linkmauve>
My current usecase is I get a fd from V4L2’s EXPBUF, get a GEM handle for it, to import into a DRM framebuffer, so only a single process is involved for now.
<tzimmermann>
jfalempe, right. you can use existing format helpers for conversion. drm_fb_blit() copies a framebuffer into a scanout buffer. and it convert the format if necessary.
<linkmauve>
Eventually I will let the user of my decoding library decide whether it imports the fd in DRM, or in EGL, or in mmap().
<linkmauve>
So if I don’t import it into a DRM framebuffer, that is if I don’t drmPrimeFDToHandle(), there is no handle created and thus nothing to close either?
<tzimmermann>
jfalempe, the glyph is a bitmap IIRC. if you set the input framebuffer to DRM_FORMAT_R1 and point the src data to the glyph buffer, it should be possible to draw the glyph directly into the output
<linkmauve>
Except if EGL did that for me behind the scenes, but then I don’t have to care either because EGL does its stuff.
<pq>
linkmauve, even so, if you happen to import the same buffer again, and you already have a GEM handle for it, you will get the *same* handle. If you then close the handle once, it's gone for the both fds.
<tzimmermann>
the format conversion is implicit. if the output buffer is already in _R1, no conversion would happen
<jfalempe>
tzimmermann, yes that's how fbdev work, it consider the glyph as a 1bit image.
<pq>
linkmauve, yes, no need close if you didn't get a handle in the first place.
<tzimmermann>
and for the format conversion, you'd only need a few bytes of temporary memory. with the new patchset you can preallocate that easily.
<pq>
linkmauve, the problem is, if you call FDToHandle, and EGL internally does FDToHandle, then both you and EGL have the same handle. If one of you closes the handle, also the other loses the handle.
<tzimmermann>
the format-helper tests in tests/ have some examples on how to make a 'fake' framebuffer to use with the format-conversion API
<linkmauve>
pq, how do I make sure two fds are for a different file description btw?
<pq>
...on the same fd, or a different fd pointing to the same kernel BO
<tzimmermann>
(the current api could be better, i guess)
<pq>
linkmauve, you don't, really.
<pq>
that's why you should use GBM for all fd-to-handle purposes, so it does the reference counting right.
<pq>
linkmauve, I don't think it matters whether the file description (nor file descriptor) are the same or not. What matters is which kernel BO they point to.
<linkmauve>
Would you recommend that even if I only import the buffers to a framebuffer? In order to avoid maybe reusing the same buffer from V4L2?
<pq>
linkmauve, you said you were writing a library that might sometimes import to EGL instead.
<linkmauve>
Ideally I don’t know what the user is doing.
<pq>
linkmauve, do you also expose the dmabuf fd or some other handle to your library users?
<linkmauve>
Currently I only give the dmabuf fd yes, alongside the required metadata to import it.
<linkmauve>
Size, format, modifier, offsets, strides.
<pq>
linkmauve, so, your users could be calling FDToHandle without you knowing.
<jfalempe>
tzimmermann, ok, I'm looking into that, (and I will review your patches too).
<linkmauve>
Yes.
<tzimmermann>
thanks
<pq>
linkmauve, if your lib, or the user, then closes the GEM handle, both will lose it.
<linkmauve>
Speaking of which, I don’t even know when it’s ok to reuse the buffer for the next V4L2 request.
<pq>
linkmauve, the only remedy is that everyone must be using GBM for getting a GEM handle from a dmabuf fd.
<linkmauve>
My library should never actually deal with GEM handles, the user should.
<pq>
GBM is the one that reference counts then properly, and it also works if you import to EGL, since EGL internally uses it too.
<linkmauve>
Right.
<pq>
ok
<linkmauve>
Hopefully my library will limit itself to handing out buffers from V4L2, and that’s it, but I think I still need to know what the user does with them in order to reuse them or not.
<pq>
btw. in general buffer re-use is recommended, because freeing and allocating is heavier. Ideally you do all the imports and handle conversions once, and then in steady state just switch between what you have.
<linkmauve>
Perhaps I need to have an API function which the user calls to release the buffer, or something.
<linkmauve>
Yup, I could see that while tracing, REQBUFS takes some millisecond or so.
<pq>
yes, you will need some kind of sync mechanism
bbrezillon_ has joined #dri-devel
<pq>
if you also support resize, you might want to have buffers individually created and destroyed as needed, rather than a whole "swap chain" at a time.
<linkmauve>
I’m currently focusing on image formats (I have static opaque lossy webp implemented already, yay!), but those include videos nowadays.
sgruszka has quit [Remote host closed the connection]
kts has joined #dri-devel
<mlankhorst>
Lyude: should i expect a whole lot of nouveau commits in drm-misc-next?
kts has quit [Quit: Leaving]
kts has joined #dri-devel
Haaninjo has joined #dri-devel
<jani>
where's a no-nonsense guide to deploying documentation from a fdo gitlab repo to pages?
<jani>
pq: but I guess you first need to have a container registry or something something?
<jani>
pq: those lines have stuff like "- .fdo.suffixed-image@debian"
<Venemo>
why do we even bother with Mesa 23.2 at this point? why not just go straight to 23.3
<pq>
jani, yes, if you want to. Or you don't, and run some generic container that where you create a public/ dir any way you want.
<ishitatsuyuki>
Venemo: context for 23.2 vs 23.3?
<pq>
jani, every project has a container registry. Weston uses ci-templates to create and re-use custom containers.
<Venemo>
ishitatsuyuki: well, Mesa 23.2 hasn't had a final release yet and the branch point for 23.3 is very close now, isn't it?
<ishitatsuyuki>
ok, I see
<Venemo>
maybe I am missing some context on what happened with 23.2?
<jani>
pq: I'm just looking for a basic guide with simple steps to get this done, from scratch, on a new project. zero experience in gitlab workflows, some experience in github workflows
<pq>
There are the gitlab docs, but I suppose those are not what you want.
<jani>
pq: maybe I just need to set aside more time to peruse them. seem a bit exhausting :p
<jani>
pq: after that, the weston yml will probably be helpful, thanks
<pq>
jani, is the hypothetical project already having CI running in any way?
<jani>
pq: nope, nothing at all
<pq>
ok, I think that should be the first step then. Look at pages as a second step.
<pq>
as in, decide where and how you want to get your containers from
rpigott has quit [Remote host closed the connection]
ella-0 has quit [Remote host closed the connection]
ifreund has quit [Remote host closed the connection]
sumoon has quit [Remote host closed the connection]
kennylevinsen has quit [Remote host closed the connection]
kchibisov has quit [Remote host closed the connection]
rosefromthedead has quit [Remote host closed the connection]
rpigott has joined #dri-devel
ifreund has joined #dri-devel
kennylevinsen has joined #dri-devel
rosefromthedead has joined #dri-devel
ella-0 has joined #dri-devel
kchibisov has joined #dri-devel
sumoon has joined #dri-devel
<koike>
Hi sima o/, a few drm/ci patches were sent to the list with A-b's, I would like to check with you about the workflow, who should pick those patches up
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
shashanks_ has quit [Remote host closed the connection]
<mlankhorst>
Lyude: Ok that's fine, I just wanted to know all the nouveau commits in drm-misc-next were intentional before making a new pull request. :)
<Lyude>
yeah it's intentional! :)
<sima>
Lyude, so time for a MAINTAINERS update to add drm-misc as nouveau repo?
<sima>
maybe also add the new volunteers there if that's not yet done
<sima>
can also just add as reviewers
loki_val has quit []
<mareko>
karolherbst: can rusticl use PIPE_CONTEXT_COMPUTE_ONLY?
<karolherbst>
last time I tried it was broken in radeonsi
<mareko>
it works on CDNA
<airlied>
but it should definitely use it
<karolherbst>
but I kinda want to rather have screen flags also for other things
<pepp>
karolherbst: I tried a while ago and it worked fine
<karolherbst>
mareko: I think something was broken with the compute blitter, but I can check again
<mareko>
karolherbst: pipe_context::blit isn't supported by compute-only contexts
<karolherbst>
yeah.. it wasn't through the blit method
<mareko>
regardless of the method
<karolherbst>
just accelerated resource/image copy things using compute instead of 3D
<mareko>
compute-only contexts can only use util_compute_blit at the moment
<mareko>
which implements a subset of pipe_context::blit
<karolherbst>
right... but CL doesn't have API blits anyway
<karolherbst>
all I know is that some GPU accelerated shader based resource copy path wasn't working correctly
<karolherbst>
but that was like last year probably
<karolherbst>
I'll check with the CTS and report back
<mareko>
if si_compute_copy_image returns false, we should look into it
<karolherbst>
any specific reason you are asking, or just being curious here?
<mareko>
karolherbst: yes, it's a long story, you can also set PIPE_CONTEXT_COMPUTE_ONLY if PIPE_CAP_GRAPHICS returns 0, otherwise CDNA will refuse to create a context
<karolherbst>
ahhh
<karolherbst>
right.. CDNA was entirely without 3D support
<karolherbst>
yeah, makes sense
<karolherbst>
okay, if I don't run into any bugs, I'll just set PIPE_CONTEXT_COMPUTE_ONLY, otherwise I'll check for PIPE_CAP_GRAPHICS
<karolherbst>
but seeing some errors in dmesg "amdgpu: failed to get a new IB (-512)" and "amdgpu: failed to clear page tables on GEM object close (-512)"
<mareko>
karolherbst: that's probably a result of the hang/reset
<karolherbst>
even after a reboot?
<mareko>
I see
anholt has quit [Remote host closed the connection]
<mareko>
we shouldn't see those results after reboot
<karolherbst>
but I did a warm reset, so maybe some leftover state on the hardware
<zmike>
dcbaker: yes
<dcbaker>
zmike: 👍️
mbrost has joined #dri-devel
<karolherbst>
mareko: besides that the CTS is clean
<karolherbst>
only saw those messages right at the beginning
<mareko>
ok good
<karolherbst>
ehh wait... I think I removed my commit setting COMPUTE_ONLY
unerlige has joined #dri-devel
fab has quit [Quit: fab]
<karolherbst>
okay.. another run then
<karolherbst>
yeah.. nevermind, it's still broken
<karolherbst>
I'll dig into it later and see what's actually causing this
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<mareko>
karolherbst: most likely you need to set the environment variable AMD_DEBUG=nodcc
<karolherbst>
mhh, doesn't help
<mareko>
karolherbst: what's the failing test doing?
<karolherbst>
I didn't pinpoint which test(s) are causing it yet
gerddie62 has joined #dri-devel
gallo72 has joined #dri-devel
<karolherbst>
mareko: something with shared memory it seems
<karolherbst>
looks like a null pointer access
<karolherbst>
maybe shared memory doesn't get bound or something?
<zamundaaa[m]>
But yeah it would be good to have something that can be done before any rendering commands were submitted, to work around things like PSR. Afaik the kernel does some guesses based on input events, but that's imo a really bad hack and not super useful
<orowith2os[m]>
Yay! Glad to see Kwin is taking some interest too :)
Danct12 has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
Guess for PSR specifically, a compositor could just commit a pageflip with an old buffer. But that feels like a hack too, just in userspace instead of the kernel
<orowith2os[m]>
Mutter's use case is to work around it taking too long to get to GPU work; it stays on the CPU for so long that frames get sent late, which is why triple buffering patches exist
<orowith2os[m]>
Getting to hint the GPU when it's about to do something means it can reject the triple buffering patches entirely
<orowith2os[m]>
The problem itself should be fixed too, but the workaround/solution has more use cases, so
<orowith2os[m]>
Just to be sure, I'd like to rope in jadahl to confirm I have everything correct