<CADIndie>
Hello, I am the project manager for QuestCraft. We are having some difficulty with Freedreno on the Quest 3. The Quest 3 runs the Adreno740v3 and has graphical corruption when any of the Quest 3 menus are visible, (including the guardian). Is there a known fix, a method to find a fix, or information that would be helpful to know?
<HdkR>
CADIndie: Probably the biggest issue is that Adreno 740 is very new and it is only just coming up. There are known missing features and bugs
<HdkR>
Probably better to rely on the proprietry Adreno driver on that device until A740 is more stable in Freedreno/Turnip
Net147 has joined #dri-devel
<CADIndie>
Is there any way we would be able to help fix/diagnose the issue? Right now we don't have the ability to use the proprietery driver as its missing a great deal of features we require as well as compat with Zink (which is almost detrimental).
<airlied>
CADIndie: I'd file issues with gfxreconstruct traces if you can get them
<airlied>
or just reproducer methods to start with
<CADIndie>
Thank you, we will try utilziing gfxreconstruct for this issue and will follow up soon.
bmodem has joined #dri-devel
<HdkR>
Also might be good to raise the alarm in QCom's graphics forum that people want their driver to support the features that Zink needs. Hopefully get them to increase priority for this on their end
<airlied>
they don't usually do many updates once they ship the hw, you kinda get stuck on whatever they release with
<HdkR>
Yea, but good to talk about needs early so next year they implement at least one extension
<CADIndie>
We'll make sure to let them know, hopefully things start going in the right direction with them.
<HdkR>
There are multiple people wanting Zink with their blob, so hopefully more people yelling makes it actually happen
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
Net147 has quit [Ping timeout: 480 seconds]
<JoshuaAshton>
MrCooper: Sorry, I mean the dmabuf was dup'ed
fab has joined #dri-devel
Duke`` has joined #dri-devel
yyds_ has joined #dri-devel
yyds has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
tzimmermann has joined #dri-devel
itoral_ has joined #dri-devel
itoral has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
sima has joined #dri-devel
kts has quit [Quit: Leaving]
tomba has joined #dri-devel
itoral has joined #dri-devel
kts has joined #dri-devel
itoral_ has quit [Ping timeout: 480 seconds]
archbirdplus has quit [Quit: leaving]
frieder has joined #dri-devel
fab has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
frieder has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
frieder has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
jsa has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
<MrCooper>
JoshuaAshton: thanks for the clarification, I guess some kind of incorrect reference count handling is likely then
<dolphin>
agd5f: I could have sworn amdgpu had a shader memory transfer option in the kernel in the past, has it been dropped or am I just remembering incorrectly?
jfalempe has joined #dri-devel
mripard has joined #dri-devel
frankbinns has joined #dri-devel
frankbinns1 has joined #dri-devel
lynxeye has joined #dri-devel
Daanct12 has joined #dri-devel
frankbinns has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
mvlad has joined #dri-devel
glennk has joined #dri-devel
tursulin has joined #dri-devel
dliviu has joined #dri-devel
vliaskov has joined #dri-devel
moony has quit []
frankbinns1 is now known as frankbinns
i509vcb has quit [Quit: Connection closed for inactivity]
heat has joined #dri-devel
pcercuei has joined #dri-devel
kts has joined #dri-devel
<danylo>
CADIndie pmed you, tldr: open an issue with how to repro and api traces, a740 should render things correctly, the diff with prop driver is in perf. And we appreciate any real world usage of our driver =)
camus1 has joined #dri-devel
flynnjiang has quit [Remote host closed the connection]
camus has quit [Read error: Connection reset by peer]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
kts has quit [Quit: Leaving]
lynxeye has quit [Quit: Leaving.]
lynxeye1 has joined #dri-devel
lynxeye1 has quit []
moony has joined #dri-devel
rasterman has joined #dri-devel
Net147 has joined #dri-devel
rgallaispou has joined #dri-devel
Net147 has quit [Remote host closed the connection]
Net147 has joined #dri-devel
kts has joined #dri-devel
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #dri-devel
qyliss has quit [Quit: bye]
qyliss has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
qyliss has quit [Quit: bye]
qyliss has joined #dri-devel
<jfalempe>
javierm, I'm looking to disable the fbcon output (kernel logs only) when drm_panic runs. But fbcon doesn't use "register_console()" so I don't see how it gets the printk() output.
camus1 has quit []
camus has joined #dri-devel
Net147 has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
Haaninjo has joined #dri-devel
Net147 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
xroumegue has quit [Ping timeout: 480 seconds]
xroumegue has joined #dri-devel
<karolherbst>
did we ever support GL_KHR_shader_subgroup_shuffle in GL?
<karolherbst>
mhh we also don't support GL_KHR_shader_subgroup
<karolherbst>
nvm then
camus has joined #dri-devel
cmichael has joined #dri-devel
yyds_ has quit [Remote host closed the connection]
frankbinns2 has quit [Read error: Connection reset by peer]
frankbinns2 has joined #dri-devel
<mripard>
they look fine, but there's no reason to bypass the usual rules there
<mripard>
so please send the patches, and wait to a r-b or a-b before merging it
<lumag>
mripard, ack
itoral has quit [Remote host closed the connection]
<lumag>
this is even better from my pov
frankbinns1 has joined #dri-devel
frankbinns2 has quit [Read error: Connection reset by peer]
frankbinns2 has joined #dri-devel
<mupuf>
alyssa: oh boy...
frankbinns1 has quit [Read error: Connection reset by peer]
<mupuf>
daniels: seems like the little job prioritization hack isn't sufficient and Marge jobs don't get picked up fast-enough
frankbinns1 has joined #dri-devel
<mupuf>
would be good if someone from collabora could have a look at the generic runner eric_engestrom wrote, so that it could get deployed as soon as possible
<daniels>
it's nothing to do with that, it's that some of our network services had a terribly rough weekend, and a lot of the runners ended up taking themselves offline
<daniels>
they're all back now
frankbinns has joined #dri-devel
<lumag>
mripard, excuse me, just verifying as not to make more mess than I already did :-D With the final Heikki's r-b is it fine to merge https://patchwork.freedesktop.org/series/122584/ through drm-misc?
<daniels>
I'm fine with using the script - last I remember we were waiting to see from the AMD PoV how the experiment was going - but it wouldn't really change anything for us apart from changing the no-runners-available failure mode from 'the last thing you see is 'waiting for job to start' in the log' to 'job never gets picked up'
frankbinns2 has quit [Ping timeout: 480 seconds]
<mupuf>
daniels: great!
<daniels>
mupuf: does 'great' mean 'the script works perfectly and you should use it ASAP', or?
<mupuf>
lol, no, it was for the "they are back now"
frankbinns1 has quit [Ping timeout: 480 seconds]
<mupuf>
As for the new runner, it would mean you could set gitlab job timeouts and it would actually guarantee that Marge would always be the next job picked up, unlike now
<mripard>
lumag: didn't pinchartl have some comments about it?
<mupuf>
right now, if I queue 10 jobs for the same runner, 9 of them will be run before any Marge job can start
<mupuf>
that's not ok
<lumag>
mripard:
<lumag>
<pinchartl> lumag: I'm not a big fan of it as I still feel there's something we should do better. but as I don't have a better solution to propose, I have no objection
<lumag>
<pinchartl> so, please go ahead, you can merge the series :-)
<daniels>
mupuf: hm? we overcommit our gitlab-side runners wrt lava, so the jobs get queued at a higher priority inside LAVA, which uses strict prio ordering
<daniels>
mupuf: so if you fire 10 jobs at it, of which 9 are non-Marge, the Marge one will get picked first
<mupuf>
daniels: you said that the overcommit was 2, right?
<daniels>
I think we bumped that a fair bit higher
<mripard>
lumag: then yeah, go ahead
<lumag>
ack, thanks
<mupuf>
daniels: You sure about that? Looking at gitlab's admin runner page, 3 runners I checked only have one runner
<daniels>
we have one runner instance registered which has a wide concurrent
<mupuf>
I see, and I assume you went a little crazy, like 16?
<daniels>
yeah
<mupuf>
so, then the only issue is the gitlab timeout
<daniels>
if there are any that are missing then those should be fixed regardless, yeah
mripard has quit [Remote host closed the connection]
<mupuf>
ok :)
robmur01 has quit [Ping timeout: 480 seconds]
<daniels>
I'm on other stuff for the next couple/few days, but I can give you a dump of every job's timeout if that's useful
robmur01 has joined #dri-devel
<mupuf>
daniels: no need, I just misattributed the issue here ;)
bmodem has quit [Ping timeout: 480 seconds]
donaldrobson has joined #dri-devel
mripard has joined #dri-devel
haasn` has quit []
<javierm>
jfalempe: you mean to disable at runtime and not at built time?
<jfalempe>
javierm, Yes
<jfalempe>
javierm, in fact from my test, fbcon doesn't write over the drm panic screen, so I'm not sure it's really needed.
<javierm>
jfalempe: interesting. I don't know tbh
<javierm>
tzimmermann: robher: my opinion is that "of/platform: Disable sysfb if a simple-framebuffer node is found" can wait for v6.8, I woulnd't target the v6.7-rc cycle, specially since is already -rc5
<javierm>
tzimmermann: robher: WDYT ?
<jfalempe>
javierm, I think the panic backtrace is written before the panic callback is called. And then even if I add some printk at the end of drm panic, they are not written to the framebuffer.
fab has quit [Quit: fab]
Cart has quit []
<javierm>
jfalempe: maybe you can make fbcon_unbind() an exported symbol and use it ?
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
donaldrobson has quit [Ping timeout: 480 seconds]
donaldrobson has joined #dri-devel
rgallaispou1 has joined #dri-devel
<jfalempe>
javierm, fbcon_unbind() takes the console_lock() so I can't use it directly from a panic handler. But I can do something similar.
rgallaispou1 has quit []
rgallaispou1 has joined #dri-devel
kzd has joined #dri-devel
rgallaispou has quit [Ping timeout: 480 seconds]
<sima>
jfalempe, javierm imo if we have the drm panic handler, we need to nuke the fbcon one preemptively
<sima>
fbcon_unbind from panic context is a definite no-go imo :-)
<sima>
or anything like that really
<sima>
something like an fb_info->flags NO_PANIC or so maybe that's set at driver registration
<sima>
eventually we need to push that into the vc layer too, so that it can be handled in the actual console functions
<sima>
but that needs oggness' panic rework to get much further first
<sima>
mripard, perfect bikeshed :-)
<sima>
mripard, want me to reply? generally I'm with vsyrjala and jani, _init functions shouldn't fail and at most should WARN_ON if it's abused
<sima>
unfortunately C doesn't let us encode requirements all that well into function signatures
<sima>
connector_init is kinda me because the xarray can fail to allocate memory, but in practice it cannot, so drivers are kinda ok in outright ignoring that error value
<sima>
and so I don't think we should use the fact it's not void as an excuse to add more error cases, there should be none
<sima>
(GFP_KERNEL never fails for small allocs like 1-2 xarray branches, the kernel allocator will retry forever)
fab has joined #dri-devel
<javierm>
sima, jfalempe: I've to admit that suggested fbcon_unbind() without thinking on the locking situtation :)
donaldrobson has quit [Ping timeout: 480 seconds]
<sima>
javierm, in general panic is not the place where you want to make any big scary calls, irrespective of locking
<sima>
so if something must not happen during panic, we need to arrange for that upfront
<javierm>
sima: got it
<javierm>
jfalempe: at first it can be a build time option though, depends on !VT
donaldrobson has joined #dri-devel
<sima>
like ideally on a system with drm panic we'd completely disable the vt console
<sima>
or at least the panic part
<jfalempe>
javierm, the current KConfig is !FRAMEBUFFER_CONSOLE
<sima>
so pure thread based printing, but that needs oggness' work
<jfalempe>
but I want to remove that, so that it's easier to enable for distribution.
<javierm>
sima: but even without that, and if is very slow, it would be better than nothing right?
<javierm>
jfalempe: I understand the goal but from the discussion it seems that won't be trivial
<jfalempe>
sima, I'm not able to make fbcon write over the panic screen, so I think even doing nothing works.
<sima>
javierm, oh it could be a fallback still
<sima>
so in static struct console vt_console_driver replace the ->write with ->write_threaded (or whatever it's going to be called)
<sima>
on a system with drm panic handler
<sima>
otherwise we need the legacy ->write panic horror show
<sima>
jfalempe, we've mostly disabled a lot of it already because too dangerous for drm drivers
<sima>
jfalempe, if you have a shadow buffer it won't do anything, since that wont run
<sima>
or damage handling in general
<jfalempe>
sima, ah ok, that can explain why it works.
<jfalempe>
javierm, sima, maybe we can merge drm_panic with !FRAMEBUFFER_CONSOLE as a first step, and then patch vt_console_driver, and remove this condition with confidence ?
<javierm>
jfalempe: that's what I was suggesting, yes
<sima>
yeah that sounds ok to get this going
<javierm>
jfalempe: because you mentioned distros enabling for testing but they couldn't really do it without having a user-space KMS based VT, a wayland compositor in the initramfs, etc
<sima>
maybe put the reason why into the Kconfig text
fab has left #dri-devel [#dri-devel]
<javierm>
there's still a lot of missing pieces in the distros to make this feature useful IMO
<sima>
javierm, well also quite a few loose ends on the kernel side, but need to get going somehow somewhere
<jfalempe>
javierm, yes I think the drm_panic can still be useful without the KMS based VT.
aravind has quit [Remote host closed the connection]
aravind has joined #dri-devel
<javierm>
sima: agreed. Hence my suggestion to make it depends on !VT (although !FRAMEBUFFER_CONSOLE probably makes more sense)
<jfalempe>
I didn't get review a drm_panic v5, I will send a v6 with just rebase and warning fixes, and see if it gets more eyes.
<javierm>
jfalempe: I think what I meant is that wouln't add too much value if one already has a fbcon/VT
fab has joined #dri-devel
<sima>
javierm, otoh we could just limit to finishing the CONFIG_VT=n case and ignore all the remaining warts :-)
<javierm>
sima: exactly :)
<sima>
although I guess ogness would still want to make the entire vt layer use a vt_console_lock to untangle this mess from the core side
<jfalempe>
javierm, I still think drm_panic looks more professional, and with qrcode, it can also help distribution tracking panics.
<javierm>
jfalempe: that's true too
<agd5f>
dolphin, the radeon driver at one point had an option to use shaders for kernel paging IIRC, but I think that all got migrated to CP DMA and SDMA.
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
hansg has joined #dri-devel
iive has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
tristianc6704 has quit [Ping timeout: 480 seconds]
flom84 has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
Duke`` has joined #dri-devel
alyssa has quit [Quit: alyssa]
donaldrobson has quit [Ping timeout: 480 seconds]
flom84 has quit [Remote host closed the connection]
sima has quit [Read error: Connection reset by peer]
sima has joined #dri-devel
i509vcb has joined #dri-devel
cmichael has quit [Remote host closed the connection]
cmichael has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
cmichael has quit []
sgm has quit [Quit: sgm]
donaldrobson has joined #dri-devel
sgm has joined #dri-devel
frieder has quit [Remote host closed the connection]