ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
iive has quit [Quit: They came for me...]
epoch101 has quit []
anholt has quit [Remote host closed the connection]
glennk has quit [Ping timeout: 480 seconds]
The_Company has joined #dri-devel
simon-perretta-img_ has joined #dri-devel
lsntvt_ has quit [Remote host closed the connection]
lsntvt_ has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
CME has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
sarnex has quit [Read error: Connection reset by peer]
sarnex has joined #dri-devel
CME has joined #dri-devel
lcn has quit [Remote host closed the connection]
lcn has joined #dri-devel
mriesch has quit [Remote host closed the connection]
mriesch has joined #dri-devel
davispuh has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
balrog_ has joined #dri-devel
balrog has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
fomys has quit [Read error: Connection reset by peer]
melnary has quit [Remote host closed the connection]
melnary has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
Duke`` has joined #dri-devel
kzd has quit [Quit: kzd]
kzd has joined #dri-devel
kzd has quit [Quit: kzd]
fomys has joined #dri-devel
fab_ has joined #dri-devel
fab_ is now known as Guest21669
Duke`` has quit [Ping timeout: 480 seconds]
feaneron has quit [Ping timeout: 480 seconds]
<ity>
Is there some way I can log page flips? Specifically, for the sake of tracking down random scanout freezes. I cannot tell if
<ity>
- driver stopped scanning-out
<ity>
- the display server (sway) stopped doing page flips
<ity>
etc etc. Nothing in dmesg (besides some random, as far as I can tell unrelated iGPU "Atomic update failure" from an unrelated time several hours before the actual issue), so I don't actually know where to look, haha.
<ity>
I know it's not a system freeze since I can ssh and do things just fine. Just cannot tell if it's sway locking up or the driver breaking, and unsure how to track that down.
<tarceri>
mareko: did you run the final patch through shader-db to be sure it doesn't do anything?
sima has joined #dri-devel
<tarceri>
I have a feeling I tested it at some stage but it was still doing something
<Lynne>
was the limit on FindSMsb only being usable on 32-bit variables lifted yet?
<Lynne>
I remember there being an extension to remove this limitation
MrCooper has quit [Ping timeout: 480 seconds]
Guest21669 has quit []
MrCooper has joined #dri-devel
<mareko>
tarceri: yes, there are 0 shader-db changes with radeonsi
<tarceri>
thing might have improved :)
kts has joined #dri-devel
blaztinn_ has quit [Remote host closed the connection]
blaztinn has joined #dri-devel
mriesch has quit [Remote host closed the connection]
mriesch has joined #dri-devel
FANTOM has joined #dri-devel
blaztinn has quit [Remote host closed the connection]
blaztinn has joined #dri-devel
rasterman has joined #dri-devel
fab has joined #dri-devel
vliaskov has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
tzimmermann has joined #dri-devel
vliaskov has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
mripard has joined #dri-devel
Cahata has joined #dri-devel
warpme has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
Cahata has quit [Remote host closed the connection]
idr has quit [Ping timeout: 480 seconds]
jkrzyszt_ has joined #dri-devel
lynxeye has joined #dri-devel
kode54 has quit [Read error: Connection reset by peer]
kode54 has joined #dri-devel
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
kts has joined #dri-devel
<glehmann>
Lynne: no that ext only covered, only bitfield extract/insert/reverse
<glehmann>
FindSMsb/UMsb/Lsb are harder because the actual spir-v instruction is defined as 32bit only, so it can't be changed by just changing a Vulkan VUID
<Lynne>
oh, well, looking at the rdna3 instruction sheet, the hardware only accepts 32-bit numbers anyway
<glehmann>
VALU is 32bit only yes, SALU has a 64bit version
<glehmann>
Lynne: but if you want 64bit findmsb, don't hesitate to open a Vulkan-Docs issue
<karolherbst>
Are there any reasons why a DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD + DRM_SYNCOBJ_HANDLE_TO_FD_FLAGS_EXPORT_SYNC_FILE might fail on a valid syncobj?
<karolherbst>
(besides OOM)
<emersion>
karolherbst: maybe if the syncobj has not yet materialized?
<karolherbst>
mhhh, what does that mean?
<karolherbst>
but it sounds plausible
<emersion>
it's for wait-before-submit
<emersion>
before GPU work has been enqueued, the syncobj sync_file for a given point will be NULL
<karolherbst>
yeah, soo if I submit the syncobj then exporting works fine, but I need to export before anything waits on or submits it
<karolherbst>
_but_ maybe I should just not use sync files then?
<karolherbst>
it's just a lot of the code assumes sync_file...
<emersion>
you need to wait for GPU work to be enqueued before being able to get a sync_file out of the syncobj
<karolherbst>
mhhh
<karolherbst>
well, it's not under my control
<emersion>
sync_file is a special "privileged" fence
<emersion>
which promises it's going to complete "soon"
<karolherbst>
ahh
<karolherbst>
mhhh
<karolherbst>
annoying
<emersion>
can only be created by the kernel
<emersion>
that is, there is no user-controlled sync_file
<karolherbst>
it seems like I only get sync files when anything uses VULKAN_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD and the code I'm working on (external semaphore in CL) need to be able to consume that one
<emersion>
you can turn a sync_file into a syncobj, if that helps
<emersion>
but i'm not sure i understand what you want to do
<karolherbst>
so vulkan applications create an FD through VULKAN_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD, and I need to import that one, but I also need to be able to create fds that vulkan applications can import
<karolherbst>
sooo.. the thing is, I don't know what's the vulkan impl :)
<karolherbst>
though might as well assume mesa...
<emersion>
ok, then that's toast
<emersion>
i would fully support and help a new vulkan ext :)
<karolherbst>
there is cl_khr_external_semaphore_opaque_fd
<karolherbst>
and it's "implementation defined"
<emersion>
but then that only works if CL and Vulkan are the same driver
<karolherbst>
I see
<karolherbst>
might as well use opaque then
<emersion>
;_;
<karolherbst>
but I also wanted to get the sync_fd thing working
warpme has joined #dri-devel
<emersion>
what vulkan does is block (!) until the sync_file materializes in some places
<karolherbst>
anyway.. on the mesa side I need to create some sort of semaphore where I can reliable get a fd for without having any queue
K900 has quit [Remote host closed the connection]
<karolherbst>
yeah.. that's fine
K900 has joined #dri-devel
<emersion>
e.g. if you give a wait point, and submit work, the submission function will block until it can extract a sync_file
<karolherbst>
not sure if clGetSemaphoreHandleForTypeKHR is allowed to block, but the signal/wait variants are
<emersion>
i have no idea what the vulkan sync_file export func does
<emersion>
maybe a good place to look?
<emersion>
either fails or blocks, i'd say
<karolherbst>
mhhh... yeah maybe I just need to place a wait somewhere, the amdgpu winsys might just assume the fence has already be attached to a queue (which would make sense given that the normal code flushes a context and uses that fence to export)
<karolherbst>
and yeah.. vulkan blocks
<karolherbst>
I had to uhm.. deal with it, because I had zink blocking trying to export the fence
<emersion>
right
<emersion>
this is quite annoying to deal with from the wlroots side :<
<karolherbst>
but yeah, if I just need to wait, I just have to see how mesa waits on the vulkan side then
<karolherbst>
yeah...
<emersion>
there's an ioctl for WAIT_FOR_SUBMIT
<karolherbst>
this external semaphore/memory business is sure fascinating
<emersion>
there are libdrm wrappers for these ioctls
<karolherbst>
the world with cl_gl sharing was wonderful, because you knew the GL context on the CL side, and you could establish a back channel to do all this stuff behind the applications back (like sharing modifier information, stride, size, etc...)
<emersion>
kinda sad nobody sent the kernel patch for this
<karolherbst>
heh
<emersion>
tbh it looks like an oversight
<emersion>
drm_syncobj_timeline_wait_ioctl is literally the same code
<emersion>
but with the points passed in instead of NULL
<karolherbst>
sooo.. guess I go spinning then
<karolherbst>
which.. is annoying because it might as well spin forever 🙃
<emersion>
so i think just adding the flag to the allow-list should just work
<karolherbst>
well if you have a new kernel, yes
<emersion>
with this reasoning we'll never fix any kernel issue :P
<karolherbst>
I'm just trying out the spinny solution first and see if that helps
<karolherbst>
ohh right the workaround I've added was to flush the last queue I saw that semaphore on...
<karolherbst>
mhhh
<karolherbst>
I could turn it into a wait, but I also don't want to risk dead locks
<karolherbst>
but yeah.. it works..
<karolherbst>
maybe I just spin after the flush, because it's gonna give me a proper fd at some point
<karolherbst>
emersion: anyway, thanks for the help! Seems to be working correctly now
<emersion>
cool!
<karolherbst>
now I just need to figure out why the queue is randomly dying... but it's probably unrelated because the vulkan <-> CL interop tests does a few successful iterations until it breaks
imre has joined #dri-devel
pcercuei has joined #dri-devel
feaneron has joined #dri-devel
bbrezill1 has joined #dri-devel
warpme has quit []
apinheiro has joined #dri-devel
jsa1 has joined #dri-devel
cweperle^ has quit [Remote host closed the connection]
bbrezillon has quit [Ping timeout: 480 seconds]
jsa1 has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
alarumbe has joined #dri-devel
guludo has joined #dri-devel
YuGiOhJCJ has quit []
<sima>
karolherbst, yeah fixing the kernel would be nice for at least the future
<sima>
like the fd compare function that's finally generally available and mesa is even going to use it now
<karolherbst>
okay. If there are no technical reasons for this restriction I could try to figure out if it's possible
<sima>
as long as it's an opt-in flag I really can't see how this would break anything
<emersion>
yeah, i don't see any reason why binary syncobj should not support this
MrCooper has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
<sima>
I mean userspace might deadlock if you use it wrong, but that applies to timeline syncobj too
<karolherbst>
yeah.. I mean.. use a short enough timeout and then spin on the wait in case you don't
azerov has quit []
davispuh has joined #dri-devel
azerov has joined #dri-devel
<zmike>
mareko: 🤔
<zmike>
why are there tests which exceed the max value?
davispuh has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
nerdopolis has joined #dri-devel
krumelmonster has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
phasta has joined #dri-devel
krumelmonster has joined #dri-devel
kzd has joined #dri-devel
fab has quit [Quit: fab]
warpme has quit []
fab has joined #dri-devel
fab is now known as Guest21688
rasterman has quit [Quit: Gettin' stinky!]
bolson_ has quit [Ping timeout: 480 seconds]
Guest21688 has quit []
warpme has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.6.3]
kts has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: brb]
frankbinns has quit [Remote host closed the connection]
kts has joined #dri-devel
bolson has joined #dri-devel
warpme has quit []
<zmike>
mareko / pepp: do you have plans to fix your deprecation warnings ?
<Sachiel>
s/DEPRECATED// should be easy enough
kts has quit [Quit: Konversation terminated!]
<zmike>
you have your own deprecation problems
<Sachiel>
same solution applies
kts has joined #dri-devel
davispuh has joined #dri-devel
<phasta>
my maintainer tools / dim is hanging at "Fetching linux-upstream (local remote origin)... ". Still worked this morning. Is there an outage?
<ukleinek>
in another channel someone wailed about git.k.o being slow.
<jannau>
phasta: maybe an infrastructure problem on kernel.org side? lore.k.o fails with "Error 503 Backend fetch failed" for me
* phasta
wants to finally merge what he's been working on since September <.< -.-''''''
<phasta>
yoah, seems a server is dead or broken or sth "Fetching linux-upstream (local remote origin)... error: RPC failed; HTTP 502 curl 22 The requested URL returned error: 502"
<mareko>
zmike: yes
imre has quit [Ping timeout: 480 seconds]
<ukleinek>
..ooOO(There were some git security fixes released just yesterday. Coincidence?)
<phasta>
Worked now. Maybe the server admin got a new cup of coffee ^^'
epoch101 has joined #dri-devel
MrCooper has joined #dri-devel
dsimic is now known as Guest21693
dsimic has joined #dri-devel
Guest21693 has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
anholt has joined #dri-devel
zsoltiv__ has joined #dri-devel
imre has joined #dri-devel
zsoltiv___ has quit [Ping timeout: 480 seconds]
idr has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
orbea has quit [Quit: You defeated orbea! 2383232 XP gained!]
jkrzyszt_ has quit []
lynxeye has quit [Quit: Leaving.]
orbea has joined #dri-devel
gfxstrand has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
nerdopolis has joined #dri-devel
Duke`` has joined #dri-devel
rasterman has joined #dri-devel
feaneron has quit [Ping timeout: 480 seconds]
unerlige1 has left #dri-devel [#dri-devel]
unerlige has joined #dri-devel
cweperle^ has joined #dri-devel
phasta has quit [Quit: WeeChat 4.6.2]
zsoltiv___ has joined #dri-devel
zsoltiv__ has quit [Ping timeout: 480 seconds]
frankbinns has joined #dri-devel
feaneron has joined #dri-devel
Kayden has quit [Quit: -> JF]
rasterman has quit [Quit: Gettin' stinky!]
kts has joined #dri-devel
zzyiwei has quit [Quit: Lost terminal]
rasterman has joined #dri-devel
danylo has quit [Quit: Ping timeout (120 seconds)]
danylo has joined #dri-devel
coldfeet has joined #dri-devel
coldfeet has quit []
warpme has joined #dri-devel
warpme is now known as Guest21701
Guest21701 has quit [Ping timeout: 480 seconds]
zzyiwei has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
coldfeet has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
coldfeet has quit [Ping timeout: 480 seconds]
coldfeet has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
MrCooper has quit [Ping timeout: 480 seconds]
coldfeet has quit [Quit: Lost terminal]
<anholt>
daniels: can we delete old traces from traces-db again, yet? Would love to clean it up so that people can reasonably use it in perf testing outside of mesa ci.
fab has quit [Quit: fab]
sima has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
<dcbaker>
zmike: I'm looking at the pipe_surface changes, if that's what you're asking about
<dcbaker>
I'm not planning to look at Crocus or i915 though
minecrell has quit [Quit: Ping timeout (120 seconds)]
minecrell has joined #dri-devel
FANTOM has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
<zmike>
dcbaker: who is responsible for those drivers?
Caterpillar has quit [Ping timeout: 480 seconds]
FANTOM has joined #dri-devel
apinheiro has quit [Quit: Leaving]
FANTOM has quit [Ping timeout: 480 seconds]
<alyssa>
zmike: is anybody?
<zmike>
that's my question
<alyssa>
I thought we just play hot potato (:
<zmike>
why do we have drivers in the tree that are unmaintained is the question I always ask
<zmike>
and usually someone pops out to scream NO IT'S ME I'M THE ONE IN CHARGE
<alyssa>
CODEOWNERS lists anholt for i915 and nobody for Crocus
<alyssa>
also that file seems pretty unmaintained
<alyssa>
problematically, there is no listed code owner for the CODEOWNERS file
<alyssa>
that explains the unmaintainedness
<alyssa>
(((:
<zmike>
I don't think I've ever opened that file
<HdkR>
Sounds like this "nobody" can fix the problems when it happens :P
<Sachiel>
I thought that was what "Community maintained" meant
<alyssa>
HdkR: Great idea
<Sachiel>
you change something that affects them, you are on the hook to fix them up
<zmike>
that's not really how drivers are supposed to work though
<zmike>
common code sure
<Sachiel>
I may be wrong, but I'm under the impression that that's how it always had worked
<zmike>
drivers are supposed to have maintainers
<zmike>
otherwise there's nobody who is actually testing them and addressing issues
Karyon has quit [Remote host closed the connection]