ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Zopolis4_ has quit []
<Lynne>
I don't think debugPrintfEXT works fine, it's reporting all push data is uninitialized (yet it's working)
errrfpwold^ has joined #dri-devel
errrfpwold^ has quit [Remote host closed the connection]
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
<Lynne>
yup, debugprintfext is broken, writing the data to a buffer says my push data is fine
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
errrrrfpwciv^ has joined #dri-devel
Company has quit [Quit: Leaving]
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
krushia has quit [Ping timeout: 480 seconds]
kode549 has left #dri-devel [#dri-devel]
kode54 has joined #dri-devel
<kode54>
that +M annoyed me once again
Zopolis4_ has joined #dri-devel
i-garrison has quit [Ping timeout: 480 seconds]
errrrrfpwciv^ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
aravind has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
JohnnyonF has quit [Remote host closed the connection]
JohnnyonFlame has joined #dri-devel
bmodem has joined #dri-devel
bmodem has quit []
bmodem has joined #dri-devel
mbrost has joined #dri-devel
bmodem has quit []
bmodem1 has joined #dri-devel
krushia has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
bmodem1 has quit []
bmodem has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
mbrost_ has joined #dri-devel
tzimmermann_ has quit []
tzimmermann has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<Lynne>
the more I look at it, the more it looks like a radv issue...
lemonzest has joined #dri-devel
djbw_ has quit [Read error: Connection reset by peer]
bgs has joined #dri-devel
itoral has joined #dri-devel
fab has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
mbrost_ has quit []
danvet has joined #dri-devel
mbrost has joined #dri-devel
sgruszka has joined #dri-devel
agneli_ has joined #dri-devel
<Lynne>
seems like I fixed it, not sure which of the millionth refactorings did it
bmodem1 has joined #dri-devel
Zopolis4_ has quit []
godvino has joined #dri-devel
errrrrrrrrrrrrrrfpwcic^ has joined #dri-devel
agneli has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
rasterman has joined #dri-devel
alanc has joined #dri-devel
i-garrison has joined #dri-devel
fab has quit [Quit: fab]
godvino1 has joined #dri-devel
godvino has quit [Ping timeout: 480 seconds]
yuq825 has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
godvino has joined #dri-devel
godvino1 has quit [Read error: Connection reset by peer]
mbrost has quit [Read error: Connection reset by peer]
tursulin has joined #dri-devel
pjakobsson_ is now known as pjakobsson
godvino1 has joined #dri-devel
godvino has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
bmodem has joined #dri-devel
bmodem1 has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
<MrCooper>
kode54: FWIW, if you identify with NickServ, it changes your nick to the identified one, even if you're on +M channels
jkrzyszt has joined #dri-devel
errrrrrrrrrrrrrrfpwcic^ has quit [Remote host closed the connection]
lynxeye has joined #dri-devel
elongbug_ has joined #dri-devel
elongbug_ has quit []
<danvet>
javierm, tzimmermann I just learned about dev_err_probe ... is this something we should roll out to helpers like component.c or maybe the various probe helpers for bridge/panel?
<danvet>
pinchartl, ^^
<danvet>
it sounds pretty cool
<danvet>
also automatically ties into device_set_deferred_probe_reason() infra
elongbug_ has joined #dri-devel
<pinchartl>
danvet: it's a very nice helper, I like it
<danvet>
it's very neat indeed
<danvet>
just wondering whether we should do a gpu/todo.rst entry
<danvet>
it seems to be one of the really good things which is just a notch to hard for cocci
<pinchartl>
the only issue I can think of when using it in helper is that you make sure those helpers will only be called from a probe path
vliaskov has joined #dri-devel
<pinchartl>
and I'm not sure what would happen if the driver then called dev_err_probe() a second time in the error path
<pinchartl>
this needs to be checked
<danvet>
uh, maybe not quite so awesome, because device_set_deferred_probe_reason doesn't stack :-(
<danvet>
pinchartl, yeah I just checked, it doesn't do the right thing
<danvet>
so you cant just splatter this all over in common code
<danvet>
but also shouldn't be too hard to make it a stack that resets on every probe attempt
<danvet>
hm what was andrzej hajda's nick again
godvino has joined #dri-devel
elongbug has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest10031
srslypascal has joined #dri-devel
sarahwalker has joined #dri-devel
<javierm>
danvet: I believe that doesn't stack because otherwise printing the deferral reason in /sys/kernel/debug/devices_deferred would be tricky
<javierm>
or do you mean to print the first element (i.e: original deferred reason)?
<danvet>
javierm, well just make it a logfile really
<danvet>
like on every probe reset it to nothing, then record them all
<danvet>
so you could do something like the shared panel lookup code could print something, then the driver, then maybe even component.c
<kode54>
19:21 -NickServ- You are connected using SSL and have provided a matching client certificate
<danvet>
and you'd get the entire stack of how the probe_defer cascaded through
<kode54>
it doesn't make this association until I take the main nick
<danvet>
and don't have to make sure that there's only ever one to avoid accidentally overwriting the improtant one
<danvet>
like if it doesn't stack we can't add something to component.c
elongbug_ has quit []
<kode54>
and the substitute nick is random
<danvet>
because it might overwrite the one that matters
elongbug has joined #dri-devel
godvino1 has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: Lost terminal]
Guest10031 has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
<javierm>
danvet: right
<MrCooper>
kode54: "/msg NickServ identify <password> kode54" and it will change your nick to kode54
<javierm>
danvet, pinchartl: what we can do is to make deferred_probe_reason a list and then print something like: 'rockchip-drm 13970000.hdmi: can't find GPIO for bridge -> couldn't look up bridge'
<javierm>
or something like that
<danvet>
robclark, tzimmermann should we volunteer Dmitry Baryshkov for drm-misc commit rights? it's mostly msm stuff but I guess would help with pushing the non-msm patches
<danvet>
robher, ^^ (I have no idea who's still at linaro doing gpu stuff)
<tzimmermann>
danvet, no objections from my side.
<javierm>
danvet, pinchartl: then device_set_deferred_probe_reason() could add another node to the list of probe deferral reasons
<kode54>
MrCooper: that requires me to switch to my password keeper to retrieve my password
<kode54>
client doesn't have it stored because it's in certfp auth mode
<kode54>
either way, something I have to do manually any time it happens
<emersion>
you can thank OFTC for having a server from prehistory
fab has quit [Quit: fab]
fab_ has joined #dri-devel
fab_ is now known as Guest10036
dtmrzgl has quit []
guru_ has joined #dri-devel
heat has joined #dri-devel
heat has quit [Remote host closed the connection]
oneforall2 has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
dtmrzgl has joined #dri-devel
<mareko>
does NIR have a utility returning whether an SSA def post-dominates another SSA def?
pendingchaos has quit [Read error: Connection reset by peer]
i509vcb has quit [Quit: Connection closed for inactivity]
itoral has quit [Remote host closed the connection]
oneforall2 has quit [Quit: Leaving]
godvino1 has joined #dri-devel
oneforall2 has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
godvino has quit [Ping timeout: 480 seconds]
thellstrom has joined #dri-devel
godvino1 has quit [Read error: Connection reset by peer]
<javierm>
tzimmermann: I've a very hard time trying to read Sui Jingfeng's email do how they format the text...
<javierm>
*due
<danvet>
something breaks lines and inserts an empty newline after that
<danvet>
it does read a bit like a peom
<javierm>
danvet: yeah, and also there are some underscore characters dropped randomly it seems
<dottedmag>
danvet: javierm: One of their e-mail passed through GPT-4 with prompt "improve formatting, do not change text": http://paste.debian.net/1276381/
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<danvet>
lol
devilhorns has quit []
<javierm>
dottedmag :D
<javierm>
dottedmag: need to add an emacs script that does this :P
<lina>
I have no idea whether that makes sense though, would appreciate comments ^^
<DavidHeidelberg[m]>
eric_engestrom: it almost passed :D haha, never mind, thanks for resolving the flake
<daniels>
lina: tl;dr everything just works if the driver just does what it's told to and doesn't try to be too clever
<eric_engestrom>
DavidHeidelberg[m]: yeah, sorry about forgetting to `--stress`-test the move to arm64 runners :/
<DavidHeidelberg[m]>
haha, I need to finish that "reminder MR template"
<eric_engestrom>
:P
<lina>
daniels: How does the modifier stuff work with SCANOUT then? Right now when we get SCANOUT we force linear and create a dumb scanout resource at the display controller then import it, but if there is high-level negotiation of modifiers that doesn't make much sense...
<robher>
danvet: neither do I not being at Linaro. :)
<lina>
I really need to figure out how to not get highlights on "linaro"... ^^;;
<robher>
linaro, linaro, linaro
* lina
might have fixed it ^^;;
<jannau>
linaro, linaro, linaro
<lina>
Yay! ^^
<daniels>
lina: does DCP require allocations to be done from a dedicated area, or can it (provided it's linear) import dmabufs allocated by another device?
<jannau>
it should be able to import and has its own iommu
<lina>
It should be able to import them, and it can also handle compression though we haven't worked that out yet (nor whether it's the same exact compression we already support in AGX or something special)
<daniels>
aight, so in that case don't overthink it. if EGL tells you to allocate only linear, then allocate only linear. if EGL tells you that you can allocate compressed, then allocate compressed :)
<lina>
And do nothing special with the SCANOUT flag?
<daniels>
as long as your compositor supports zwp_linux_dmabuf_v1 v4 (terrible naming I know), and you expose your modifiers via the EGL queries as well as KMS IN_FORMATS, everything will just work
<lina>
How do the buffers end up mapped at DCP via kmsro then? On demand?
<daniels>
kmsro and clients are very different
<daniels>
clients won't (well, shouldn't ...) be using kmsro
<lina>
I think they are... somehow...
thellstrom has quit [Read error: Connection reset by peer]
<lina>
glxgears hits the dev->ro && (templ->bind & PIPE_BIND_SCANOUT) codepath
jfalempe has quit [Quit: Leaving]
<daniels>
heh ok, which compositor?
<lina>
kwin
<lina>
(on xwayland)
<lynxeye>
daniels: If the compositor provides the kms device node to the client, then the client will end up using kmsro
<lynxeye>
lina: even if the app isn't fullscreen the compositor might end up putting it on a plane, which might have different tiling, etc. capabilities than the renderer.
<lina>
Yeah...
<lynxeye>
the best way is really to rely on dmabuf-feedback for the modifiers and not do anything "clever" in your driver
thellstrom1 has joined #dri-devel
thellstrom has quit [Read error: Connection reset by peer]
<lina>
So it should work if we just switch to GPU->display imports and don't apply any restrictions on scanout?
<lina>
I think only vc4 does it like that now, all the other drivers seem to create buffers on the display side
<lynxeye>
lina: PIPE_BIND_SCANOUT doing something special on some kmsro drivers is really just to work around the issue that some display engines need allocations that can't be satisfied from the GPU side (e.g. contig memory)
<lynxeye>
lina: If your display engine is behind a iommu it should be able to deal with GPU buffer allcoations, so there is no need to allocate from the display side
<lynxeye>
lina: and especially don't force linear, just because it's a scanout allocation. Rely on the modifier to tell you which layout can be used.
pixelcluster_ has joined #dri-devel
<lina>
OK, I just tried doing it that way and the actual import works, but at least glmark2-es2-drm ends up with a compressed modifier DCP can't handle. I wonder if we're implementing that right on the DCP side...
<lina>
As far as I can tell the KMS driver is listing only LINEAR as a supported modifier.
<daniels>
lina: if you run wayland-info, which version of zwp_linux_dmabuf_v1 does kwin support? if it's not v4 then the protocol is missing
pixelcluster has quit [Ping timeout: 480 seconds]
<lina>
(This is glmark2 on raw kms so far, haven't tried kwin yet)
<lynxeye>
might be a compositor issue. Without dmabuf feedback you get all supported modifiers, which includes the one that only the renderer can handle. With dmabuf feedback the compositor should send a preferred tranche with only the linear modifier when it determines that the app could go onto a plane
<daniels>
oh right, in that case it's glmark2-es-drm's fault; it almost certainly doesn't parse the IN_FORMATS blob which it really should
<lina>
It looks like it doesn't specify any modifiers at all
<lina>
It probably makes sense to force linear for SCANOUT without any explicit modifiers?
godvino has joined #dri-devel
<lynxeye>
yea, at least that's what etnaviv does also.
aravind has quit [Ping timeout: 480 seconds]
thellstrom1 has quit [Ping timeout: 480 seconds]
<lina>
OK, that works and fixes the glxgears issue, and kwin still works! ^^
<daniels>
++
<lina>
Now I think the last thing to do is make the scanout export lazy (only when the handle is created), because otherwise we still end up with the glxgears buffer mapped to the display controller for no reason.
paulk-bis has joined #dri-devel
paulk has quit [Read error: Connection reset by peer]
bmodem has joined #dri-devel
bmodem has quit []
bmodem has joined #dri-devel
bmodem1 has quit [Ping timeout: 480 seconds]
<lina>
OK, that fixed it for the buffer on the glxgears side... but now XWayland is asking for the KMS handle for the glxgears surface and that causes it to be mapped to the display controller.
<lina>
That has to be wrong, there's no reason for Xwayland to be trying to get KMS handles, is there?
<daniels>
lina: Xwayland certainly does some pretty cursed things with GBM, and I would strongly suspect that MR I linked above would be what's leading it to pick the wrong device
<lynxeye>
lina: There are a lot of legacy places in gallium that use a kms handle export to query properties of the resource. resource_get_param was introduced a lot later.
<daniels>
I do need to get around to trying to help figure out that EGLDevice MR at some point, but all of the device-handling code is absolutely cursed, and it was also right around when all the DRI refactoring was in progress, so I figured if I waited it out then things might improve ...
<lina>
^^
<lina>
OK, I'll punt on this one for now, hopefully it won't bite us too much
<daniels>
if linear truly bites hard, you could always do the shadow-resource thing where you present the app a tiled buffer, then do a linear blit at end of frame (signaled by pipe->flush(PIPE_FLUSH_END_OF_FRAME))
<lina>
It'll have to be some kind of heuristic, but then again maybe this is pointless once DCP supports compression anyway...
godvino1 has joined #dri-devel
bmodem has quit []
bmodem has joined #dri-devel
<daniels>
heh, yeah
<daniels>
lina: out of interest tho, if you run wayland-info against your version of kwin, what version does it say zwp_linux_dmabuf_v1 is, and if it's version 4, what does it say the main device is?
<zamundaaa[m]>
KWin atm does not use EGL_EXT_device_drm_render_node at all, it always sends the primary node of the primary GPU
godvino has quit [Ping timeout: 480 seconds]
bmodem has quit []
<daniels>
yeah, so I guess it'd have to start using that, and we'd have to fix mesa to make that ext work with kmsro :P
bmodem has joined #dri-devel
<lina>
That device is the display controller node, yeah
<lina>
Are the listed formats/modifiers supposed to only be the ones supported by it?
<zamundaaa[m]>
For the scanout tranche, yes. For the other tranches, no
<lina>
I see 3 tranches and none of them seem to have any flags, and all of them have formats not supported by DCP
<zamundaaa[m]>
KWin only passes along what egl returns from eglQueryDmaBufFormatsEXT + eglQueryDmaBufModifiersEXT
<daniels>
for the scanout tranche, it should be intersecting with IN_FORMATS
<zamundaaa[m]>
Are some formats maybe external_only? KWin filters those out
<lina>
Which is the scanout tranche, how do I tell?
<zamundaaa[m]>
It would be the one with flags: scanout
<lina>
None of them have that
<daniels>
wayland-info would probably never get sent scanout tranches as it doesn’t even create a window so could never be a candidate for direct scanout :P
pixelcluster_ has quit []
pixelcluster has joined #dri-devel
agneli_ has left #dri-devel [#dri-devel]
jdavies has joined #dri-devel
jdavies is now known as Guest10056
<zamundaaa[m]>
yeah
jewins has joined #dri-devel
Guest10056 has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
<Nefsen402>
For PRIME situations in wayland, will mesa always blit to the primary GPU before handing the dmabuf to the wayland compositor? I'm asking about amdgpu specifically
Haaninjo has joined #dri-devel
<robclark>
danvet: ack for lumag and r-b for patch
sgruszka has quit [Ping timeout: 480 seconds]
vyivel has quit [Remote host closed the connection]
<MrCooper>
lina: Xwayland explicitly uses render nodes, so even if it asks for a "KMS handle", that should just be the GEM handle of the render node and shouldn't require mapping to DCP
<daniels>
MrCooper: unless kwin has told it to open the DCP device ...
<MrCooper>
doesn't use that yet
bmodem has joined #dri-devel
<lina>
MrCooper: It's hitting the kmsro path so it's not using the render node...
<daniels>
MrCooper: wl_drm
<MrCooper>
hmm, xwl_drm_handle_device looks up the corresponding render node if it doesn't get passed one, but maybe that doesn't work in this case?
bmodem2 has joined #dri-devel
<MrCooper>
AFAICT Xwayland/glamor only calls gbm_bo_get_handle(_for_plane) if it was built against old Mesa though, so I do suspect this is a Mesa internal issue
<daniels>
right, due to that MR I linked above, right now if you have a system with disjoint display & render DRM devices, the clients will receive the 'wrong' device name, i.e. that of the KMS device you opened via GBM, rather than the GPU device that kmsro discovered
bmodem1 has quit [Ping timeout: 480 seconds]
yuq825 has quit []
<MrCooper>
right, I hadn't realized it's actually two separate DRM devices
<MrCooper>
(maybe better not to assume everybody is aware of this ;)
bmodem has quit [Ping timeout: 480 seconds]
<daniels>
my bad!
<MrCooper>
no worries, in hindsight "kmsro" was a giveaway
godvino2 has quit [Ping timeout: 480 seconds]
jewins has quit [Ping timeout: 480 seconds]
dviola has joined #dri-devel
<alyssa>
lina: We should be able to avoid splitting render passes to scanout as long as we get all the synchronization stuff right, hopefully
<alyssa>
and then it's just an issue of partial renders. If we really care about optimizing that we can potentially use a compressed surface for the partial renders and linear for the final scanout and save a blit
<alyssa>
(only works if there's a glClear at the start of the frame)
<lina>
Wouldn't a game rendering directly to scanout possibly end up doing multiple passes?
godvino has joined #dri-devel
<alyssa>
hopefully not if we don't do anything sill
<alyssa>
silly
<alyssa>
we still do lots of silly things
<alyssa>
like writing gallium drivers instead of zink
<alyssa>
zmike: im learning slowly.
bmodem has joined #dri-devel
bmodem1 has joined #dri-devel
<zmike>
don't hurt yourself
bmodem2 has quit [Ping timeout: 480 seconds]
* alyssa
screams
<FLHerne>
any recommendations for a random Mesa thing to look at while it's raining outside? :p
fab has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
<FLHerne>
I'm a C/Python programmer, have some experience with compiler internals, very little with graphics
<alyssa>
gfxstrand: Let's rename your compiler to "NAK", meaning Names Are Kindahard
<kisak>
and put it right beside the NVIDIA Awesome Kompiler?
kzd has joined #dri-devel
godvino has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
aravind has quit [Remote host closed the connection]
aravind has joined #dri-devel
Kwiboo has quit [Quit: .]
<lumag>
danvet, robclark: ack, I will apply, thank you.
Kwiboo has joined #dri-devel
bmodem has joined #dri-devel
bmodem1 has quit [Ping timeout: 480 seconds]
bmodem1 has joined #dri-devel
nchery is now known as Guest10072
nchery has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
Zopolis4_ has quit []
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
sarahwalker has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
pendingchaos_ is now known as pendingchaos
i509vcb has joined #dri-devel
bmodem has joined #dri-devel
djbw_ has joined #dri-devel
bmodem1 has quit [Ping timeout: 480 seconds]
bmodem1 has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
<javierm>
danvet, tzimmermann: commented on the thread but maybe is easier to discuss here. Can't just land danvet's patch #1 as is and then do any further cleanups on top?
<jenatali>
alyssa: A few weeks ago you were talking about the SM5 shift behavior and how it's weird that NIR inherited that and maybe adding new instructions that don't have the low 5 bits automatically masked. I just learned that apparently DXIL didn't inherit DXBC's behavior here and now it's undefined what happens with oversized shifts
<jenatali>
All that to say, if you did add lowering for shifts to put that masking in nir, you'd have a second customer
<tzimmermann>
javierm, i'll type up something on top of daniel's patchset
<javierm>
tzimmermann: Ok
camus has quit [Remote host closed the connection]
aravind has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
gouchi has joined #dri-devel
smiles_1111 has quit [Ping timeout: 480 seconds]
thellstrom1 has joined #dri-devel
<alyssa>
jenatali: Womp.
thellstrom has quit [Ping timeout: 480 seconds]
<alyssa>
jenatali: You need to mask in your backend then or dozen/d3d12 are already broken, I have a .shader_test somewhere exhibiting the broken
<jenatali>
Womp indeed. Looks like NV requires the manual clamp while other vendors still do the clamp for DXIL shaders
bmodem1 has quit [Ping timeout: 480 seconds]
<jenatali>
Yeah, I'm adding the mask. It manifests in some CL CTS tests and causes flickering in DOOM Eternal :P
<gfxstrand>
Womp womp....
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
<danvet>
javierm, you did review patch 1/3 in the check_var series ... I'm confused?
<alyssa>
jenatali: I just inserted the mask in my backend and eat the instruction count hit. If you do something better in NIR (plumbing through the undefinedness from glsl and vtn) I'd use your thing. Have bigger fish to fry myself
<jenatali>
alyssa: Yeah I just followed suit with what DXC and the DXBC->DXIL converter do, constant values get the mask applied to the constant, dynamic values just get an &
nchery has quit [Ping timeout: 480 seconds]
<alyssa>
Yep
lynxeye has quit [Quit: Leaving.]
ngcortes has joined #dri-devel
junaid has joined #dri-devel
junaid has quit []
moa has quit [Read error: Connection reset by peer]
junaid has joined #dri-devel
<zmike>
Lynne: just a heads up I found and fixed a really annoying corner case in lavapipe's db implementation
<zmike>
it's unlikely you've hit it, but if you're still testing there then you'll want to update from the branch
<Lynne>
I don't think I've hit it, I got it working fine this morning on all vendors
<Lynne>
and promptly proceeded to break it again in a way I don't understand on radv before committing -_-
<zmike>
classic mistake
Haaninjo has quit [Quit: Ex-Chat]
<danvet>
robclark, planning a -fixes pull?
gio has quit [Quit: WeeChat 3.7.1]
gio has joined #dri-devel
bl4ckb0ne has quit [Remote host closed the connection]
Nefsen402 has quit [Remote host closed the connection]
emersion has quit [Remote host closed the connection]
bl4ckb0ne has joined #dri-devel
Nefsen402 has joined #dri-devel
emersion has joined #dri-devel
gio has quit []
tzimmermann has quit [Quit: Leaving]
gio has joined #dri-devel
MajorBiscuit has joined #dri-devel
godvino has joined #dri-devel
<DavidHeidelberg[m]>
robclark: while you being pinged, any objections against kernel uprev to 6.3-rc5? Few whole CI runs, seems without regression
<robclark>
danvet: not that I know of.. but there should be a -next soon
nchery has joined #dri-devel
<DavidHeidelberg[m]>
zmike: btw. the zink+a630 traces failures disappeared after rebuild with `CONFIG_PHY_QCOM_USB_HS=y` back in place not triggered anymore (my guess would be it could be some GCC fail?)
<robclark>
DavidHeidelberg[m]: no objections, did you figure out the zink thing?
<robclark>
huh
<robclark>
odd
<DavidHeidelberg[m]>
robclark: haha, nope; but my guess would be: random GCC/linker error.. since now we're at 6.3-rc5; but before I recompiled against 6.3-rc4 with different kernel config and it also NOT failed
<DavidHeidelberg[m]>
robclark: btw. are a630 powered down or just getting reset signal?
<zmike>
DavidHeidelberg[m]: zink has no bugs!
<DavidHeidelberg[m]>
my guess would be that maybe one runner got flaky and it just presented on this job few times in a row
<robclark>
DavidHeidelberg[m]: hmm, they still have interwebs access..
<anholt>
DavidHeidelberg[m]: reset signal, pretty low level one
<DavidHeidelberg[m]>
anholt: maybe GPU got altered into some weird state which persisted? or just got hit with rate 3 flakes in a row?
<anholt>
I don't know what instability in particular you're looking at, but ci daily says zink-a630-traces at least has been quite unstable.
<robclark>
anholt: DavidHeidelberg[m]: hmm, some of the cheza last contact time was ~55min ago.. but then others have recent last-contact.. which is odd, I think
<robclark>
since I think it really should be all the same NUC
<anholt>
are they all the same format of runner tag?
<robclark>
oh, google-cheza-new vs google-cheza
fab has quit [Quit: fab]
<anholt>
I've cleared out the old mesa-cheza runner registrations from back before bare-metal, too.
<robclark>
I guess it is fine, maybe fritz was playing remotely with the new runners
mohamexiety has joined #dri-devel
bluebugs has joined #dri-devel
junaid has quit [Remote host closed the connection]
<javierm>
danvet: I did, yes
<danvet>
javierm, why did you say that it needs review then?
<javierm>
danvet: no, I meant the other series, patch 1/8 because Thomas disagreed
<danvet>
javierm, ah ok, that was the confusion :-)
<javierm>
danvet: sorry if I pasted the wrong patchwork series
thellstrom has joined #dri-devel
thellstrom1 has quit [Ping timeout: 480 seconds]
bgs has quit [Remote host closed the connection]
mohamexiety has quit [Quit: Konversation terminated!]
srslypascal is now known as Guest10092
srslypascal has joined #dri-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
Guest10092 has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
danvet has quit [Read error: No route to host]
godvino has quit [Quit: WeeChat 3.6]
gouchi has quit [Remote host closed the connection]
danvet has joined #dri-devel
bluetail968 has joined #dri-devel
bluetail9688 has joined #dri-devel
bluetail9688 has quit []
bluetail has joined #dri-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
bluetail96 has quit [Ping timeout: 480 seconds]
bluetail968 has quit [Ping timeout: 480 seconds]
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest10099
srslypascal has joined #dri-devel
bluetail has quit [Remote host closed the connection]
Guest10099 has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
<Lynne>
dj-death: could you rebase your anv descriptor buffer PR? I can test it on an alderlake
rasterman has quit [Quit: Gettin' stinky!]
<Lynne>
also, am I the only one who noticed 2 years ago when git pull --rebase started rebasing your tree on top of the remote, rather than the other way around?
<Sachiel>
I don't think I ever used git pull
<Lynne>
it makes you rebase changes twice in case you're pulling from a remote, once to go back, and once to go forward, twice solving conflicts, it's insane
<gfxstrand>
I've never noticed git pull --rebase have that behavior, ever.
<gfxstrand>
It's always rebased on top of the remote for me
<Lynne>
could've sworn it was not the case, I think it only started doing this last year, in 2020 july
<Sachiel>
some settings changed? The man page for it says it behaves differently depending on parameters
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
tursulin has joined #dri-devel
<Lynne>
the settings themselves changed, first it started warning about not setting --ff-only or --merge or --rebase
<Lynne>
but the new settings don't support the old behavior of rebasing on top of your current tree
mbrost has joined #dri-devel
Zopolis4_ has joined #dri-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
Leopold_ has joined #dri-devel
srslypascal is now known as Guest10101
srslypascal has joined #dri-devel
camus1 has joined #dri-devel
Guest10101 has quit [Ping timeout: 480 seconds]
avoidr has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
<norris>
danvet: are these (PSR + vblank + rockchip) something you want to take another look at, or should I get a Chromium-er to look?
<norris>
but I thought v3 was ready; just fell through the cracks
MajorBiscuit has quit [Ping timeout: 480 seconds]
<danvet>
hm I think I discussed them with robclark or maybe even seanpaul_ already?
<danvet>
vague memories of that at least
<norris>
on IRC? I can try to find if they're somewhere public
<danvet>
norris, I think it's all good, doesn't need my input
<danvet>
maybe inflict them on seanpaul_ :-)
danvet has quit [Remote host closed the connection]
<norris>
OK, if you say so :) it's either been seanpaul_ or dianders as victims, although dianders sometimes wants a non-Chromium-er to look
danvet has joined #dri-devel
<dianders>
Yeah, seanpaul_ is probably better in this case since he's spent much more time in the PSR code than I have. I don't mind being a mule and doing the gruntwork to apply a patch that's been reviewed, but I haven't yet reviewed these ones. If seanpaul_ is unavilable / unable to review them then I'll try to learn enough about this codepath to give them a good review.
danvet has quit [Ping timeout: 480 seconds]
vliaskov_ has quit [Remote host closed the connection]
Leopold_ has quit [Remote host closed the connection]