ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
amarsh04 has quit []
epoch101 has joined #dri-devel
amarsh04 has joined #dri-devel
amarsh04 has quit []
amarsh04 has joined #dri-devel
riteo has joined #dri-devel
OftenTimeConsuming has joined #dri-devel
<karenw>
"ERROR: [../src/amd/vulkan/radv_physical_device.c:1969] Code 0 : Could not open device /dev/dri/renderD129: Invalid argument (VK_ERROR_INCOMPATIBLE_DRIVER)" Oh boy I love updating my drivers only to lose vulkan support. *sigh*
<karenw>
This laptop is ultra cursed anyway (inegrated gpu using radeon, high-perf gpu using amdgpu) so I'm not too surprised. Time to debug and find out why.
KarenTheDorf has joined #dri-devel
<KarenTheDorf>
Welp, mesa mainline doesn't even boot correctly, most things segfault at launch, including plasma. No more hardware acceleration for me for a while I guess.
minecrell has quit [Quit: Ping timeout (120 seconds)]
minecrell has joined #dri-devel
karenw has quit [Ping timeout: 480 seconds]
kaiwenjon has quit [Remote host closed the connection]
KarenTheDorf has quit [Remote host closed the connection]
kaiwenjon has joined #dri-devel
kaiwenjon has quit []
kaiwenjon has joined #dri-devel
karenw has joined #dri-devel
<DavidHeidelberg>
"lawyers" hanging around, please review https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32447 it's not rocket science, but it should clarify licensing to the distributions and people using the Mesa ! (corporate important stuff! :D )
<DavidHeidelberg>
it follows the Linux kernel conversions, which seems to be pretty clean and nice.
<clever>
for things like xterm that dont repaint often, it will persist until the next repaint
<karenw>
Hmm, I wonder if that's what I get. I don't lose kwin, but occasionally random applications will get a "This context is innocent" message and die.
<clever>
for video/games, its repainting at 60hz, so its just a flash
<clever>
i already went into the kernel source before, and raised the timeout massively, it didnt help, it just made it take longer for the kernel to complain
<clever>
once the gpu is reset and X hangs, chvt also hangs, so you cant get back to text mode until X is killed
<clever>
it looks like a gpu function gave an error, so X ran abort()
<clever>
and abort() then leads to gpu de-init, which hangs
<clever>
possibly because its abort()'ing with a lock held?
The_Company has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
vedm has joined #dri-devel
vedm_ has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
sguddati has joined #dri-devel
alane has quit []
alane has joined #dri-devel
<clever>
amdgpu: The CS has cancelled because the context is lost. This context is innocent.
<clever>
karenw: and with further digging, i found that X logs to stderr, and digging revealed a second log file (lightdm) that has the stderr
kaiwenjo1 has quit []
heat has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
parthiban has joined #dri-devel
epoch101 has quit []
enunes has quit [Ping timeout: 480 seconds]
karenw has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
sukuna1 has joined #dri-devel
sukuna has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]
borecole has joined #dri-devel
oneforall2 has joined #dri-devel
guru_ has joined #dri-devel
borecole has quit []
sguddati has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Quit: WeeChat 4.4.3]
rgallaispou has joined #dri-devel
sguddati has joined #dri-devel
fab has joined #dri-devel
epoch101 has quit []
kzd has quit [Ping timeout: 480 seconds]
hikiko has quit [Quit: Leaving!]
hikiko has joined #dri-devel
sukuna has joined #dri-devel
sukuna has quit [Remote host closed the connection]
mehdi-djait33971 has joined #dri-devel
sukuna1 has quit [Ping timeout: 480 seconds]
sguddati has quit [Ping timeout: 480 seconds]
cascardo has joined #dri-devel
cascardo_ has quit [Ping timeout: 480 seconds]
fab has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
vliaskov has joined #dri-devel
jsa1 has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
sima has joined #dri-devel
fab has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
glennk has joined #dri-devel
frieder has joined #dri-devel
frieder has quit []
frieder has joined #dri-devel
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
Adrinael has quit [Ping timeout: 480 seconds]
phasta has joined #dri-devel
jfalempe has joined #dri-devel
<austriancoder>
daniels: I was told that you might be working on arm32 mesa container thing that is needed to use ci-tron for arm32 devices. Is there any eta?
jkrzyszt has joined #dri-devel
dolphin has joined #dri-devel
gnuiyl__ has quit []
gnuiyl has joined #dri-devel
warpme has joined #dri-devel
apinheiro has joined #dri-devel
lynxeye has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
The_Company has quit []
biju has joined #dri-devel
fomys_ has joined #dri-devel
Adrinael has joined #dri-devel
Adrinael is now known as Guest2511
frieder has joined #dri-devel
<Kayden>
is there a reasonable way to get a disassembly of .dxbc files?
rasterman has joined #dri-devel
<Kayden>
trying to see if an app is doing silly things in its shaders or if vkd3d-proton is translating things in ways I'd prefer it didn't
<Kayden>
managed to get those with VKD3D_DUMP_SHADER_PATH
<konstant>
Hello! Newbie question about RADV. Am I understanding correctly that BVH format is hardwired into GPU? I'm researching space partitioning algorithms for fun and it would be interesting to try out different tricks if the format is not hardwired. I found BVH encode compute kernel in repository, but no traversal, therefore it looks like it is indeed hardwired. Of course, I could just try different things with compute shaders and classic p
<konstant>
ipeline, but it would be interesting to try to inject custom BVH format into raytracing acceleration structures if it is possible. (sorry if it is a duplicate, its my first time using IRC and I'm receiving "unable to send" errors)
<rodrigovivi>
jani: thank you!
<sima>
rodrigovivi, so should I roll drm-next to -rc2 so you can do the backmerge and sort things out for xe?
<rodrigovivi>
sima: yes, please
kts has joined #dri-devel
<sima>
rodrigovivi, done
<glehmann>
Konstant: if you want to use the ray tracing hw acceleration (mainly image_bvh64_intersect_ray), the bvh format can't be changed
<konstant>
glehmann: Thanks for the answer.
egbert has joined #dri-devel
davispuh has joined #dri-devel
<sima>
tzimmermann, mlankhorst I guess drm-misc-next also needs a backmerge and fixup for the module namespace stuff, see the mail from sfr
<tzimmermann>
sima, i've seen another one of those in xe_vsec.c
<tzimmermann>
easy to fix
kts has quit [Quit: Leaving]
fab has quit [Quit: fab]
<sima>
tzimmermann, yeah, rodrigovivi is already handling that one with a backmerge to xe
<sima>
or is that one also in drm-misc?
<tzimmermann>
sima, i'm not on duty, but I'll check for the backmerge tomorrow
<tzimmermann>
sima, i've seen it in -tip
<rodrigovivi>
I'm on it
<sima>
tzimmermann, yeah tip is a bit busted rn until this is all sorted
<sima>
imre, for the hotplugged connector discussion, I think unconditionally adding to the connector list in drm_connector_regsiter and then still using that same list as we do now for delayed registration if the overall drm_device isn't registered yet should work I think?
<sima>
at least I couldn't come up with a corner case where it fails
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
<mlankhorst>
sima: Yeah I just noticed the buildfails
<mlankhorst>
was also hit by another failure in relocate_kernel
phasta has quit [Quit: Leaving]
<sima>
mlankhorst, you'll do the backmerge or is it on mripard (who seems not around)?
balrog has joined #dri-devel
<mlankhorst>
I'll take a look
<mlankhorst>
hit the compile failure too
<mlankhorst>
Do I include the build failure fix in the backmerge or as separate commit?
fab has joined #dri-devel
<sima>
mlankhorst, depends if you want to give sfr credit, imo either is fine as long as you push the fix together with the merge to make sure no one sneaks in
<sima>
or just credit sfr with a Link: to the mail
<sima>
if you do it in the merge as a fixup
<sima>
mlankhorst, see also further up for the sha1 curtesy jani that broke things
<sima>
that needs to be in the merge commit as the reason
<mlankhorst>
Yeah I'll finish compile testing first, then push. :)
<mlankhorst>
I had noticed the same issue on Xe with xe_vsec, and relocate_kernel for an unrelated failure that's config dependant, one of those releases..
<mlankhorst>
rodrigovivi: Can you also test it works without VSEC symbol?
<rodrigovivi>
I have the merge commit ready here, just build is taking longer then I'd like too... pushing soon
<rodrigovivi>
just in time... build passed... pushing it right now
<mlankhorst>
Pushing 1 merges and 0 non-merge commits. Merges should only be pushed by maintainers. Are you sure? (y/N) y
<mlankhorst>
one wins!
<sima>
mlankhorst, you typoed sfr's name :-/
<mlankhorst>
oops
<mlankhorst>
I have had his name wrong in my mind for years then!
<sima>
mlankhorst, tzimmermann -tip should work again I hope
<sima>
yeah but that seems hard to hit and not a drm one
<mlankhorst>
True, I was hitting that one though
Guest2552 has joined #dri-devel
konstant has quit [Remote host closed the connection]
robmur01 has joined #dri-devel
<imre>
sima, I think detecting/adding MST connectors should work already before registering the device to be visible by userspace.
<imre>
there seems to be a check in drm_connector_register() to handle this
<imre>
the !connector->dev->registered and registration_state != DRM_CONNECTOR_INITIALIZING
Duke`` has joined #dri-devel
frieder has quit [Remote host closed the connection]
<sima>
imre, yeah that's what I mean, leave that check and all the logic around it unchanged
tejasupa has quit [Remote host closed the connection]
<sima>
and for dynamic/mst connectors move the list_add from connector_init to the top of connector_register, without any additional conditions
<imre>
ah
<sima>
the delayed registration we still need, because that can only be done when we have the sysfs/debugfs files or it will blow up
<imre>
wouldn't the logical place for list_add be after connector->registration_state = DRM_CONNECTOR_REGISTERED; in drm_connector_register() ?
<sima>
but internally within the driver the connector list is all the registration we have, so that should always happen
<imre>
I thought that's what you meant
<imre>
at least wrt. GETRESOURCES and MST ..
<sima>
nah, before, even outside of the mutex I think
<sima>
there's about 3 cases
<sima>
1. non-dynamic connectors: nothing changes
<sima>
2. dynamic connector, registered after drm_dev_register: no delayed registration, drm_connector_regsiter called from connector/mst code does it all
<sima>
3. dynamic connectors at driver load before drm_dev_register: this is tricky, but drm_connector_register called from connector/mst code needs to add the connector to the connector_list, but then the delayed register call from drm_dev_register will do everything else, since we still need to delay that part due to debugfs/sysfs nesting
<sima>
imre, that also means that drm_connector_register_all needs to call a version of _register which doesn't do the list-add, or things go boom
<imre>
so list_add on top of drm_connector_register() should happen only if the connector is not alreay on the list, right?
<sima>
yeah
<imre>
ok
<sima>
because there's also drivers that have non dynamic connectors but still call drm_connector_register, because we haven't finished the todo I linked
<sima>
that's why I suggested to key this off of the connector type being mst
<sima>
so that it's consistent
<sima>
otherwise if we both list_add in connector_init (non-dynamic version) and connector_register we have another boom
<sima>
or you do dynamic versions of both _init_ and _register
<sima>
or you do the handful of patches needed to nuke all the few remaining surplus drm_connector_register calls
<sima>
git grep says 9 drivers left with those
<sima>
if I'm correct that mst is really the only thing we hotplug (since we don't hotplug bridges yet)
haaninjo has joined #dri-devel
<imre>
okay
<sima>
imre, hm a sanity check we should probably add is WARN_ON(dev->registered) in the non-dynamic connector_init
<imre>
this is what I also suggested in the email thread, except of an internal drm_connector_register() for the deferred registration
<sima>
because that would be a clear bug
<imre>
so I think this could be done now
<imre>
but one more thing
<sima>
hm yeah maybe I misread then a bit what you were aiming for, it looked like you missed the GETRESOURCES case for case 3 above
<imre>
I guess you agree that users should see the connector only after it's fully inited
<imre>
that is sysfs/debugfs is already added for it
<imre>
and late_register is called for it
<imre>
?
<imre>
atm GETRESOURCES would not guarantee that
<sima>
hm
<imre>
as you pointed out, yes
<imre>
but it's an existing issue
<sima>
yeah I guess that's a really good reason to do the list_add at the end of connector_register
<imre>
but we can't atm
<sima>
but still needs to happen unconditionally because of case 2
<sima>
hm why?
<imre>
the best would be a 3rd connector list
<imre>
just for registration
<imre>
if deferred registratoin happens via the current connector list
<sima>
oh case 2 where the mst gets added before drm_dev_register ...
<imre>
then list_add needs to happen on top of drm_connector_register()
<imre>
yes
<sima>
well, that is a much bigger issue
<sima>
because it also impacts the non-dynamic connectors, and we cannot hotplug those a notch later because that could confuse userspace
<sima>
like ideally the entire mess would get added atomically, but that's not how this works unfortunately
<imre>
how are non-dynamic connectors impacted?
<sima>
imre, so for this I'd just add a patch which adds a comment to drm_dev_register explaining how we're kinda screwed
<sima>
they have the same race right under drm_dev_register
<imre>
right
<imre>
so for instance GETRESOURCES sees a non-dynamic connector before its sysfs/debugfs is added
<sima>
yeah
<sima>
we just hope and pray the system doesn't boot fast enough :-/
<imre>
what about checking registration state in GETRESOURCES
<sima>
hm right it's not just debugfs/sysfs, it's also GETRESOURCES and GETCONNECTOR because we have the drm_mode_object_register in there
<imre>
GETCONNECTOR checks mode_config.object_idr
<imre>
so that's ok?
<sima>
imre, wrong way to close the race, we want to make sure GETCONNECTOR immediately works right when you can open the drmfd
<sima>
not delay the visibility in GETRESOURCES, that only works for case 3, not 1
<sima>
so I guess for drm_dev_register we'd need to split drm_connector_register_all into 2 phases
<sima>
phase run before drm_minor_register: adds to list and registers mode object
warpme has quit []
<sima>
phase run afterwards: calls ->late_register and the sysfs/debugfs stuff
samuelig has quit [Quit: Bye!]
<sima>
I frankly would just record this as a FIXME somewhere and focuse on the more minimal fix for case 3
<imre>
ok
<sima>
since this issue is about as old as the delayed connector registration
samuelig has joined #dri-devel
robmur01 has quit [Remote host closed the connection]
<sima>
which is like over 8 years
<sima>
and I haven't heard anyone yell thus far
robmur01 has joined #dri-devel
flto has quit [Ping timeout: 480 seconds]
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
mehdidjait[m] has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
mehdi-djait339716 has quit []
kts has quit [Remote host closed the connection]
flto has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
sukuna has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
bolson has joined #dri-devel
mehdidjait[m] has quit []
mehdidjait[m] has joined #dri-devel
Guest2562 has joined #dri-devel
Guest2562 has quit [Remote host closed the connection]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
kaiwenjon has joined #dri-devel
jkrzyszt has quit [Quit: Konversation terminated!]
lynxeye has quit [Quit: Leaving.]
fomys_ has quit []
coldfeet has joined #dri-devel
epoch101 has joined #dri-devel
androidui has quit [Remote host closed the connection]
ZLangJIT has joined #dri-devel
ZLangJIT is now known as androidui
yogesh_m1 has quit [Ping timeout: 480 seconds]
anujp has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
epoch101 has quit []
epoch101 has joined #dri-devel
coldfeet has quit [Quit: Lost terminal]
biju has quit []
anujp has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
yogesh_m1 has joined #dri-devel
heat is now known as Guest2572
heat has joined #dri-devel
Guest2572 has quit [Read error: Connection reset by peer]