ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
mclasen has joined #dri-devel
<alyssa> I think you can but you'd need Khronos to manually approve the waiver
<alyssa> (For conformance, I mean. For just running tests, sure, no biggie. Except the board is so slowww)
<icecream95> Anyway, there is a tonne of bug reports and I don't have a G31 so can't fix them myself
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
bschiett has quit [Remote host closed the connection]
sdutt has quit [Ping timeout: 480 seconds]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
oneforall2 has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
tango_ has quit [Read error: Connection reset by peer]
tango_ has joined #dri-devel
sdutt has joined #dri-devel
sdutt_ has joined #dri-devel
frieder has joined #dri-devel
sdutt_ has quit [Remote host closed the connection]
sdutt_ has joined #dri-devel
sdutt_ has quit [Read error: Connection reset by peer]
sdutt_ has joined #dri-devel
ManMower has quit [Read error: Connection reset by peer]
ManMower has joined #dri-devel
ManMower has quit []
sdutt has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
sdutt_ has quit [Read error: Connection reset by peer]
sdutt has joined #dri-devel
ManMower has joined #dri-devel
rcf1 has quit []
sdutt has quit [Ping timeout: 480 seconds]
rcf has joined #dri-devel
mwk has quit [Ping timeout: 480 seconds]
ManMower has quit [Quit: leaving]
heat_ has quit [Ping timeout: 480 seconds]
pendingchaos_ has joined #dri-devel
sdutt has joined #dri-devel
pendingchaos has quit [Ping timeout: 480 seconds]
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
jernej_ has joined #dri-devel
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
toolchains has joined #dri-devel
tzimmermann_ has quit []
Duke`` has joined #dri-devel
OftenTimeConsuming is now known as Guest883
OftenTimeConsuming has joined #dri-devel
Guest883 has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
OftenTimeConsuming has quit [Ping timeout: 480 seconds]
OftenTimeConsuming has joined #dri-devel
plombo has quit [Ping timeout: 480 seconds]
jekstrand has quit [Remote host closed the connection]
jekstrand has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.5]
abws has quit [Read error: Connection reset by peer]
Duke`` has quit [Ping timeout: 480 seconds]
toolchains has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
mbrost has joined #dri-devel
toolchains has joined #dri-devel
srslypascal has quit [Ping timeout: 480 seconds]
jekstrand has quit [Ping timeout: 480 seconds]
toolchains has quit [Ping timeout: 480 seconds]
srslypascal has joined #dri-devel
jekstrand has joined #dri-devel
LexSfX has quit []
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
LexSfX has joined #dri-devel
tzimmermann has joined #dri-devel
danvet has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
maxzor_ has joined #dri-devel
maxzor has quit [Remote host closed the connection]
rasterman has joined #dri-devel
<danvet> bnieuwenhuizen, looking at your mail around stalls and disabling implicit sync and all that
<danvet> is that enough?
<danvet> i915 plan is to essentially do exactly that and make vm operations like any other free-wheeling engine (and userspace keeps all pieces when it unmaps stuff to early)
<danvet> and if there's any sync needed, userspace can pass drm_syncobj/fences back and forth to make sure everything is always pipelined
<danvet> bnieuwenhuizen, but from your mail I'm mildly worried there's still more stalling?
jkrzyszt has joined #dri-devel
<MrCooper> bnieuwenhuizen: BTW, you forgot to Cc amd-gfx on that series
maxzor_ has quit [Remote host closed the connection]
maxzor_ has joined #dri-devel
LexSfX has quit []
LexSfX has joined #dri-devel
<bnieuwenhuizen> danvet: the amdgpu VM operation ioctl doesn't take in/out fences yet
<danvet> bnieuwenhuizen, so once you have that and implicit sync is fully opt-out everywhere (both vm ops and cs) then we should be good as far as you can see?
<bnieuwenhuizen> So my question in the cover letter is kinda whether we should add in fences, though my concern is head of line be blocking if we do that
<bnieuwenhuizen> Christian had a series for adding the out fence
mvlad has joined #dri-devel
pcercuei has joined #dri-devel
<bnieuwenhuizen> sigh, everytime I do something interesting in kernel land the conversation always starts witha NAK :|
bmodem has joined #dri-devel
<danvet> bnieuwenhuizen, I've been trying to explain to könig that him rolling in with a NAK first and explanations later really isn't great communication style
<danvet> but it doesn't stick :-(
<danvet> "not great communication style" meaning here with the most Swiss understatement and politeness possible
ybogdano has quit [Read error: Connection reset by peer]
<MrCooper> "Ich kriege ein Brötchen" (Germany) vs "Ich hätte gerne ein Brötchen" (Switzerland) :)
<danvet> yeah it's a bit of that and sometimes lost in translation on top
toolchains has joined #dri-devel
* danvet typed some reply
mwk has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
frieder has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
frieder has joined #dri-devel
<pq> emersion, re: DSC; thanks!
<emersion> :P
<pq> thinking of scientific uses, I guess "visually lossless" = "lossy" compression.
<emersion> yeah, that's quite an interesting marketing wording
<emersion> can't wait to order a "mostly vegan hamburger" at the restaurant
toolchains has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
mclasen has joined #dri-devel
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
pjakobsson has quit [Quit: ZNC 1.7.5 - https://znc.in]
<MrCooper> the point of DSC is to allow modes which would normally require more bandwidth than is physically available; don't think lossless is possible in that case
<HdkR> Might as well as call 4:2:0 visually lossless :P
<MrCooper> e.g. the Samsung Odyssey G9's native 5120x1440 works at 240 Hz only with DSC
<HdkR> My 4k144hz display also only works at that setting with DSC
<pq> MrCooper, yeah. Makes me wonder what kind of static image is the worst for the codec. :-)
<pq> Xorg weave? :-p
Anorelsan has joined #dri-devel
<MrCooper> probably a good start :)
<HdkR> Theoretically the spec is open and royalty free, could take a look at how the encoder works and generate a worst case.
<emersion> i've been wondering about this as well :P
pjakobsson has joined #dri-devel
<airlied> wow 250,000 subjective tests is how they dceide visual losslessness
lumag_ has joined #dri-devel
<pq> and what will be quality loss look like
<MrCooper> I think people have hit pathological cases even with real world games
leah has quit [Ping timeout: 480 seconds]
maxzor_ has quit [Remote host closed the connection]
maxzor_ has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
whald has joined #dri-devel
<glennk> must be the same test subjects that decided pentile was visually lossless :-p
pendingchaos_ is now known as pendingchaos
maxzor_ has quit [Remote host closed the connection]
maxzor_ has joined #dri-devel
lygstate has joined #dri-devel
devilhorns has joined #dri-devel
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
rkanwal has quit [Ping timeout: 480 seconds]
devilhorns has quit [Remote host closed the connection]
devilhorns has joined #dri-devel
icecream95 has quit [Ping timeout: 480 seconds]
saurabhg has joined #dri-devel
<daniels> can't wait to see what 'visually lossless' DSC is like when the input is a 'visually lossless' framebuffer compression modifier
devilhorns has quit []
* ccr shudders
Anorelsan has quit [Quit: Leaving]
rkanwal has joined #dri-devel
devilhorns has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
saurabhg has quit [Ping timeout: 480 seconds]
ana has joined #dri-devel
bmodem has joined #dri-devel
mclasen_ has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
toolchains has quit [Remote host closed the connection]
toolchains has joined #dri-devel
abws has joined #dri-devel
toolchai_ has joined #dri-devel
<alyssa> emersion: "tastes vegan", there's so little meat in it you wouldn't know it's tofu!
<alyssa> (Due to the current soybean shortage, ground beef not otherwise safe for human consumption is being used as filler for our tofu burgers.)
<alyssa> :p
<emersion> ahah
toolchains has quit [Ping timeout: 480 seconds]
<alyssa> ^not tofu
bmodem has joined #dri-devel
icecream95 has joined #dri-devel
Company has joined #dri-devel
<danvet> javierm, just noticed that your vesafb patch landed through the fbdev tree. was that coordinated like that or did we end up double merging?
sdutt has joined #dri-devel
<javierm> danvet: yes, Helge asked me if he could merge through fbdev because was preparing a PR for torvalds and wanted to include it
ahajda_ has joined #dri-devel
ahajda_ has quit []
ahajda has joined #dri-devel
<danvet> javierm, yeah just wanted to make sure we're not creating a mess since it's all about the lifetime around handover
pixelcluster has joined #dri-devel
<javierm> danvet: yeah, but I think is safe since the other patches already made it to v5.18
<javierm> danvet: it's unclear to me though when we should merge stuff and when he has, I guess this is a good example why doesn't really make that much sense to have separate trees for this...
<danvet> yeah :-/
<danvet> my cunning plan is to just wait until he's given up, like all fbdev maintainers beforehand
<javierm> hehe
toolchai_ has quit [Remote host closed the connection]
toolchains has joined #dri-devel
Peuc_ has quit [Ping timeout: 480 seconds]
toolchains has quit [Ping timeout: 480 seconds]
icecream95 has quit [Ping timeout: 480 seconds]
Peuc has joined #dri-devel
ella-0_ has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
maxzor has joined #dri-devel
Haaninjo has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
mclasen_ has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
bmodem has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
maxzor_ has quit [Remote host closed the connection]
maxzor_ has joined #dri-devel
sdutt has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
<alyssa> jekstrand: re regressing XFB + GL SPIRV on radeonsi, should we maybe revert just that last commit?
<alyssa> It's a nice clean up for sure, but it's not necessary for panfrost and unless someone plans to looking into the bug today, we shouldn't leave the tree broken
<MrCooper> what are the symptoms of this regression?
<jekstrand> alyssa: I'm going to look into it today
<jekstrand> alyssa: I can probably fix it.
<MrCooper> (wondering if it's the GPU hang regression I've been struggling to bisect :)
<alyssa> MrCooper: transform feedback with ARB_gl_spirv is broken on radeonsi since an MR merged last night
<alyssa> a few piglits (not run in pre-merge CI) are regressed
<alyssa> jekstrand: Ack :)
<MrCooper> but the piglits just fail, no GPU hangs?
<jekstrand> Currently trying to figure out how my renderpass MR broke RADV HIZ
<jekstrand> But maybe I should switch gears since that's a regression
<pepp> MrCooper: yes, they just fail
whald has quit [Read error: Connection reset by peer]
toolchains has joined #dri-devel
maxzor_ has quit [Remote host closed the connection]
maxzor_ has joined #dri-devel
<MrCooper> pepp: k, thanks, probably a separate regression then
rkanwal has quit [Read error: Connection reset by peer]
rkanwal has joined #dri-devel
sravn__ is now known as sravn
<sravn> danvet "my cunning plan ...fbdev ..." - or remove the dependencies to fbdev so we do not care
toolchains has quit [Ping timeout: 480 seconds]
maxzor has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
JohnnyonFlame has joined #dri-devel
rkanwal has quit [Read error: Connection reset by peer]
rkanwal has joined #dri-devel
maxzor_ has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Ping timeout: 480 seconds]
toolchains has quit [Ping timeout: 480 seconds]
<idr> pepp: I will test that today.
<pepp> thanks
alyssa has left #dri-devel [#dri-devel]
toolchains has joined #dri-devel
saurabhg has joined #dri-devel
mahkoh has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
toolchains has quit [Ping timeout: 480 seconds]
plombo has joined #dri-devel
heat_ has joined #dri-devel
<mahkoh> Hi. I'm using libgbm to allocate buffers to display on a cursor plane. I tried using GBM_BO_USE_RENDERING|GBM_BO_USE_CURSOR but allocations fails. Then I tried GBM_BO_USE_RENDERING|GBM_BO_USE_SCANOUT but the AMDGPU driver does not accept these buffers cursor planes. Looking at the mesa source code, I found that PIPE_BIND_CURSOR implies linear layout in radeonsi and indeed
<mahkoh> GBM_BO_USE_RENDERING|GBM_BO_USE_SCANOUT|GBM_BO_USE_LINEAR creates working buffers. Is this the correct way to allocate buffers for cursor planes?
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
<emersion> GBM_BO_USE_SCANOUT|GBM_BO_USE_LINEAR is what you need yes
Duke`` has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
<mahkoh> Thanks, that's what I was looking for.
gouchi has joined #dri-devel
plombo has quit [Ping timeout: 480 seconds]
adjtm has joined #dri-devel
adjtm has quit []
tzimmermann has quit [Quit: Leaving]
rasterman has joined #dri-devel
mbrost has joined #dri-devel
raster-- has joined #dri-devel
rasterman has quit [Ping timeout: 480 seconds]
<MrCooper> GBM_BO_USE_CURSOR was really intended for this though? In which case that not working sounds like a bug
abws has quit [Quit: abws]
raster-- has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
<MrCooper> conceptually GBM_BO_USE_SCANOUT|GBM_BO_USE_LINEAR might not be guaranteed to work for cursors
tjmercier has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
raster-- has joined #dri-devel
rasterman has joined #dri-devel
raster-- has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
rasterman has quit [Ping timeout: 480 seconds]
<emersion> GBM_BO_USE_CURSOR is a bit weird iirc
<emersion> it uses a drm dumb buffer
<emersion> GBM_BO_USE_SCANOUT|GBM_BO_USE_LINEAR is what wlroots does, and i never got a bug report about it not working
<emersion> ah no, USE_CURSOR doesn't do dumb buffers, GBM_BO_USE_WRITE does?
<emersion> anyways, it doesn't matter too much
toolchains has quit [Ping timeout: 480 seconds]
<emersion> USE_CURSOR is bad because it leaks even more KMS knowledge into the user-space driver
<daniels> iirc its main differentiator was overallocating for hardware which can only do fixed cursor sizes, but we have a cap for that
<daniels> also pread/pwrite, but, no
rasterman has joined #dri-devel
<danvet> daniels, emersion yeah so on i915 (and I'm not sure on how many other drivers) uploading cursor data is special
<danvet> hence that thing
<danvet> emersion, so maybe fire up on a gen2/3 and appreciate how your cursor doesn't work :-/
<danvet> ah no it should work
<danvet> tbh I'm not sure whether there's any drivers left where dumb bo wont work for cursor (assuming it's the right size)
* danvet looked at the wrong i915 mmap
rasterman has quit [Ping timeout: 480 seconds]
rkanwal has quit [Ping timeout: 480 seconds]
devilhorns has quit []
rasterman has joined #dri-devel
<ccr> I wonder why I read that as "wrong i915 meme" .. hmm.
toolchains has joined #dri-devel
<zmike> ccr: are you planning to get those trace patches into a MR?
rasterman has quit [Ping timeout: 480 seconds]
<ccr> zmike, I could, if you wish so. admittably I made the assumption that it might be waste of time as you mentioned that the current approach might be wrong (re: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4609#note_1241125 )
<ccr> but it's no trouble for me if you think they are MR-worthy
<ccr> :)
iive has joined #dri-devel
<zmike> ccr: I think that's ultimately unrelated though
<zmike> I use your new trace script regularly to give me a quick overview
<zmike> it's really nice for that
<ccr> okay, I overinterpreted what you said there. I'll see about that MR then soon-ish.
<zmike> cool
<Lyude> seanpaul__: any chance you're around? Wondering if you might be able to answer some questions about drm_dp_send_query_stream_enc_status()?
<Lyude> seanpaul__: my main question is just where the driver is typically expected to call this (since it seems to not be hooked up anywhere), so I know whether or not we should be expecting to hold MST modesetting locks already when this is called or not
<Lyude> *when this is called
rsalvaterra_ has joined #dri-devel
rsalvaterra is now known as Guest923
rsalvaterra_ is now known as rsalvaterra
Guest924 has quit [Ping timeout: 480 seconds]
sdutt has quit [Ping timeout: 480 seconds]
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
<anarsoul> looks like I didn't debug nir in a long time. Was NIR_PRINT replaced by something else?
<airlied> NIR_DEBUG=print ?
* airlied forgets
<jenatali> Yeah
<anarsoul> airlied: thanks!
<jenatali> Or NIR_DEBUG=print_vs or print_fs IIRC
<jenatali> (or the other shader kinds too)
heat_ has quit [Remote host closed the connection]
heat has joined #dri-devel
linkmauve has left #dri-devel [Error from remote client]
kts has joined #dri-devel
mahkoh has quit [Quit: WeeChat 3.5]
sdutt has joined #dri-devel
<cwabbott> looks like the build deps for vk_cmd_queue are busted
toolchains has quit [Ping timeout: 480 seconds]
<cwabbott> oh wait, no... vk_cmd_queue.h got moved to $BUILDDIR/src/vulkan/runtime from $BUILDDIR/src/vulkan/util but the old copy never got deleted
<cwabbott> truely cursed
<zmike> oof yeah I've hit that $infinity times by now
rasterman has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
mclasen has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
toolchains has joined #dri-devel
eukara has quit [Remote host closed the connection]
toolchains has quit [Ping timeout: 480 seconds]
maxzor has joined #dri-devel
<dcbaker> austriancoder: Do you want me to pull https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16383 into the 22.1 branch?
<dcbaker> zmike: I've got both "9bb9511edc zink: remove first_frame stalling" and "1c019ee1ba st/pbo_compute: fix z coords for compute pbos" from you, which need several non-trivial previous patches to apply to the 22.1 branch, enough that I gave up on trying to sort them out, what would you like to do about those?
<zmike> hm
<zmike> yeah I can look in a few
<zmike> dcbaker: feel free to ping me on backports if they don't apply in one go, I can get it sorted out so you can move on
<zmike> (for mine anyway)
<dcbaker> th pbo_compute needs "make easier to read" patch to apply cleanly, but it still doesn't compile cleanly
<zmike> I'll wrangle it
<dcbaker> thanks
Haaninjo has quit [Quit: Ex-Chat]
Duke`` has quit [Ping timeout: 480 seconds]
gouchi has quit [Quit: Quitte]
mvlad has quit [Quit: Leaving]
eukara has joined #dri-devel
jani has quit [Remote host closed the connection]
jani has joined #dri-devel
jani is now known as Guest941
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
plombo has joined #dri-devel
<zmike> dcbaker: am I clear to push?
<dcbaker> you are now, though you'll have to rebase
<zmike> hm just fetched and nothing new so I think I'm good
<zmike> pushed
<zmike> had to pick in a couple trivial nir patches
LexSfX has quit [Ping timeout: 480 seconds]
<zmike> really annoying that the same patches that introduce trivial nir helpers also modify 50000 other files to replace existing usage instead of doing those in a separate patch
<jekstrand> sorry
LexSfX has joined #dri-devel
plombo has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
dsrt^ has joined #dri-devel
plombo has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
<dcbaker> zmike: thanks again!
<zmike> dcbaker: thanks for the release!
<dcbaker> of course
<dcbaker> now for 22.0…
linkmauve has joined #dri-devel
dsrt^ has quit [Ping timeout: 480 seconds]
dsrt^ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
lygstate has quit [Remote host closed the connection]
danvet has quit [Ping timeout: 480 seconds]
pixelcluster has quit []
maxzor has quit [Ping timeout: 480 seconds]
plombo has quit [Remote host closed the connection]
ybogdano is now known as Guest953
Guest953 has quit [Read error: Connection reset by peer]
ybogdano has joined #dri-devel
icecream95 has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.5]
pcercuei has quit [Quit: dodo]
toolchains has joined #dri-devel
mbrost has joined #dri-devel
lumag_ has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
<gawin> bonjour, can I force apitrace to print file names in stacktrace when getting "error: caught an unhandled excepton"?
crabbedhaloablut has quit [Read error: Connection reset by peer]
<gawin> (built both mesa and apitrace from source)
crabbedhaloablut has joined #dri-devel
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
dsrt^ has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
iive has quit []
q66 has quit []
heat has quit [Remote host closed the connection]
rsripada_ has joined #dri-devel
aswar002_ has joined #dri-devel
Ryback_[WORK] has joined #dri-devel
jhli_ has joined #dri-devel
ybogdano is now known as Guest957
sdutt_ has joined #dri-devel
ybogdano has joined #dri-devel
unerlige3 has joined #dri-devel
mdnavare_ has joined #dri-devel
dolphin` has joined #dri-devel
dolphin is now known as Guest958
dolphin` is now known as dolphin