ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
iive has quit [Quit: They came for me...]
djbw has joined #dri-devel
kzd_ has joined #dri-devel
jkrzyszt_ has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
<Lynne>
airlied: what's wm_invalid? I don't see it in any code
bgs has joined #dri-devel
dliviu has quit [Ping timeout: 480 seconds]
dliviu has joined #dri-devel
jdavies_ has quit [Ping timeout: 480 seconds]
egbert is now known as Guest4784
egbert has joined #dri-devel
phasta_ has joined #dri-devel
Guest4784 has quit [Ping timeout: 480 seconds]
<airlied>
Lynne: gm_invalid in ffmpeg sorry
phasta has quit [Ping timeout: 480 seconds]
<airlied>
the code to derive it is in get_shear_params_valid
<Lynne>
ah, yeah, it's pretty reasonable to ask the parser to validate them
stuart has quit []
<Lynne>
I'll put it in StdVideoAV1MESAGlobalMotionFlags
Net147 has quit [Quit: Quit]
Net147 has joined #dri-devel
bgs has quit [Remote host closed the connection]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
Kayden has quit [Quit: go home]
ngcortes has joined #dri-devel
pochu_ has quit [Ping timeout: 480 seconds]
ngcortes has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
pochu has joined #dri-devel
ngcortes has quit [Read error: Connection reset by peer]
<kurufu>
Maybe this isnt quite the right place, but is it expected for glTexImage2D with NULL data argument to actually set gpu memory? I see a huge perf regression on dg2 due to aux initialization that isnt on any other drivers or integrated chips.
<kurufu>
or if it is happening in integrated chips its so fast as to be unmeasurable.
Kayden has joined #dri-devel
konstantin_ has quit [Ping timeout: 480 seconds]
konstantin has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
Zopolis4 has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
kts has joined #dri-devel
aravind has quit [Read error: Connection reset by peer]
aravind has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
Haaninjo has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
pallavim has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
yuq825 has joined #dri-devel
tzimmermann has joined #dri-devel
Zopolis4 has quit []
Zopolis4 has joined #dri-devel
itoral has quit [Remote host closed the connection]
<MrCooper>
same on first retry, second retry passed
danvet has quit [Ping timeout: 480 seconds]
liyi_ has joined #dri-devel
liyi has quit [Remote host closed the connection]
danvet has joined #dri-devel
darkapex has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
phasta has joined #dri-devel
<MrCooper>
bnieuwenhuizen: out of curiosity, why are you interested in explicit sync in the X11 (and Wayland) protocol? Aren't gfxstrand's ioctls enough to disable implicit sync in RADV?
srslypascal has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
mairacanal9 is now known as mairacanal
aravind has joined #dri-devel
javierm has quit [Quit: leaving]
javierm has joined #dri-devel
liyi_ has quit [Ping timeout: 480 seconds]
hansg has joined #dri-devel
sergi has left #dri-devel [#dri-devel]
danvet has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
apinheiro has joined #dri-devel
hansg has quit [Quit: Leaving]
fab has joined #dri-devel
JohnnyonFlame has joined #dri-devel
itoral has quit []
gawin has joined #dri-devel
<gawin>
am I right that gitlab recently hasn't been sending some mails?
<daniels>
gawin: nope, it's been working fine for me
pochu has quit []
fab has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[m]>
MrCooper: when 2G of zram is not enough...
abhinav__5 has joined #dri-devel
kts has joined #dri-devel
Cyrinux9 has quit []
abhinav__ has quit [Ping timeout: 480 seconds]
Cyrinux9 has joined #dri-devel
nchery has quit [Read error: Connection reset by peer]
jannau_ has quit []
jannau has joined #dri-devel
Zopolis4 has quit []
sergi has joined #dri-devel
sergi has left #dri-devel [#dri-devel]
sergi has joined #dri-devel
sergi has left #dri-devel [#dri-devel]
<enunes>
MrCooper: DavidHeidelberg[m]: hmm that failure is not any known issue, we have been running piglit in CI for a very long time and I don't remember seeing it happen
sergi has joined #dri-devel
<DavidHeidelberg[m]>
enunes: for some reason when replaced xorg with weston for traces, traces run earlier than weston bringup.. Have to investigate. But for angle traces it does work reliably... :D
Namarrgon has quit [Ping timeout: 480 seconds]
sergi has left #dri-devel [#dri-devel]
sergi has joined #dri-devel
kts has quit [Quit: Leaving]
ice9 has quit [Ping timeout: 480 seconds]
ice9 has joined #dri-devel
<jenatali>
Is there a label for backports? Or some other way that release maintainers prefer to be notified of backport MRs?
fxkamd has quit [Remote host closed the connection]
phasta_ has joined #dri-devel
phasta has quit [Ping timeout: 480 seconds]
<kisak>
jenatali: merge requests targeting staging/##.# should be enough to get the release maintainer's attention. If you think something fell through the cracks, then you can find who is managing that release branch at https://docs.mesa3d.org/release-calendar.html and give them a ping on the merge request.
<jenatali>
Mmkay, just wasn't sure if the targeted MR would notify them or if there was some other process to let them know
Haaninjo has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
JohnnyonFlame has quit [Remote host closed the connection]
tursulin has quit [Read error: Connection reset by peer]
tursulin has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
elongbug has joined #dri-devel
Danct12 has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
jfalempe has quit [Quit: Leaving]
zackr has joined #dri-devel
<zackr>
tzimmermann, mripard, mlankhorst: i have two fixes that should go in drm-misc-fixes but unfortunately will conflict between drm-misc-next and drm-misc-fixes. is there a preferred way of resolving it ahead? i thought of submitting them to drm-misc-next and then cherry-picking and resolving on drm-misc-fixes to record the resolve and pushing the two branches then
phasta_ has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
<mripard>
zackr: apply it to drm-misc-fixes, and fix the merge conflict in tip
nora has quit [Remote host closed the connection]
Namarrgon has joined #dri-devel
<mripard>
there's no need to apply it twice
djbw has joined #dri-devel
Company has joined #dri-devel
bgs has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
elongbug has quit [Remote host closed the connection]
kzd has joined #dri-devel
elongbug has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
devilhorns has quit []
Duke`` has joined #dri-devel
pallavim has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
tursulin has quit [Ping timeout: 480 seconds]
elongbug has quit [Remote host closed the connection]
<zackr>
mripard: the patches were written on top of changes that went into drm-misc-next, so the commits that went to dri-devel were on top of, essentially drm-misc-next, that means dim apply on drm-misc-fixes will conflict and once i resolve that the drm-tip will conflict with the opposite of what i just resolved for drm-misc-fixes. so the cherry-pick would eliminate the silly second conflict. but it's just 2 patches so if the double conflict way is
<zackr>
preferred i'll do it that way. thanks!
tzimmermann has quit [Quit: Leaving]
kzd has quit [Quit: kzd]
heat has quit [Ping timeout: 480 seconds]
<zackr>
mripard: actually this is a bit of a mess. the patches won't apply through dim apply at all because they were written on top of commits that are in drm-misc-next, so git will throw "error: sha1 information is lacking or useless, error: could not build fake ancestor" i can, of course, apply manually with patch -p1 but then the Link to patchworks points to an email with a different diff
<javierm>
zackr: I believe there's `dim cherry-pick` for that
<javierm>
zackr: but if is for fixes in -next, why not push through that or does it have to go to this -rc cycle ?
<javierm>
zackr: it's quite likely that if it applies cleanly to v6.2, that will be backported by the stable folks if land in v6.3 and has a Fixes: tag
kzd has joined #dri-devel
<zackr>
javierm: the two patches are not for things in -next, they're both security fixes, it just that the code they touch was rewritten in current -next so i wrote them on top of that. i can rewrite them on top of 6.1 and then push them through drm-misc-fixes and eventually resolve via drm-tip but that's definitely not less work than a cherry pick from drm-misc-next
<javierm>
zackr: another thing you could do then is apply on -next and then post a backported version to stable@
<javierm>
zackr: that way you only have the patch once in mainline but still is backported to older stable versions
<zackr>
javierm: yes, that's a good idea. i'd have to wait for drm-misc-next to be merged to linus' tree for this though, wouldn't i?
<javierm>
zackr: I don't think so. I believe that once it's pushed to drm-misc-next then you can already post it to stable since the commit sha-1 should be the same?
<javierm>
zackr: but that's a good question, probably mripard or tzimmermann could give advice here
mbrost has quit [Ping timeout: 480 seconds]
<zackr>
javierm: cool, i'll wait until tomorrow to hear from them before doing anything then
<javierm>
zackr: sounds goods
alyssa has joined #dri-devel
<alyssa>
zmike: "vulkan requires that vertex attribute access be aligned to the size of
<alyssa>
a component for the attribute"
<alyssa>
do you have a spec citation for this? I can't find one
<alyssa>
so no unaligned vertex fetch for AGXV, that's good to know
<alyssa>
in that case won't bother extending agx_nir_lower_vbo, cause if it's good enough for Zink it's good enough for asahi gl :^)
<zmike>
smh writing a new gl driver in the current year
<alyssa>
it's not new
<alyssa>
strictly there's an icky edge case in the VK text, because they ask for alignment of the final address -- not the inputs
<alyssa>
which are not equivalent if you only render a single point
<alyssa>
R32 attribute, a single point, offset=3, stride=17
<alyssa>
er no
<alyssa>
lol no I can add
<alyssa>
nvm
<alyssa>
input #0 is accessed at offset, so offset must be aligned
<alyssa>
input #1 is accessed at offset + stride, so since offset is aligned, so is stride
<alyssa>
yeah ok got it
jkrzyszt has joined #dri-devel
<jenatali>
Yep, D3D had to relax our validation to match VK
<alyssa>
jenatali: what case needs to be relaxed..?
<alyssa>
drawing zero points? :~P
<jenatali>
D3D required that the offset within a vertex element needed to be aligned. Instead, the requirement is that the final address needs to be aligned
elongbug has quit [Read error: Connection reset by peer]
bgs has quit [Remote host closed the connection]
gouchi has quit [Remote host closed the connection]
junaid has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
mmind00 has joined #dri-devel
ice9 has quit [Ping timeout: 480 seconds]
Ristovski has quit [Quit: 0]
apinheiro has joined #dri-devel
Ristovski has joined #dri-devel
<danvet>
zackr, since we still have -fixes open I'd apply to -next, then cherry-pick over with -x (not sure we have a dim cmd for that) and make sure you land it tomorrow so it doesn't miss the release
<danvet>
for stable you need to wait until -next is in linus' tree before stable takes it, which I think is not a good idea for these patches
<danvet>
javierm, ^^
<danvet>
zackr, also good idea to tell the drm-misc maintainers what you've done in case of conflicts (but drm-tip should catch these too)
<danvet>
oh also only put the cc: stable onto the version in -fixes, otherwise stable gets it twice and gets very confused
<danvet>
and if you do miss the release, then drm-misc teams should make sure it at least lands in the big merge window pull (but occasionally something goes amiss in the handover there)
<javierm>
danvet: ah, I didn't know it was a requirement to actually land in linus' tree to post to stable
<danvet>
mripard, mlankhorst ^^ fyi
<javierm>
danvet: and yeah, we do have a -x command in dim: `dim cherry-pick`
<javierm>
it does a `it cherry-pick -s -x -e`
<danvet>
well I'm never sure whether that only works for drm-intel or also misc :-)
<javierm>
danvet: I've used for misc in the past so I can say that worked for me at least :)
<danvet>
ah yeah that's the one
<danvet>
zackr, dim cherry-pick is your friend
<javierm>
danvet: also, since commit 281550897a58 ("dim: Consider fix-of-fix for -fixes cherry picking") it can even do transitive cherry-picks which is awesome
jkrzyszt has quit [Ping timeout: 480 seconds]
<javierm>
thanks to rodrigovivi
<danvet>
weaponized bash scripting is scary
<javierm>
danvet: s/weaponized// :)
Zopolis4 has quit []
zf has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
apinheiro has quit [Quit: Leaving]
zf has joined #dri-devel
darkapex_ has joined #dri-devel
<gfxstrand>
dschuermann_: Sorry review on continues has taken so long. This is apparently NIR week, so I'm going to try and get a solid full review done. It's 5:30 PM now so I may not get through it all tonight but I'll hopefully be all the way through or blocked tomorrow.