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
<soreau> MrCooper: yea I saw how kmscube did it when I was writing this https://gitlab.freedesktop.org/mesa/kmscube/-/merge_requests/47
<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
<linkmauve> Ok, thanks. :)
<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?
yuq825 has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
Dark-Show_Pi4 has joined #dri-devel
pcercuei has quit [Quit: brb]
sgruszka has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
pcercuei has joined #dri-devel
cmichael has joined #dri-devel
<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
<jani> pq: okay, thanks
<pq> jani, https://docs.gitlab.com/ee/ci/quick_start/ - maybe is some kind of default container, since I don't see it configured...
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]
alarumbe has joined #dri-devel
<Venemo> dj-death: can you please finish your review on this one? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24752
dtmrzgl has quit []
<dj-death> Venemo: will do, maybe not today though
<Venemo> dj-death: thanks, can I assign it to you?
pekkari has joined #dri-devel
<dj-death> Venemo: sure
<Venemo> done, thx
dtmrzgl has joined #dri-devel
itoral has quit [Remote host closed the connection]
DavidHeidelberg has joined #dri-devel
DavidHeidelberg[m] has left #dri-devel [#dri-devel]
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
yyds has quit [Remote host closed the connection]
pekkari has quit [Quit: Konversation terminated!]
<sima> koike, kinda on vacations, but check with drm-misc maintainers if a backmerge is needed and then push to drm-misc-next
<koike> sima: ok, thanks!
Daanct12 has quit [Ping timeout: 480 seconds]
<mlankhorst> just wait a bit btw
<mlankhorst> I would like to confirm that some patches belong to drm-misc-next, otherwise I need to rebase it, backmerge would mess it up
heat has joined #dri-devel
heat has quit [Read error: No route to host]
heat has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
aravind has joined #dri-devel
kzd has joined #dri-devel
sgruszka has quit [Remote host closed the connection]
yyds has joined #dri-devel
yuq825 has left #dri-devel [#dri-devel]
pochu has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
pekkari has joined #dri-devel
yyds has joined #dri-devel
yyds has quit []
yyds has joined #dri-devel
yyds has quit []
Duke`` has joined #dri-devel
yyds has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
yogesh_m1 has joined #dri-devel
yogesh_mohan has quit [Ping timeout: 480 seconds]
pekkari has quit [Remote host closed the connection]
shashanks has joined #dri-devel
yyds has quit [Quit: Lost terminal]
yyds has joined #dri-devel
pekkari has joined #dri-devel
yyds has quit []
yyds has joined #dri-devel
<soreau> the runner said I don't have enough privs to run jobs for MRs so it spams my inbox with fail messages :P
macromorgan has quit [Quit: Leaving]
macromorgan has joined #dri-devel
<soreau> what is the producedure to gain enough privileges to run jobs for MRs on gitlab.fd.o?
yyds has quit [Quit: Lost terminal]
yyds has joined #dri-devel
yyds has quit [Remote host closed the connection]
shashanks_ has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
shashanks has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
pekkari has quit [Quit: Konversation terminated!]
aravind has quit [Ping timeout: 480 seconds]
noord has quit [Quit: bye]
cmichael has quit [Quit: Leaving]
An0num0us has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
noord has joined #dri-devel
gouchi has joined #dri-devel
<soreau> zmike: To run wlroots compositors with drm backend, you have to make sure drm backend is enabled in wlroots first
<zmike> pls post in ticket
<zmike> thx
<soreau> ok, updated comment
<cmarcelo> To know what margebot is up to I've been using a search on MR with filter: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests?assignee_username=marge-bot&scope=all&sort=updated_desc&state=opened&utf8=%E2%9C%93 is there a better way to do that (i.e. does margebot itself have a log or status somewhere)?
<DavidHeidelberg> but needs to be rebased, it's loooong time ago
<cmarcelo> DavidHeidelberg: thanks, I'll take a look at that.
tristianc6704 has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
tristianc6704 has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
pcercuei has quit [Quit: Lost terminal]
pcercuei has joined #dri-devel
pcercuei has quit []
aswar002_ has joined #dri-devel
pzanoni` has joined #dri-devel
mattrope_ has joined #dri-devel
pzanoni` has left #dri-devel [#dri-devel]
pcercuei has joined #dri-devel
pzanoni is now known as Guest1290
pzanoni has joined #dri-devel
Guest1290 has quit [Ping timeout: 480 seconds]
aswar002 has quit [Ping timeout: 480 seconds]
mattrope has quit [Ping timeout: 480 seconds]
aswar002 has joined #dri-devel
rsripada_ has joined #dri-devel
dolphin` has joined #dri-devel
fdu_ has joined #dri-devel
dolphin is now known as Guest1291
dolphin` is now known as dolphin
sghuge_ has joined #dri-devel
lstrano_ has joined #dri-devel
shankaru1 has joined #dri-devel
unerlige has quit [Ping timeout: 480 seconds]
Ryback_[WORK] has joined #dri-devel
a-865 has quit [Quit: ChatZilla 0.17.1 [SeaMonkey 2.53.17.1/20230917131154]]
Guest1291 has quit [Ping timeout: 480 seconds]
fdu has quit [Ping timeout: 480 seconds]
shankaru has quit [Ping timeout: 480 seconds]
Ryback_ has quit [Ping timeout: 480 seconds]
rsripada has quit [Ping timeout: 480 seconds]
sghuge has quit [Ping timeout: 480 seconds]
lstrano has quit [Ping timeout: 480 seconds]
aswar002_ has quit [Ping timeout: 480 seconds]
a-865 has joined #dri-devel
<mlankhorst> Lyude: ping?
a-865 has quit [Quit: ChatZilla 0.17.1 [SeaMonkey 2.53.17.1/20230917131154]]
a-865 has joined #dri-devel
<Lyude> mlankhorst: I can make one if you want, I had pushed it there after asking airlied
a-865 has quit []
sghuge_ has quit []
sghuge has joined #dri-devel
a-865 has joined #dri-devel
An0num0us has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<anholt> anyone up for acking some piglit test coverage for my refactor long ago? https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/813
<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
<dcbaker> zmike: I have an unexpcted pass from zink-lvp: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/49441458. Should I just mark that as expected pass and move on?
<mareko> karolherbst: clear_texture won't work with a compute-only context, you can use util_clear_texture_sw in the meantime
<karolherbst> ahh, yeah, that might explain it
<karolherbst> atm I fall back to `u_default_clear_texture`
<mareko> that might also work
<karolherbst> if that's the case, radeonsi can just not set the clear_texture cb and rusticl will fall back to u_default_clear_texture
<karolherbst> I can try that later
<mareko> radeonsi uses u_default_clear_texture, which should fallback to sw because clear_render_target is NULL
heat has quit [Remote host closed the connection]
<karolherbst> okay
<mareko> oh, it's not
heat has joined #dri-devel
<mareko> yeah it will crash most likely
sima has quit [Ping timeout: 480 seconds]
<karolherbst> my GPU hard reset :')
<karolherbst> or rather.. it doens't do anything
gouchi has quit [Quit: Quitte]
<karolherbst> mareko: yeah.. removing si_clear_render_target indeed helps
<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?
anholt has joined #dri-devel
<mareko> karolherbst: shared memory isn't bindable
<karolherbst> pepp: it's the `api/test_api execute_kernel_local_sizes` causing issues
<karolherbst> ehh wait.. it's not even using shared memory
<karolherbst> just running a shader
<karolherbst> let me try to figure out what exactly messes it up
<karolherbst> mhhh... RUSTICL_DEBUG=sync fixes it...
<karolherbst> maybe something with fences or so messing up
tursulin has quit [Ping timeout: 480 seconds]
<karolherbst> I'll try to figure out more tomorrow
Duke`` has quit [Ping timeout: 480 seconds]
gerddie62 has quit [Ping timeout: 480 seconds]
gallo72 has quit [Ping timeout: 480 seconds]
imre has joined #dri-devel
<mareko> karolherbst: can you also please check whether this fixes it? https://pastebin.pl/view/raw/7396a189
<karolherbst> yep, that helps with that single test
<karolherbst> mareko: with that patch I don't see any regressions and it seems to work: https://gitlab.freedesktop.org/-/snippets/7690
<karolherbst> I still have AMD_DEBUG=nodcc set though
<karolherbst> trying a new run without it
<karolherbst> but that also seems to work, or at least it's not as broken as without that patch so far
heat has quit [Remote host closed the connection]
bbrezillon_ has quit [Remote host closed the connection]
<karolherbst> yep, looks fine without nodcc as well
atipls has quit [Remote host closed the connection]
atipls has joined #dri-devel
mvlad has quit [Remote host closed the connection]
vliaskov_ has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
An0num0us has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
<orowith2os[m]> Does anybody know if using a DRM master node gives a compositor anything special than just privileged ioctls?
<orowith2os[m]> I asked karolherbst about it elsewhere but nothing solid
<orowith2os[m]> I'm mainly interested in if a compositor running on a master node has higher priority for GPU work
<orowith2os[m]> And if other clients on render nodes get put at a higher priority when e.g. gaming or using direct scanout
<anholt> nope, it's just the ioctls.
gio has quit [Ping timeout: 480 seconds]
shashanks__ has joined #dri-devel
shashanks_ has quit [Ping timeout: 480 seconds]
<anholt> argh. no gdb and no apt in the ci rootfs
pcercuei has quit [Quit: dodo]
kasper93 has joined #dri-devel
<orowith2os[m]> anholt: ouch, would like to maybe sort something like that out at some point
<orowith2os[m]> Iirc ChromeOS has GPU hints for when things happen, if we can drag that over into desktop Linux it would be amazing
<orowith2os[m]> (and Mutter would be able to make decent use of it)
<anholt> hooking up queue priorities: great. associating literally any new behavior with DRM control nodes: bad.
kasper93_ has quit [Ping timeout: 480 seconds]
<orowith2os[m]> Anything to hint the GPU when it needs to clock up and when it can go into low power mode
<orowith2os[m]> (e.g.: low clocks normally, slightly higher to accommodate overview animations, back down when not doing anything)
<orowith2os[m]> Right now I believe the flow is you do something -> GPU sees you do something -> GPU clocks up
<orowith2os[m]> This would be you hint that you're about to do something -> the GPU clocks up -> you do something
<anholt> a common way to fix this on phones is to hook input after an idle delay to preemptively clocking up gpu.
<orowith2os[m]> If that's making any sense
<anholt> which doesn't require any app smarts
<orowith2os[m]> Hm
<anholt> and is entirely within the kernel
<orowith2os[m]> Yeah, I believe that's what ChromeOS does
<orowith2os[m]> But I don't believe it's ever been upstreamed
<orowith2os[m]> So many believes, eugh
<anholt> also, if your kernel driver doesn't quickly clock up on submit after an idle period, that's also a driver bug.
<orowith2os[m]> But a general hinting mechanism would probably be better
<anholt> but this is my opinion
<zamundaaa[m]> Dallas Strouse (she/her) 🧑‍🏫: there is https://lists.freedesktop.org/archives/dri-devel/2023-August/419773.html
<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
<orowith2os[m]> I am fairly new to all of this
heat has joined #dri-devel