ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
nchery is now known as Guest3491
nchery has joined #dri-devel
<jekstrand>
karolherbst: Sounds about right
<jekstrand>
karolherbst: It's probably timing out
<karolherbst>
ahh
<karolherbst>
that fast though?
<karolherbst>
although I think something is not right :D
<karolherbst>
with llvmpipe I am getting "write: 512 GB in 368.0 ms: 1391.4 GB/s"
<karolherbst>
what the heck is that thing doing
<karolherbst>
jekstrand: anything I can do so it doesn't time out?
iive has quit []
co1umbarius has joined #dri-devel
Guest3491 has quit [Ping timeout: 480 seconds]
columbarius has quit [Ping timeout: 480 seconds]
<Ristovski>
lol I love "Cool contexts are too cool to be banned! (Used for reset testing.)"
<karolherbst>
wait..
<karolherbst>
it simply creates a 1GB buffer and copies that all over again
<karolherbst>
yeah okay.. I guess llvm could optimize that shit away
<karolherbst>
dcbaker: do we support build profiles in meson for rust?
<karolherbst>
I might want to start adding debug specific code, because some issues start to become impossbiel to debug, but I also don't want release builds to suffer from it
<karolherbst>
and I need some workarounds where functions are static inline in release, but real function in debug
LexSfX has quit []
LexSfX has joined #dri-devel
<jekstrand>
karolherbst: Yeah, there are limits. Letting compute contexts run forever is on the ToDo list for i915 but it's a long road.
<karolherbst>
mhh, how is intels compute runtime handling it?
<jekstrand>
Getting banned unless you're running on a juiced kernel or with cmdline parameters set
<karolherbst>
mhhh
<jekstrand>
There was theoretical support for long-running contexts in theory for a while but it got pulled because it didn't actually work properly.
<karolherbst>
strange.. because I tihnk that test just works as is with their runtime
<karolherbst>
"128 GB in 6230.1 ms (20.5 GB/s)"
<karolherbst>
the bandwidth even seems reasonable
<karolherbst>
but I suspect that we might be doing something incorrectly somewhere... I just don't know what yet
<karolherbst>
the test is super trivial though
Company has quit [Quit: Leaving]
Kayden has quit [Quit: Leaving]
<karolherbst>
noooo.. now I can't lock my screen.. fun
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
Kayden has joined #dri-devel
stuart has quit []
jewins has quit [Ping timeout: 480 seconds]
jimjams has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Read error: Connection reset by peer]
heat has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
yoslin has quit [Quit: WeeChat 3.4.1]
yoslin has joined #dri-devel
consolers has joined #dri-devel
<consolers>
no clues for me about the opencl segfaults since mesa 21?
<consolers>
afaict all my mesa builds since i moved from 20.3 to 21.2 and since have the problem. if it is a problem with my setup, i need a clue about where to look
sdutt_ has joined #dri-devel
sdutt has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
mdroper has quit [Read error: Connection reset by peer]
itoral has joined #dri-devel
danvet has joined #dri-devel
itoral_ has joined #dri-devel
<HdkR>
consolers: I'd recommend building a debug version of mesa and getting a backtrace and creating an issue on it.
Kayden has quit [Read error: Connection reset by peer]
K`den has joined #dri-devel
itoral has quit [Ping timeout: 480 seconds]
K`den is now known as Kayden
<HdkR>
Three days asking about a segfault and no answers. Needs more information and better visibility tracking :)
<consolers>
ok i'll try that. should . with rc3 or relase
<consolers>
its happening since i moved to mesa-21
<airlied>
install debug symbols and get a backtrace in gdb
<consolers>
i'm on gentoo, it'll be a huge build
<consolers>
the question is should i rebuild my present media-libs/mesa-22.0.0 or get new sources
<airlied>
rebuild the one that is crashing seems like a good idea
<consolers>
the problem is i wont be able to test it without installing
<consolers>
if i use the gentoo framework
<consolers>
let me see...
frieder has joined #dri-devel
reductum has joined #dri-devel
<airlied>
Ristovski: yeah rusticl/amd is a fair bit away no matter which path I take or leave other people to take :-P
libv_ is now known as libv
cheako has quit [Quit: Connection closed for inactivity]
lumag_ has joined #dri-devel
frieder_ has joined #dri-devel
frieder_ has quit [Remote host closed the connection]
frieder has quit [Quit: Leaving]
frieder has joined #dri-devel
mvlad has joined #dri-devel
Daanct12 has joined #dri-devel
mceier has quit [Quit: Reconnecting]
mceier has joined #dri-devel
mszyprow has joined #dri-devel
consolers has quit [Ping timeout: 480 seconds]
zzoon[m] is now known as zzoon_holidays_till_8th[m]
Daanct12 has quit [Quit: Leaving]
Daanct12 has joined #dri-devel
MajorBiscuit has joined #dri-devel
jkrzyszt has joined #dri-devel
tursulin has joined #dri-devel
tzimmermann has joined #dri-devel
i-garrison has quit [Ping timeout: 480 seconds]
<pq>
HdkR, maybe you could replace "disable autodetect" with "force mode"? I have a feeling that might be more likely to exist in any compositor.
<HdkR>
Apparently wlroots has some understanding of virtual output as well
i-garrison has joined #dri-devel
<pq>
if it's virtual output you actually want, then sure
<pq>
I assumed this was about some KVM switch that messes up your whatever when you switch :-)
<HdkR>
yes, that's the exact problem case
mairacanal[m] has quit []
arisu has quit []
tintou has quit [Quit: Bridge terminating on SIGTERM]
Eighth_Doctor has quit []
go4godvin has quit [Quit: Bridge terminating on SIGTERM]
tomba has quit [Quit: Bridge terminating on SIGTERM]
Tooniis[m] has quit []
dcbaker has quit [Quit: Bridge terminating on SIGTERM]
MatrixTravelerbot[m] has quit []
kallisti5[m] has quit []
bylaws has quit [Quit: Bridge terminating on SIGTERM]
exit70[m] has quit []
unrelentingtech has quit []
Guest331 has quit []
gagallo7[m] has quit []
Anson[m] has quit []
onox[m] has quit []
gnustomp[m] has quit []
YaLTeR[m] has quit []
hasebastian[m] has quit []
cwfitzgerald[m] has quit []
yshui` has quit []
jenatali has quit [Quit: Bridge terminating on SIGTERM]
pushqrdx[m] has quit []
reactormonk[m] has quit []
nielsdg has quit []
masush5[m] has quit []
Dylanger has quit [Quit: Bridge terminating on SIGTERM]
heftig has quit [Quit: Bridge terminating on SIGTERM]
danylo has quit [Quit: Bridge terminating on SIGTERM]
neobrain[m] has quit []
Newbyte has quit [Quit: Bridge terminating on SIGTERM]
DrNick has quit []
MrR[m] has quit []
PiGLDN[m] has quit []
DavidHeidelberg[m] has quit []
ralf1307[theythem][m] has quit []
Sumera has quit [Quit: Bridge terminating on SIGTERM]
T_UNIX has quit []
doras has quit [Quit: Bridge terminating on SIGTERM]
robertmader[m] has quit []
kusma has quit [Quit: Bridge terminating on SIGTERM]
aura[m] has quit []
Andy[m] has quit []
Strit[m] has quit []
chema has quit [Quit: Bridge terminating on SIGTERM]
znullptr[m] has quit []
undvasistas[m] has quit []
jasuarez has quit [Quit: Bridge terminating on SIGTERM]
mripard has quit [Quit: Bridge terminating on SIGTERM]
cleverca22[m] has quit []
zamundaaa[m] has quit [Quit: Bridge terminating on SIGTERM]
tonyk has quit [Quit: Bridge terminating on SIGTERM]
LaughingMan[m] has quit []
shadeslayer has quit [Quit: Bridge terminating on SIGTERM]
x512[m] has quit []
Mis012[m] has quit [Quit: Bridge terminating on SIGTERM]
martijnbraam has quit [Quit: Bridge terminating on SIGTERM]
egalli has quit []
Vin[m] has quit []
RAOF has quit []
gdevi has quit []
chivay has quit []
halfline[m] has quit []
zzoon_holidays_till_8th[m] has quit []
JosExpsito[m] has quit []
jekstrand[m] has quit []
Mershl[m] has quit []
sigmoidfunc[m] has quit []
moben[m] has quit []
naheemsays[m] has quit []
bluepenquin has quit [Quit: Bridge terminating on SIGTERM]
dhanuka[m] has quit []
mighty17 has quit []
unevenrhombus[m] has quit []
ramacassis[m] has quit []
itoral_ has quit [Remote host closed the connection]
<javierm>
tzimmermann: so there are two things that are still missing 1) make sysfb handle the unregistration of the platform devices registered by it and 2) disable sysfb when a driver is probed
<javierm>
(2) also should unregister the device if sysfb registered it, that's why we need (1)
consolers has joined #dri-devel
<consolers>
ok i have a backtrace for the clinfo segfault: http://ix.io/3WVD
<javierm>
jfalempe: those have been reviewed by Lyude already right? Maybe we could land that so tzimmermann can re-send on top ?
<javierm>
actually, better if tzimmermann reviews those ones and then you can trade with him :)
<jfalempe>
Yes, Lyude wanted tzimmermann to review as well ;)
<jfalempe>
I'm preparing another patch for better gamma support for mgag200 too.
<javierm>
jfalempe: you also will be a much better reviewer for his patches than me, since you are already familiar with the driver code
<tzimmermann>
jfalempe, i didn't see your patch. i'll review soon
<javierm>
tzimmermann: just ignore this problem is also an acceptable answer for me. It's just that danvet wanted to land the last two patches of that series, and can't be done until we fix the race
<jfalempe>
tzimmermann, thanks, that's a good trade ;)
<tzimmermann>
jfalempe, ah yep. the gamma-lut setup is horrible
<tzimmermann>
it's still from the times when mgag200 was non-atomic
<jfalempe>
yes, that don't work with gnome3 night-time setup.
<jfalempe>
also there are some special case for 16bits. I'm not sure if there are really needed.
<tzimmermann>
jfalempe, BTW i intent to replace mgag200's simple-kms with regular atomic helpers. and also rework the way differnt models are handled. but please don't wait for these changes
<tzimmermann>
i'm looking forward to the gamma changes. i always wanted to fix that, but never had the time. thanks for working on this
<tzimmermann>
javierm, we wanted to disable sysfb when we register the first native driver, right?
<javierm>
tzimmermann: yes
apinheiro has joined #dri-devel
pcercuei has joined #dri-devel
<jfalempe>
I've looked into this, because there is a bug in mutter, where it always try to set gamma, even if driver doesn't support it.
<javierm>
ah, matrox cards are common in server hardware. I wondered why you folks had so much interest in this driver :)
<javierm>
tzimmermann: and that's what I did in v4
<tzimmermann>
it has a retro feeling to it :)
<javierm>
haha
<tzimmermann>
javierm, can we do without DRIVER_FIRMWARE?
itoral_ has quit [Remote host closed the connection]
<javierm>
tzimmermann: not really, because otherwise the DRM core has no way to know that simledrm is the driver registered the DRM device and will attempt to remove its own platform device
itoral_ has joined #dri-devel
<javierm>
tzimmermann: so is either add a new DRIVER_FIRMWARE capability or do it at remove_conflicting_framebuffers() time
<javierm>
since simpledrm and other drivers using a firmware provided fb won't call that
<javierm>
I'm leaning towards the latter
<danvet>
lynxeye, if you want me to just apply your patch and do the additional fix as a follow up I guess just tell me
<tzimmermann>
javierm, i have a meeting now. i'll get back to you later today
<javierm>
tzimmermann: doing it at register_framebuffer() (for fbdev) and drm_dev_register() (for DRM) is more correct, agree but a good compromise is doing it at remove_conflicting_framebuffers() to avoid a new cap
<javierm>
tzimmermann: Ok, later!
itoral_ has quit [Remote host closed the connection]
itoral_ has joined #dri-devel
hch12907 has quit [Ping timeout: 480 seconds]
jimjams has quit [Quit: Connection closed for inactivity]
consolers has quit [Ping timeout: 480 seconds]
<danvet>
javierm, trying again to catch up a bit, which patch set should I look at?
itoral_ has quit [Remote host closed the connection]
itoral_ has joined #dri-devel
itoral_ has quit [Remote host closed the connection]
hch12907 has joined #dri-devel
itoral_ has joined #dri-devel
itoral_ has quit [Remote host closed the connection]
<javierm>
danvet: and the question was whether we want to add a new DRM_FIRMWARE cap (like the patch-set does) or just do the sysfb disable and pdev removal at remove_conflicting_framebuffers(), as was done in v2
<javierm>
I'm leaning towards the latter, but tzimmermann suggested the former so I wanted to get an agreegment with him about the preferred approach
<danvet>
javierm, maybe I get it all wrong, but I thought we have to do the removal upfront at remove_conflicting_fb time
<danvet>
by drm_dev_register time it's too late
<danvet>
maybe something uber-clever like doing it at drm_dev_alloc time might work, but it seems very wonky to make an alloc function change stuff like that
<javierm>
danvet: right. I should be more precise. We are doing the removal at remove_conflicting_fb time but the question is about the disable
<javierm>
but the disable also implies a removal if that wasn't done before
<danvet>
hm but if you disable later, wont there be a race?
<danvet>
or I'm confused
<javierm>
danvet: right. No, you are not confused... that's true
<javierm>
between removing the conflicting framebuffers and registering the DRM device there's a critical section where sysfb could register a "simple-framebuffer" device and that match simpledrm driver
itoral_ has quit [Remote host closed the connection]
maxzor has joined #dri-devel
itoral_ has joined #dri-devel
<javierm>
danvet: that's an easy answer then, we must do the disable at remove_conflicting_framebuffers() time, and since that's not called by drivers using a firmware-provided FB, there's no need for DRIVER_FW cap
itoral_ has quit [Remote host closed the connection]
itoral_ has joined #dri-devel
Daanct12 has quit [Quit: Leaving]
itoral_ has quit [Remote host closed the connection]
itoral_ has joined #dri-devel
itoral_ has quit [Remote host closed the connection]
itoral_ has joined #dri-devel
itoral_ has quit [Remote host closed the connection]
itoral has joined #dri-devel
<danvet>
javierm, well that leaves FB_INFO_MISC_FIRMWARE, but I'm not sure that actually matters when we nuke simpledrm through the sysfb device
<danvet>
since "is it the driver bound against the sysfb device" is a much more precise check
<danvet>
javierm, or is there some other use for the drm fw driver cap flag?
<danvet>
(that I'm missing I mean)
itoral has quit [Remote host closed the connection]
<javierm>
danvet: so if that lands, then there's no need anymore for the drm fw driver cap flag
<danvet>
javierm, do we need to set that flag even?
<danvet>
it seems to impact only two places: the fb removal (where we don't need it when we do it all through sysfb)
<danvet>
and some really funky font freeing special case on the virtual console
<javierm>
danvet: I believe we do, for the corner case where you have simpledrm but then a real fbdev driver is probed that would want to kick out simpledrm
<javierm>
danvet: because the remove confliciting fb loop has:
<javierm>
if (!(registered_fb[i]->flags & FBINFO_MISC_FIRMWARE))
<danvet>
uh
<danvet>
can we just not care about that case?
<danvet>
or if we do, teach fbdev to also nuke sysfb as needed?
<javierm>
danvet: fbdev will nuke sysfb if we set FBINFO_MISC_FIRMWARE for simpledrm
<javierm>
or rather, will nuke the pdev associated with the fbdev registered by simpledrm
itoral has quit [Remote host closed the connection]
<javierm>
danvet: but I don't think that could cause any harm to set FBINFO_MISC_FIRMWARE, that feels the correct thing to do
<javierm>
danvet: and the other two patches in that series have merit on its own IMO
<javierm>
the first 3 patches from that series could be dropped and the DRIVER_FW cap not needed since we will disable sysfb at remove conflicting fb time
<danvet>
javierm, twice the same link?
<javierm>
gah
<danvet>
javierm, 9a45ac2320d0a just stumbled over this
<danvet>
agd5f, ^^ did we figure out more what's going on there with efifb?
itoral has quit [Remote host closed the connection]
<danvet>
javierm, yeah I guess makes sense
<danvet>
javierm, note that default bpp is a different can of worms, I kinda want to outright nuke that entire thing because it's so much wrong
<danvet>
but never got anywhere
<danvet>
we mix up bpp and depth
itoral has joined #dri-devel
<javierm>
danvet: yes, I noticed the FIXME in drm_fbdev_generic_setup()
<javierm>
danvet: but this is actually in preparation of nuking it. Since then drm_fbdev_generic_setup() won't have a bpp param anymore and can be removed from "options"
Andy[m] has joined #dri-devel
aura[m] has joined #dri-devel
bylaws has joined #dri-devel
Guest26 has joined #dri-devel
chema has joined #dri-devel
chivay has joined #dri-devel
RAOF has joined #dri-devel
Eighth_Doctor has joined #dri-devel
cleverca22[m] has joined #dri-devel
cwfitzgerald[m] has joined #dri-devel
dcbaker has joined #dri-devel
Anson[m] has joined #dri-devel
dhanuka[m] has joined #dri-devel
Guest21 has joined #dri-devel
doras has joined #dri-devel
danylo has joined #dri-devel
Dylanger has joined #dri-devel
itoral has quit [Remote host closed the connection]
egalli has joined #dri-devel
exit70[m] has joined #dri-devel
gagallo7[m] has joined #dri-devel
gdevi has joined #dri-devel
gnustomp[m] has joined #dri-devel
Guest29 has joined #dri-devel
halfline[m] has joined #dri-devel
hasebastian[m] has joined #dri-devel
heftig has joined #dri-devel
zzoon_holidays_till_8th[m] has joined #dri-devel
jasuarez has joined #dri-devel
jekstrand[m] has joined #dri-devel
jenatali has joined #dri-devel
JosExpsito[m] has joined #dri-devel
kallisti5[m] has joined #dri-devel
kusma has joined #dri-devel
LaughingMan[m] has joined #dri-devel
mairacanal[m] has joined #dri-devel
martijnbraam has joined #dri-devel
masush5[m] has joined #dri-devel
Mershl[m] has joined #dri-devel
mighty17 has joined #dri-devel
Mis012[m] has joined #dri-devel
moben[m] has joined #dri-devel
mripard has joined #dri-devel
Vin[m] has joined #dri-devel
naheemsays[m] has joined #dri-devel
neobrain[m] has joined #dri-devel
Newbyte has joined #dri-devel
nielsdg has joined #dri-devel
DavidHeidelberg[m] has joined #dri-devel
onox[m] has joined #dri-devel
PiGLDN[m] has joined #dri-devel
pmoreau has joined #dri-devel
pushqrdx[m] has joined #dri-devel
r[m] has joined #dri-devel
ralf1307[theythem][m] has joined #dri-devel
ramacassis[m] has joined #dri-devel
reactormonk[m] has joined #dri-devel
robertmader[m] has joined #dri-devel
shadeslayer[m] has joined #dri-devel
itoral has joined #dri-devel
sigmoidfunc[m] has joined #dri-devel
Strit[m] has joined #dri-devel
Sumera[m] has joined #dri-devel
T_UNIX has joined #dri-devel
tintou has joined #dri-devel
tomba has joined #dri-devel
tonyk has joined #dri-devel
Tooniis[m] has joined #dri-devel
undvasistas[m] has joined #dri-devel
unevenrhombus[m] has joined #dri-devel
unrelentingtech has joined #dri-devel
MatrixTravelerbot[m] has joined #dri-devel
x512[m] has joined #dri-devel
<javierm>
danvet: notice that is_firmware_framebuffer() also checks for if (!(registered_fb[i]->flags & FBINFO_MISC_FIRMWARE))
YaLTeR[m] has joined #dri-devel
yshui` has joined #dri-devel
zamundaaa[m] has joined #dri-devel
znullptr[m] has joined #dri-devel
pmoreau is now known as Guest33
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<javierm>
so setting that for the simpledrm emulated fbdev really feels idiomatic
rkanwal has joined #dri-devel
<tzimmermann>
javierm, danvet, about the DRIVER_FIRMWARE flag: maybe let's rather use a dedicated dev_register function in simpledrm that does not disable sysfb
<danvet>
tzimmermann, dev_register should never disable sysfb for anyone is my take
<javierm>
tzimmermann: see danvet's comment about being too late at that point
<javierm>
tzimmermann: we really should do it at remove_conflicting_fb time
<tzimmermann>
why would that be it too late?
<tzimmermann>
javierm, saw your comment on that
<tzimmermann>
so we have to disable sysfb first and then kick out the existing firmware fb's
<danvet>
javierm, caught up on some other discussions and I'm not sure that fb_release fix is sound
<javierm>
tzimmermann: yes, or at least in the same section holding the registration lock
<javierm>
danvet: oh, really? already landed in -fixes :/
<danvet>
javierm, yeah hence the ping here
<javierm>
danvet: just saw your email, let me look at the code again
<javierm>
danvet: btw, this is a bug reported by 3 different people so even when papering over the issue, it prevents a NULL pointer deref on fbdev close
Duke`` has quit [Ping timeout: 480 seconds]
sdutt_ has quit [Ping timeout: 480 seconds]
<danvet>
javierm, yeah leaking helps to paper over null deref :-)
Duke`` has joined #dri-devel
<danvet>
javierm, do you know on which exact pointer we're blowing up on?
<javierm>
danvet: yes, struct fb_info * const info in fb_release()
<javierm>
danvet: I stand that the fix is the best we can do given the current situation
<javierm>
danvet: the whole "fb_info can change and then you need to check if file->private_data is still valid" is insane really, but that's how things are
<danvet>
well fbdev is wonky at best
itoral has quit [Remote host closed the connection]
<danvet>
javierm, can I convince you for a revert? I really don't think this is the right fix
itoral has joined #dri-devel
<javierm>
danvet: sure, but can we first agree on the right fix? I just don't want to do a revert and then a revert revert if we find that's the proper workaround
<danvet>
I haven't seen yet where exactly we blow up
itoral has quit [Remote host closed the connection]
icecream95 has quit [Ping timeout: 480 seconds]
<danvet>
javierm, I have no idea
<danvet>
javierm, minimally this needs a giantic comment that fbdev is too screwed and it's easier to just leak when we race against removal
<danvet>
it's definitely a very wrong fix, that's for sure
flacks has quit [Quit: Quitter]
<danvet>
javierm, I think I have it
<danvet>
most drivers are bs when their driver remove callback is called
<danvet>
instead of proper refcounting, they just unconditionally nuke the underlying fb_info
<danvet>
any driver which has framebuffer_release() called from their ->remove callback instead of ->fb_destroy callback is busted
<danvet>
javierm, note that the new drm fbdev emulation built on top of drm_client is I think the only fbdev implementation which gets this right
<danvet>
and the reason this is regressing due to 27599aacbaefcbf2af7b06b0029459bbf682000d is because that switched from unregister_framebuffer to removething the device
<danvet>
the former simply leaks the entire driver crap, the latter calls into the driver's ->remove which then releases the fb_info, but way too early
<danvet>
boom
<danvet>
90% confident this is t
<danvet>
*it
* danvet
off for lunch now
<javierm>
danvet: interesting, that makes sense. I'll take a look
<javierm>
danvet: enjoy!
flacks has joined #dri-devel
<danvet>
javierm, I expect if you dig into the assembly of the splat it blows up in some debug pointer in struct mutex or so
<danvet>
which has become garbage
<danvet>
but I don't really do arm assembly :-)
<javierm>
danvet: efifb has the same issue btw
<javierm>
but in this case the bug happened with simplefb
<javierm>
fbdev is really wicked
<danvet>
yeah
<danvet>
luckily we only have to fix the FBINFO_MISC_FIRMWARE drivers
<javierm>
yeah
<javierm>
danvet: and in the future only simpledrm
<javierm>
danvet: it's somehow ironic that the reason why tzimmermann and me are fixing all this fbdev issues is because we want to get rid of it :)
MajorBiscuit has quit [Ping timeout: 480 seconds]
<karolherbst>
jekstrand: deadlock on the bufmgr :(
MajorBiscuit has joined #dri-devel
<karolherbst>
no clue on how that can happen though
<danvet>
karolherbst, userspace bufmgr?
<karolherbst>
yes
<danvet>
impressive indeed :-)
<karolherbst>
probably I am doing something stupid :)
<karolherbst>
CL contrary to GL is actually heavily threaded
<karolherbst>
so.. most APIs are just thread safe
<karolherbst>
and here is the fun part: they are not dead lock safe
<danvet>
javierm, well it's the same with Xorg
<danvet>
the people who really know why it should be nuked are also the only ones qualified to fix any bugs in there
* dv_
is now reminded of the X.org presentation by daniels :)
<danvet>
karolherbst, there's like cl callbacks which allow the driver to call into cl again
<dv_>
err, wayland presentation
Company has joined #dri-devel
<karolherbst>
danvet: yeah, I know :)
morphis has quit [Ping timeout: 480 seconds]
<danvet>
karolherbst, oh I mean this was a question?
<danvet>
if yes, that sounds a bit cursed :-)
<karolherbst>
it is, the API spec even is saying so: you might dead lock, be careful
<karolherbst>
:D
morphis has joined #dri-devel
mclasen has quit [Remote host closed the connection]
<emersion>
daniels: re wl presentation protocol, how can we unblock the situation? would anyone from the weston side have time for this?>
<danvet>
javierm, simplefb is kinda finny since it drops the iomap from fb_destroy, despite that hw stuff should be dropped from ->remove
<danvet>
so it's kinda exactly the opposite of what it should be
<danvet>
but also given that simplefb doesn't tear down the mmap it's meh anyway
<danvet>
imo not worth fixing
<karolherbst>
ahh.. memory corruption.. nice
<javierm>
danvet: yeah... it seems that for every patch I posted, I end with couple of patches more needed
<danvet>
but it's the "devm for hw, drmm for sw" topic all over again
<javierm>
danvet: the branching factor in fbdev is a thing :)
<danvet>
javierm, well we only need to fix the bugs we uncover and get regression reports for
<danvet>
not all the others
<tzimmermann>
javierm, danvet: that last put can be quite some time later?
<danvet>
especially for hotplug lifetim lolz I think "use drm with fbdev emulation" is totally fine answer
<danvet>
tzimmermann, yeah
<javierm>
tzimmermann: yes, because it may be that you remove the driver but still user-space has a reference to fb_info
<danvet>
whenever userspace closes the last /dev/fb/* file
<javierm>
i.e: can close the fbdev fd much later
hch12907 has quit [Ping timeout: 480 seconds]
<javierm>
danvet: that open, mmap, write, close uAPI is really terrible
<tzimmermann>
does fbdev release the resources in time? because that's why we added hot-unplug in the first place
<tzimmermann>
vmwgfx tried to acquire the framebuffer that was still reserved by simplefb; hence failed to do so
<javierm>
tzimmermann: I don't think it does, that's why danvet suggested to make the mmap'ed writes to do a SIGBUS
sagar_ has quit [Remote host closed the connection]
Namarrgon has quit [Ping timeout: 480 seconds]
<danvet>
tzimmermann, the unregister_framebuffer needs to happen synchronously
<javierm>
tzimmermann: ah, you mean the I/O mem region. Yes, I believe it does in remove
sagar_ has joined #dri-devel
<danvet>
it's the fb_info kfree which needs to be deleayed
<tzimmermann>
ok
<danvet>
javierm, yeah tbh I'm tempted for a FBINFO_MISC_NOT_SHIT flag which just blindly uses the fb_info from file->private_data
<tzimmermann>
otherwise, we'd be back to the original problem
<danvet>
which we set for drm_client fbdev emulation
<danvet>
since that has a) proper lifetime and b) drm drivers should take care of hotunplug races with drm_dev_enter already
<javierm>
danvet: btw, I just noticed today that fbdev emulation is implemented as a drm_client
<javierm>
so cool, that blew my mind
<danvet>
and leave the horror show uapi for "real" fbdev drivers
<danvet>
javierm, not for all drivers
<tzimmermann>
javierm, it's the only drm_client :)
<danvet>
there's still a pile which hand-roll iirc, and those tend to have a bunch of issues all over
<danvet>
tzimmermann, there were patches for a nice boot splash using drm_client
<tzimmermann>
indeed
<danvet>
and also I think some kgdb resurrection using that
<tzimmermann>
one day....
<javierm>
danvet, tzimmermann: yes, and also for a drmlog
<danvet>
yeah one day :-)
* danvet
also hopefully, a lot has moved already
<javierm>
or drmcon, can't remember
<danvet>
yeah one of them
<danvet>
javierm, uh just realized, we have to move that iounmap to ->remove
<danvet>
since currently it is actually done there due to the unconditional call to framebuffer_release
<danvet>
javierm, so yeah actually everything in simplefb_destroy needs to be called from _remove
Duke`` has quit [Ping timeout: 480 seconds]
<danvet>
I think so at least
<danvet>
maybe I'm confusing myself again
<daniels>
emersion: yep, I'm definitely willing to put time into it - I think the best next steps are to figure out a) exactly what we need to make Vulkan FIFO work without blocking, and b) find out from media people exactly what they want for their queueing and the semantics, and just do the most achievable thing
<daniels>
I've been doing a little bit of groundwork on Weston to make it easier to experiment with
<danvet>
ah no framebuffer_release does not call ->fb_destroy
<tzimmermann>
it could be some soft limit, so that videomode isn't to close to the actual hardware limits (i.e., use only 80% of the available bandwidth)
<tzimmermann>
but really, i don't understand what this function really does
<tzimmermann>
and i couldn't find similar code in the old matroxfb or x11 drivers
<tzimmermann>
and mgag200 appears to be the only driver tha does this test
pcercuei has quit [Quit: brb]
Duke`` has quit [Ping timeout: 480 seconds]
shadeslayer[m] has quit []
shadeslayer[m]1 has joined #dri-devel
shadeslayer[m]1 has quit []
shadeslayer[m]1 has joined #dri-devel
pcercuei has joined #dri-devel
Namarrgon has joined #dri-devel
Namarrgon has quit []
consolers has joined #dri-devel
Namarrgon has joined #dri-devel
ivyl has quit [Quit: end of flowers]
<consolers>
so it looks like a gcc bug? i'm on gcc-11.2.0 - in gdb mesa-22.0.0/src/gallium/drivers/iris/iris_disk_cache.c:276, note = 0x0 and there is an assert (not && build_id_length(note) == 20) there which does not trigger
<consolers>
oh no not again
<consolers>
this was with -O2 -g
<consolers>
but the crash is a few lines down
<consolers>
isp is flakey again. i have a matrix acct on intel gfx but not here
<jfalempe>
tzimmermann, sometime I just copy this function in a test program, and see what it gives with real-world value. It helps to decide on the brokenness of the code ;)
<consolers>
looking at mesa-22.0.0/src/util/build_id.c:118 (build_id_find_nhdr_for_addr): it looks like dl_iterate_phdr(build_id_find_nhdr_callback, &data) succeeds but data.note which is returned is 0x0
<consolers>
is there some env variable to disable shader cache?
<consolers>
nothing relevant has changed in the mesa side between mesa-20.2.0 and mesa-21.2.1 which is where i first started encountering the crash
<consolers>
maybe i had a gcc upgrade at that point?
ivyl has joined #dri-devel
<consolers>
maybe i'll try rebuilding with -O0 later
<daniels>
danvet: I think KMS semantics would fall out of the compositor, but it's different enough it wouldn't be a carbon copy
<danvet>
daniels, yeah and I guess the only reason to add fifo to the kernel is to expose the hw fifos
<danvet>
otherwise not much point really
<danvet>
and I have no idea how to expose the hw fifo flip queues since the limitations are tricky
<danvet>
so maybe kms needs a "queue this as fifo, but only if you can put it into the hw fifo queue completely, otherwise don't bother"
<zmike>
dcbaker: pushed
<consolers>
that might solve the halting problem
consolers has quit [Quit: /l]
rkanwal has quit [Quit: rkanwal]
sagar_ has quit [Remote host closed the connection]
sagar_ has joined #dri-devel
devilhorns has joined #dri-devel
<agd5f>
danvet, I don't think it was anything wrong with efifb. seems to be related to runtime pm and amdgpu. At least the issue I was fixing with the fbdev patch a few kernels ago
<agd5f>
feel free to drop that patch if you need to. We have a better fix in amdgpu now
apinheiro has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Quit: WeeChat 3.4]
<danvet>
agd5f, nah if it's already solved then that's all good, it's not getting in the way anywhere
<danvet>
was just reviewing users of FBINFO_MISC_FIRMWARE
<danvet>
so if the amdgpu caller of the is_firmware_fb helper is already out and that's all unexported again then perfect
<danvet>
agd5f, the maybe issue is that simpledrm doesn't set this flag, so if that's loaded instead of efifb it might upset things a bit
<danvet>
maybe, not sure really
<agd5f>
it still calls it, but it's no longer necessary
<agd5f>
I can drop it
<danvet>
agd5f, hm if you can gc that code would be nice
<danvet>
thx
<agd5f>
np
mihai has joined #dri-devel
<MrCooper>
agd5f: glad you guys found a better solution for that
preda has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
shadeslayer[m]1 has quit []
shadeslayer[m] has joined #dri-devel
shadeslayer[m] has quit []
shadeslayer[m] has joined #dri-devel
mihai has quit []
jewins has joined #dri-devel
moony has quit [Read error: Connection reset by peer]
moony has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
shadeslayer has joined #dri-devel
iive has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
karolherbst: it works!
<karolherbst>
alyssa: \o/
hch12907 has joined #dri-devel
<zmike>
pepp: are you planning to submit a fix for that subgroup test?
kchibisov_ has joined #dri-devel
kchibisov has quit [Read error: Connection reset by peer]
Haaninjo has joined #dri-devel
<karolherbst>
"128 GB in 362.1 ms (353.5 GB/s)" this is actually correct...
<karolherbst>
the benchmark is just shitty
<karolherbst>
(it writes 128 times into the same buffer with the same values)
<karolherbst>
I don't think nir can look behind that, but llvm seems to be able to
<alyssa>
what benchmarks *aren't* shitty
<alyssa>
is gfxbench any good?
<karolherbst>
yeah
<karolherbst>
I think..
<karolherbst>
gputest is also quite nice
<alyssa>
I really need to get FEX set up so I can run things that aren't glmark2 and neverball
* karolherbst
starts looking into why darktable renders garbage
<alyssa>
HdkR: ^^ Is there a nice way to slot in my own mesa buidlds into FEX? (Keeping in mind I do trickery with LIBGL_DRIVERS_PATH etc for dev)
Duke`` has joined #dri-devel
consolers has joined #dri-devel
<consolers>
its probably not a gcc bug. apparently the build-id is not being found
shadeslayer is now known as Guest90
shadeslayer[m] is now known as shadeslayer
<consolers>
meson prints out: Compiler for C supports link arguments -Wl,--build-id=sha1: YES
Guest29 is now known as go4godvin
<consolers>
and the -Wl,--build-id=sha1 is there in the parameters for -o src/gallium/targets/dri/libgallium_dri.so
<consolers>
can i use nm or something to check the build-id on the .so directly?
<consolers>
ah but no -Wl.--build-id when generating pipe_iris.so - that would do it?
<jekstrand>
karolherbst: That should be unpossible
<karolherbst>
jekstrand: mhh? what?
<consolers>
i cant see which meson.build is building pipe_iris.so
ella-0 has joined #dri-devel
<consolers>
i think that is missing a ld_args_build_id, but how did i not get a segfault in 20.x
<jekstrand>
karolherbst: deadlocking in bufmgr
<karolherbst>
jekstrand: ahh yeah.. it was a use after free
<karolherbst>
atm I am debugging darktable now to figure out why scaling doesn't work :(
ella-0_ has quit [Read error: Connection reset by peer]
<karolherbst>
it actually does some serious business compared to anything I tried rusticl on before
<karolherbst>
ahh.. let me check if there is a difference between 50% and 200% (200% works, like any multiples of 100%)
<karolherbst>
ahh
<consolers>
success! after this patch http://ix.io/3WXJ i don't get the segfault anymore
<karolherbst>
broken scalings have a weird __wrapped_interpolation_resample kernel
<consolers>
i still cant explain how it worked with 20.x
<consolers>
can someone take a look at that and my backtrace posted earlier http://ix.io/3WVD
anarsoul has quit [Ping timeout: 480 seconds]
anarsoul has joined #dri-devel
<karolherbst>
uhhh
<karolherbst>
shared
cheako has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
<consolers>
this is also opencl?
<karolherbst>
I think I found it..
<karolherbst>
nope.. must be sometihng else
heat has joined #dri-devel
<karolherbst>
but I am sure something is up with coords
<karolherbst>
sooo..
maxzor has quit [Ping timeout: 480 seconds]
<karolherbst>
every line on the x axis gets all values from the right border
sdutt has joined #dri-devel
consolers has quit [Quit: /]
Guest21 is now known as DrNick
<pepp>
zmike: probably at some point but it's not a priority
<karolherbst>
jekstrand: ... barriers are only legal outside of CF structures, right?
<karolherbst>
well at least in glsl
<karolherbst>
sooo... what if we have a scoped_barrier inside a loop with an divergent if right in front of it
<cwabbott>
karolherbst: barriers for compute shaders in glsl can be anywhere, but they can't be in divergent control flow
<karolherbst>
right...
<karolherbst>
I guess then that's file what's happening as long as all threads enter the barrier, no?
<karolherbst>
or would they ahve to enter the barrier at the same time?
<cwabbott>
control flow has to reconverge
<cwabbott>
so I guess they have to enter "at the same time"
<karolherbst>
mhh
<karolherbst>
so an if without an else before the barrier would mean the threads are divergent, correct? (it's probably impossible to write ifs in a way you can make sure they converge after, but)
<jekstrand>
karolherbst: I think there are rules in CL around this but they may be tricky and our structurization may not be aware of them.
<jekstrand>
s/may/is/
<karolherbst>
jekstrand: in CL you can place it anywhere
<karolherbst>
so we have to make sure we converge the threads
<karolherbst>
anyway.. the nir matches the OpenCL C code
<karolherbst>
it's just that the threads diverge because of the if I think...
<karolherbst>
not 100% sure
<karolherbst>
yeah.. so the if depends on the thread id
<jenatali>
karolherbst: "If the barrier is inside a conditional statement, then all work-items in the work-group must enter the conditional if any work-item in the work-group enters the conditional statement and executes the barrier."
<karolherbst>
and the loop variable
<jenatali>
Looks like has to be uniform control flow to me
<karolherbst>
jenatali: I tihnk this is more a req to the runtime
<karolherbst>
the runtime has to make sure that this happens
<jenatali>
Hm? I'm looking at the CL C spec
<karolherbst>
but the barrier is inside a loop, not an if
<karolherbst>
"If the barrier is inside a loop, then all work-items in the work-group must execute the barrier on each iteration of the loop if any work-item executes the barrier on that iteration."
<karolherbst>
that sounds like the assumption doens't hold for OpenCL
<karolherbst>
ehh.. workgroup_size_variable is true though
mszyprow has quit [Ping timeout: 480 seconds]
<karolherbst>
mhh
nchery has joined #dri-devel
<karolherbst>
maybe I should mess with the darktable kernels a little and figure out if that's indeed the kernel causing issues
alyssa has left #dri-devel [#dri-devel]
<dcbaker>
karolherbst: the `-Doptimization` flag is supported, but meson doesn't have anything like Rust's customizable profiles, and the `-Dbuildtype` is kinda sorta deprecated
<dcbaker>
zmike: thanks!
gouchi has joined #dri-devel
<danvet>
mlankhorst, I'm a bit lost?
<danvet>
and I'm not sure what you mean with gtt relocations
<karolherbst>
dcbaker: right... that was kind of my worry
<danvet>
I think I have a vague idea, but it all sounds really scary
<dcbaker>
karolherbst: that's an intentional design decision because of how much of a disaster customizable profiles are in cmake
<karolherbst>
dcbaker: I think it makes sense to support it at least for "test", but...
<karolherbst>
ahhh :( it's indeed that kernel causing issues
<karolherbst>
if I just pipe through the input kernel, the output looks fine (but wrong)
<karolherbst>
but the good news is.. besides that little detail.. rusticl is able to run darktable CL kernels :)
apinheiro has joined #dri-devel
<karolherbst>
yeah.. it's that loop
<karolherbst>
annoying
<danvet>
agd5f, thx for spinning the patches, I dropped some comments since I guess you need even more work to really polish this :-)
<danvet>
but yeah one step at a time and all that
gouchi has quit [Ping timeout: 480 seconds]
<danvet>
agd5f, unfortunately I don't think lockdep can catch these, since it's another case of cross release dependencies
<danvet>
also in practice probably impossible to hit
FireBurn has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
<zmike>
dcbaker: will probably have a final batch in the next couple days, which I guess should be just in time for the scheduled release next week
<agd5f>
danvet, thanks. I think the proper fix is to not just send hotplugs even when we resume (which was good enough for system suspend), but to compare the presuspend display state with the postsuspend display state and only send a hotplug event if anything changed, but I haven't had time to page atomic into my head again recently.
<agd5f>
danvet, preference on tree for those patches?
<danvet>
agd5f, oh wherever you like most, either yours or drm-misc
<agd5f>
thanks
<danvet>
agd5f, so on rpm vs connector hotplug
<danvet>
one annoying thing kinda is that you don't get interrupts anymore when the chip is fully off
<agd5f>
right
<danvet>
so strictly speaking we should put the detect logic into polling mode again (but maybe not too often)
<danvet>
i915 has been trying to get all these corner rights, but it's a bit an endless thread
<danvet>
i915 has it's own detect loop (mostly due to the interrupt storm issues)
<danvet>
but might be worth to push some kind of function for this into probe helpers since it's not entirely trivial
<danvet>
and then maybe you can drop the unconditional uevent from rpm resume and then maybe things even work?
<agd5f>
danvet, that's the hope
angerctl has joined #dri-devel
Namarrgon has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
jagan_ has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
hch12907 has quit [Ping timeout: 480 seconds]
sdutt has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
<jekstrand>
karolherbst: Any new thoughts on my poor RTX 2060?
<karolherbst>
jekstrand: I'd wait until Ben manages to publish his patches :D he promised me to do that last week though. At least last time I spoke to him (that was after you pinged me on the bug) he said, that's close to ready
<jekstrand>
hehe, ok.
<karolherbst>
mhh.. that kernel is annoying :( it's broken on llvmpipe as well
* karolherbst
wants darktable to run perfectly
<karolherbst>
jekstrand: you don't happen to know how all that barrier/thread converging/whatever stuff works on intel?
<karolherbst>
although it could be something else in the kernel, it's just not a very complicated one
<karolherbst>
just tons of shared mem stuff
<jekstrand>
No, I don't
<karolherbst>
heh.. wait...
<karolherbst>
there are three local mem buffers
<karolherbst>
I hope I didn't messed this up
<karolherbst>
ahhhhh
<karolherbst>
crap
<karolherbst>
I think I found it
ppascher has quit [Ping timeout: 480 seconds]
<karolherbst>
I don't offset the buffers :)
<karolherbst>
so all three shared mem buffers start at 0x0
<karolherbst>
that's not good
<karolherbst>
(and how did the CTS not catch this)
<jekstrand>
:D
<karolherbst>
yay
<karolherbst>
it works
<jekstrand>
:+1:
<karolherbst>
it feels slower than the CPU though
<karolherbst>
yeah.. CPU gets it done close to instantly, but with rusticl it takes a while on iris
<karolherbst>
oh well
<karolherbst>
I hope that's because of debug builds
<javierm>
danvet: if that's the case I'll post this and the fixes for efifb and simplefb drivers
<karolherbst>
jenatali: I think they do have tests checking alignment on multiple buffers though, and I am sure my impl fails those now :D
rasterman has quit [Quit: Gettin' stinky!]
<karolherbst>
at the time where I allocate the input buffer I already lost all information about types
<karolherbst>
but I think I can store the alignment somewhere
Namarrgon has joined #dri-devel
<karolherbst>
jekstrand: I am thinking about dropping the first local mem arg and insert a constant 0...
<karolherbst>
could be a fun optimization
<danvet>
javierm, yup
<javierm>
danvet: cool, thanks for the confirmation
<jekstrand>
karolherbst: Not sure what you mean
<danvet>
javierm, feel free to include r-b: me right away
<karolherbst>
uhm... actually I don't know if we can actually do that
<danvet>
javierm, uh actually no
<karolherbst>
API buffers have to come after internal and kernel buffers
<danvet>
javierm, using file_fb_info is wrong, we do not want to recheck here at all
<danvet>
otherwise file_fb_info will make this NULL after unregister_framebuffer, which is totally fine
<karolherbst>
jekstrand: nvm.. my idea was just the first local* arg could be a constant 0, but that only works if the shader itself has a shared-size of 0
<danvet>
so only the WARN_ON is needed really and should be enough
<karolherbst>
or well.. I could insert shared-size as the constant
<karolherbst>
so kernels with one local mem buffer don't have to load the offset we already know what it is at compile time
<danvet>
javierm, wait my brain isn't working
<karolherbst>
(and do pointer math)
<jenatali>
That's not a bad idea for optimizations
<jenatali>
We just eat the load of the offset for all of 'em
<karolherbst>
yeah
<karolherbst>
it's a small opt
<karolherbst>
one could even reorder if there are multiple and constant fold it for the one with the most ops on the offset
mszyprow_ has quit [Ping timeout: 480 seconds]
<javierm>
danvet: no, I think you are correct... hmm
<javierm>
was planning to boot the rpi4 anyways to test the simplefb and efifb patches
<airlied>
karolherbst: unbearbaly slow should be about right
<daniels>
karolherbst, jenatali: Panfrost for a while ignored the offset you passed in to EGLImage dmabuf import, which was great on planar YUV when your luma was luma and your chroma was also your luma
<jenatali>
Heh, that's a good one
<karolherbst>
airlied: sure.. but I compare non CL CPU with CL CPU
<javierm>
danvet: and on the FBINFO_MISC_FIRMWARE topic, you forgot about OF/DT... the "simple-framebuffer" pdev is registered by OF core and bound to simpledrm
<jenatali>
My "all offsets are 0" bug resulted in computed images that looked mostly correct except for random black spots, and since it was GPU workgroup shared memory causing the problem, it was basically impossible to debug
<javierm>
danvet: so you could have OF -> "simple-framebufer" -> simpledrm -> "real dev" -> "real fbdev driver" that wants to kick out simpledrm fb
<javierm>
danvet: happy to also ignore that case though if you think is not worth it...
<karolherbst>
jenatali: yeah....
<danvet>
javierm, maybe I only thought about it, but my idea was that in the remove_conflicting_fb loop we pull the "nuke sysfb device" case out from under the FBINFO_MISC_FIRMWARE check
<jekstrand>
danvet: Where are we at on the fence reworks from König?
<danvet>
jekstrand, dma_resv_usage you mean for rebasing dma-buf fence import/export?
<danvet>
that fully landed
<jekstrand>
danvet: Yup.
<danvet>
but make sure you use latest drm-tip or things will go boom, there were bugs
<jekstrand>
Sounds like I should go rebase patches.
<jekstrand>
Ok, will do.
<danvet>
+1
<jekstrand>
I need to go find the patches....
<danvet>
it should be a lot simpler with the new approach
<javierm>
danvet: yes, but what I meant is that "simple-framebuffer" pdev in DT nodes are not registered by sysfb
<danvet>
jekstrand, don't you love m-l development
<javierm>
danvet: so nuke sysfb wouldn't help in that case
<danvet>
javierm, uh
<danvet>
javierm, can't we teach sysfb to recognize these?
<danvet>
having drivers add a flag if they bind against sysfb device so that some other places knows which ones to nuke feels a bit silly
<danvet>
javierm, like glue that of/platform.c code up with sysfb.c?
<danvet>
I was kinda assuming that's already how it works, but I guess not
<jekstrand>
danvet: The best/worst part is that I don't have a branch anymore to rebase so I've got to try to get patches to apply. :cry:
<javierm>
danvet: that FBINFO_MISC_FIRMWARE flag is not really "this driver binds to a device registered by sysfb" but rather "this driver uses a firmware provided framebuffer, but I don't know how we got here"
<zmike>
anholt: I've fixed the zink flakes in ci
<danvet>
javierm, yeah and I'm kinda arguing for a bit more structure
<danvet>
but inflicting structure onto fbmem.c is a lot of work :-(
<javierm>
danvet: yes, I understand your point and agree but think that cleanup should be a follow-up
<danvet>
javierm, yeah totally agreed, I think for now we can just go with "wont care"
<javierm>
danvet: my point is that right now simpledrm fbdev is the only one of the firmware-provided fb that doesn't set FBINFO_MISC_FIRMWARE
<danvet>
if you use simpledrm and an fbdev driver you just get the pieces
<javierm>
danvet: that works for me too :)
devilhorns has quit []
<javierm>
danvet: let's ignore it for now then But probably we want all the platform code to have a central place where "simple-framebuffer" pdev is registered
<danvet>
javierm, yeah I think as a goal at least that sounds like a plan
<danvet>
maybe also check it with gregkh
<javierm>
danvet: Ok
angerctl has joined #dri-devel
* jekstrand
hates that drm-tip rebases. All the old commits get lost. :(
<bnieuwenhuizen>
jekstrand: I have rebased patches, sec
<bnieuwenhuizen>
at least rebased on top of the dma_resv_usage work as of patchwork
<jenatali>
Yep. Good enough. Worst case it over-aligns but that's fine
<karolherbst>
yeah...
soreau has quit [Read error: No route to host]
soreau has joined #dri-devel
<karolherbst>
airlied: I am actually wondering.. does llvmpipe cache shader variants?
<karolherbst>
because it sometimes feels like that llvmpipe does a lot of recompilations
mszyprow_ has joined #dri-devel
angerctl has joined #dri-devel
CATS has quit [Read error: Connection reset by peer]
CATS has joined #dri-devel
TMM has joined #dri-devel
<airlied>
karolherbst: yeah it should
<TMM>
hi all! I got myself an HP zbook with an Radeon pro W6600M in it and it appears that amdgpu doesn't like it very much. https://paste.centos.org/view/7ac88ec7 Is there someone here who would be willing to help me?
<airlied>
but lots of things around imgs and samplers cause recompiles
Namarrgon has quit [Ping timeout: 480 seconds]
<karolherbst>
airlied: what about variable local sizes?
<karolherbst>
but okay.. if stuff around img and samplers can cause recompiles then that's a bit annoying :(
<TMM>
If I disable 'hybrid graphics' it does work
<TMM>
Perhaps it doesn't like the mux chip HP chose?
<TMM>
It *seems* that what is happening based on the logs I see that amdgpu tries to read some kind of configuration from the GPU's vram but the card is perhaps powered off?
<jekstrand>
danvet: drm-tip doesn't load i915 :-/
<daniels>
alyssa: that isn't generic scanout uAPI
<daniels>
alyssa: it's scanout uAPI that works if you know that your GPUs will only ever be integrated with two display controllers which can be satisfied by those constraints :P
<jekstrand>
uh, what?!? I used a Fedora config and it didn't build i915?
<daniels>
jekstrand: make modules
<alyssa>
daniels: ah..
<daniels>
alyssa: I can assure you I'd be doing more interesting things if it was :)
<alyssa>
I admit I don't know what assumptions that makes
<alyssa>
it seems to work for rockchip, at least
<jekstrand>
daniels: i915 was turned off in the config. For whatever reason, when I pulled the Fedora config and did "make menuconfig" it ended up off.
<jekstrand>
Maybe someone renamed an option?
<jekstrand>
/o\
deathmist1 has quit [Remote host closed the connection]
deathmist1 has joined #dri-devel
<daniels>
alyssa: as a lowest common denominator it's not the worst; as a universal axiom it really fails
<alyssa>
hm, ok
<daniels>
what's the problem you're facing that this would solve?
<daniels>
currently we get away with assuming that the display controller is the most constricted, so kmsro allocating from there and importing to GPU is very likely to succeed
<daniels>
but there are definitely cases where you want something more co-operative
<alyssa>
so for... some... reason
<alyssa>
the "GPU render ---AFBC---> display controller" path works by allocating a... dumb buffer of all things
<alyssa>
(a dumb buffer on the display controller, imported to the GPU)
<airlied>
jekstrand: make localmodconfig
<alyssa>
but the dumb buffer path wants a format/width/height
<alyssa>
so for AFBC, currently we make one up.
<alyssa>
in particular, AFBC is "like" the regular image with an extra row
<alyssa>
so panfrost allocates a dumb buffer of the regular image size (rounded up) plus a number of extra rows for the header blocks
<karolherbst>
geekbench5 still crashes :(
<alyssa>
that... whole dance is batshit
Duke`` has quit [Ping timeout: 480 seconds]
<alyssa>
if we're going to be making up dimensions anyway, we might as well do it more consistently like v3d does
<karolherbst>
jekstrand: okay.. back to that iris intel context crash.. is it plausible that a timeout would cause that if that happens like under a second?
<alyssa>
At least the v3d way means the "gpu driver creates resource on the scanout device and imports it to the gpu" routine doesn't need to special case AFBC, it just decides a layout for the resource (using the common layout code which is extensively tested) with the same code as "allocate an internal resource on the gpu" and only differs in where it gets the BO from
<karolherbst>
although it seems like that something about preemption doesn't really work regardless :(
Namarrgon has joined #dri-devel
<jekstrand>
karolherbst: The timeout is something like 0.5s for a single compute job and then 5s for a batch.
sdutt has quit []
sdutt has joined #dri-devel
<karolherbst>
jekstrand: oh wow.. that's not much
<karolherbst>
is that something userspace can configure?
<alyssa>
I don't actually care about fighting the WSI battle. I just want to get rid of the AFBC special case so I can extend AFBC support in the common panfrost surface layout code (shared with panvk, unit tested, written for correctness rather than happening to work)
<alyssa>
and not have to add even more special cases to the GL WSI path
<karolherbst>
but I did notice that with intels runtime my desktop doesn't get laggy, so maybe they either split up the work or... set some magic bit? dunno
<jekstrand>
karolherbst: Nope
<karolherbst>
huh...
orbea has quit [Read error: Connection reset by peer]
<jekstrand>
bnieuwenhuizen: I just don't like it as much because it's potentially a lot of ioctls to merge all those sync_files if they use multiple wait semaphores. :-/
<jekstrand>
I should rebase that one too
<bnieuwenhuizen>
jekstrand: ah, for my patches I just take the fence after the dummy submit and use that as a single sync_file
<jekstrand>
bnieuwenhuizen: Oh. Well, that works. :)
<jekstrand>
bnieuwenhuizen: Yeah, if you could rebase that and throw it on top of the MR, that'd be great.
<jekstrand>
I'll pull and test on ANV
<jekstrand>
Not sure why I didn't think of that...
<bnieuwenhuizen>
at this point in radv the dummy submit is just a merger based on timeline points on a per queue timeline semaphore anyway
<jekstrand>
yeah
<karolherbst>
is there a good way to figure out what intel is doing?
<jekstrand>
ANV actually does an exec ioctl but it's trivial.
<jekstrand>
karolherbst: What the Intel CL driver is doing?
<karolherbst>
yeah
<jekstrand>
karolherbst: They probably have mid-object preemption enabled which gets them 5s, not 0.5s.
<jekstrand>
If I had to take a blind guess
<karolherbst>
mhhh
<karolherbst>
I don't think so, but let me try something
<karolherbst>
ahh.. maybe that's indeed it
<karolherbst>
got a "[6734410.537203] Fence expiration time out i915-0000:00:02.0:cl-mem[3129763]:4!" now
<karolherbst>
still feels like they do something else
<karolherbst>
"256 GB in 10422.9 ms (24.6 GB/s)"
<karolherbst>
512 reps == 512GB makes it timeout
<karolherbst>
anyway.. is there an easy way for iris to turn that on?
rasterman has joined #dri-devel
mvlad has quit [Remote host closed the connection]
<agd5f>
karolherbst, for long running compute work, it might be better to use the KFD user queues. Those can be context switched.
<karolherbst>
agd5f: but that's amdgpu domain, isn't it?
<agd5f>
karolherbst, you'd just need a new winsys for KFD
<karolherbst>
I am confused... how would that help on iris? or is KFD some opaque term which would apply to i915 as well? I mean I know that people try to figure out how to do compute properly, but afaik it's all atm amdgpu only, no?
aswar002 has joined #dri-devel
<agd5f>
karolherbst, sorry, was mixing up contexts. hadn't read enough of the backlog
kts has quit [Quit: Konversation terminated!]
Haaninjo has quit [Quit: Ex-Chat]
<danvet>
airlied, I replied already
<danvet>
airlied, jekstrand I'm not really clear on what he's trying to solve, and I think the one thing that's clear with adding umf is that all approaches suck one way or the other
<danvet>
if it's just to make amd stack work with some new hw then I still don't get why we can't just add dma_fence with the old semantics on top of userspace memory fences
<danvet>
and if the goal is to actually roll out umf for real, then use drm_syncobj since that has the right semantics already
<danvet>
which means winsys/compositor work and everything instead of being really clever with shoehorning something into what we have that doesn't fit
deathmist1 has quit [Read error: Connection reset by peer]
deathmist1 has joined #dri-devel
mszyprow_ has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.4]
mszyprow_ has joined #dri-devel
* jekstrand
should blog about the new ioctls....
<HdkR>
Wait, new ioctls?
<HdkR>
jekstrand: Tell me more
<karolherbst>
mhhh
<jekstrand>
HdkR: "dma-buf: Add an API for exporting sync files (v13)" on dri-devel
<jekstrand>
Weirdly, it's not showing up in patchwork or the ML archives
<karolherbst>
somehow those darktable benchmarks are weird
<karolherbst>
1200% CPU, but using iris CL...
<karolherbst>
either I do a crappy job or something weird is happening
<karolherbst>
heh.. same with intels stack
<HdkR>
Hm, didn't show up in my email either
pcercuei has quit [Quit: dodo]
<HdkR>
But I see the DMA_BUF_IOCTL_EXPORT_SYNC_FILE_WSI
<jekstrand>
That's the ioctl
<jekstrand>
Maybe the cover letter didn't go through? I accedentally prefixed it with "*" which may have screwed things up. :joy:
<HdkR>
Fantastic struct packing. No need for me to add a new dma-buf handler :D
<jekstrand>
?
<bnieuwenhuizen>
jekstrand: I only have your cover letter
<jekstrand>
bnieuwenhuizen: :cry:
<HdkR>
jekstrand: Anything that touches ioctls I always need to check if the struct packing is hecked up between 32bit and 64bit
<jekstrand>
HdkR: Right. Yeah, I know better. :)
mszyprow_ has quit [Ping timeout: 480 seconds]
<HdkR>
Even the best people mess it up sometimes. I still need to implement an emulation path for aarch64 -> x86_64 because there is a struct that is messed up there :|
<danvet>
jekstrand, way too late but just scrolled through your patches
* jekstrand
re-sends
<danvet>
I think all the work from könig was worth it, looks so much neater
<jekstrand>
danvet: Yeah, it's massively simpler and obviously safe now.
<danvet>
(or I just misrember what the old stuff looked like)
<jekstrand>
The new patches are "drp... Yup. That's how that works."
<danvet>
jekstrand, yeah now it should be a joy to review instead of just "uh ... do I want to really think this through"
<jekstrand>
danvet: Review away then. :P
<karolherbst>
heh
icecream95 has joined #dri-devel
<karolherbst>
what's the point of this -d opencl thing if it ends up rendering on the CPU anyway
<danvet>
jekstrand, done
* danvet
^Z now for real
<karolherbst>
I am sure there is some nice blender stuff doing cl things, no?
<airlied>
cl got removed from blender
<jekstrand>
karolherbst: I think cycles still has a CL back-end but it's deprecated, last I knew. Worth trying if it's still there.
<karolherbst>
ohhh shit, right
<karolherbst>
"OpenCL support was removed in Blender 3.0." :(
<karolherbst>
"Instead there are HIP and Metal backends." ....
<karolherbst>
so you replace something useless by something even more useless
<jekstrand>
Yup
<jekstrand>
cuda, HIP, Metal. All the vendor lock-in APIs.
<karolherbst>
we should make blender devs wanting to revert that decision
<karolherbst>
that's my new life goal
<jekstrand>
Yup
<jekstrand>
That's one of my goals too!
<karolherbst>
nice
<karolherbst>
intel function callin when :P
* karolherbst
to busy fixing multithreading on nouveau obviously
<karolherbst>
but actually.. we should prototype it with llvmpipe
<karolherbst>
I guess that wouldn't be _too_ painful
<karolherbst>
I know Dave is busy atm so I won't ping him and ask how much work that would be
danvet has quit [Ping timeout: 480 seconds]
<karolherbst>
okay... soo.. how to fix that shit with llvm...
* karolherbst
thinks about requiring llvm-14 for rusticl
tursulin has quit [Ping timeout: 480 seconds]
morphis has quit [Ping timeout: 480 seconds]
morphis has joined #dri-devel
<karolherbst>
I want to use opencl-c-base.h so hard
<karolherbst>
printf caching disabled:
<karolherbst>
opencl-c.h: 2 minutes
<karolherbst>
opencl-c-base.h: 2 seconds
<jekstrand>
Yeah...
<karolherbst>
the only blocker is, that those vload/vstore_half APIs are missing
<karolherbst>
and we need llvm-14, but.. that's just how it is
<karolherbst>
but now that I have llvm and clang built locally...
<karolherbst>
I am sure those builtins are somwhere lost, because the fp16 ext isn't enabled or whatever reason there might be
<anholt>
alyssa: sorry, I have very little context for v3d any more. what's special about it?
<anholt>
it doesn't give your display a chance to align stride for linear, I guess.
<alyssa>
the width0=1024 bit, i think
CATS has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
<karolherbst>
okay.. fixing that half stuff invovles tablegen
<karolherbst>
I've heard it's a nice thing llvm uses
<daniels>
anholt: yeah, telling your display controller that the width is 1024 when the width is 1920 is ... not ideal
<anholt>
it's just the create_dumb. does anyone store anything during create_dumb? The only thing i know of anyone doing special there is aligning for linear.
<daniels>
I'm not saying that current kmsro is the absolute ideal, but this is not a forward step
<daniels>
anholt: it's create_dumb if your kmsro does create_dumb?
<anholt>
I'll say it more explicitly: I believe that the only side effect of lying about the width with all current kmsro display hosts is that you don't get stride alignment for linear. do you know of another problem?
<daniels>
the immediate thing that makes me twitch is the mainline KMS driver (might be OMAP now I think of it, but might not) that requires width aligned to 4096px (yes really) when you want the display controller to do rotation
<karolherbst>
aaaannnnndddd fixed
<daniels>
the long-term reflex that makes me think something better is possible is that it would be good to have an actual negotiation between GPU & display, rather than starting with kmsro's model of the display being the lowest common denominator so ignoring the GPU, then deciding that no wait actually the GPU is the lowest common denominator so let's ignore the display controller and lie to kmsro
<daniels>
like if we're deciding that we don't want to be constrained by the display anymore, then a large chunk of kmsro can just disappear and we don't even have to bump soversion
<anholt>
bump soversion?
<anholt>
huh?
<daniels>
I mean that kmsro is not ABI
<daniels>
so it seems weird to go out of our way to be lying to kmsro about dimensions, rather than just explicitly hobbling kmsro to be unaware of dimensions
<karolherbst>
I am sure it breaks tons of other stuff
<anholt>
I think that 3d driver doing layout makes a lot of sense for modifiers. If you've got a modifier, trust 3d, and ask your allocating device to allocate that many bytes. i think the flip side is if you have linear, we should probably have display allocate it since then it gets a chance to round up stride (dumb ioctl).
<anholt>
though, you've still got the vc4 exception where vc4 generally has to be the allocating device
<anholt>
so you can't just dumb allocate on display.
iive has quit []
<alyssa>
"3d driver doing layout makes a lot of sense"
<alyssa>
gotta say, I trust Panfrost's (now unit tested!) layout code far more than I trust every display driver under the sun that might be hooked up to Mali someday....
<jekstrand>
Oh, really? You don't say....
<alyssa>
jekstrand: Lol
<alyssa>
I should fix that Rockchip display driver bug I found, it's only the second one so far from the same test...
<alyssa>
It's admittedly pretty obscure
<alyssa>
Requires doing something so bizarre as using a modifiers-aware compositor with a 4K display
<daniels>
oh yeah, that should fail AddFB2
<daniels>
but KMS has no way to express 'you can do this modifier, but not w>2560' to userspace
<daniels>
anholt: ^ I'd like to say this is the reason I pushed back against that patch, but realistically it's just another corner case I forgot
<anholt>
daniels: you're thinking resource create should try an addfb and fail on failure of that?
<daniels>
anholt: that's not what I said
<daniels>
anholt: I'm saying that it suggests that Mesa's GPU allocation layer telling Mesa's display allocation layer that the width is always 1024, is not a great idea
<daniels>
and given that the GPU<->display allocation layer (kmsro) is not a stable ABI which cannot be changed, that changing it where necessary beats lying to it where unnecessary
<daniels>
especially where lying to it precludes making it actually function at all
<anholt>
I'm confused how the kernel's knowledge about w>2560 would get up to mesa allocation here.
<anholt>
I thought you were saying to addfb2 to test. or are you saying just have a little bit of display code in mesa that knows about tricks like that? (not opposed)
<daniels>
like I said, KMS has no way to express that RK3399's display controller can do KMS but only for sub-2560 width
<daniels>
so that's obviously a non-starter, and trying AddFB2 in resource_create is also quite silly