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
<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]
<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
<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]
<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