<tzimmermann>
'git tag --contains b3484d2b03e4' says that the broken commi tis already in upstream. so the revert should go into drm-misc-fixes
<javierm>
tzimmermann: ok, thanks
<tzimmermann>
same for 8633ef82f101
<tzimmermann>
'git tag --contains 8633ef82f101' says v5.15-rc1
<tzimmermann>
so the fix should go into -fixes
minecrell has quit [Read error: Connection reset by peer]
<tzimmermann>
patches in -next take a while into upstream
<javierm>
right, I keep getting confused because some subsystems only allow fixes for patches that landed during the current merge window (i.e: 5.16-rc1)
<javierm>
tzimmermann: cool, I'll push both to -fixes then
<tzimmermann>
but how do they handle fixes for older changes?
minecrell has joined #dri-devel
<javierm>
tzimmermann: they land eventually. The rationale is that a fix could again introduce a bug and if there was already a release with that bug, it can wait
<tzimmermann>
hmm, ok
mclasen has quit []
mclasen has joined #dri-devel
<javierm>
in other words, the -rc cycle is only used to stabilize the code added during the latest merge window. They make exceptions of course for critical bugs that shouldn't wait
enunes has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: pushed the first patch to -fixes and asked the efi maintainer for the second one. He will pick that one through his tree
yk has quit [Read error: Connection reset by peer]
yk has joined #dri-devel
<tzimmermann>
thanks
enunes has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
vivijim has joined #dri-devel
sadlerap1 has quit []
sadlerap has joined #dri-devel
gpuman has joined #dri-devel
gpuman_ has quit [Ping timeout: 480 seconds]
agd5f_ has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
<marex>
uh, so, after running glmark2 on mesa 21.3.1 for an hour, the rss increased from 24 MiB to 84 MiB
agd5f has quit [Read error: No route to host]
<marex>
both on lima and etnaviv
agd5f has joined #dri-devel
kevinx has quit [Ping timeout: 480 seconds]
gpuman_ has joined #dri-devel
gpuman has quit [Ping timeout: 480 seconds]
fxkamd has joined #dri-devel
rasterman has joined #dri-devel
sdutt has joined #dri-devel
<MrCooper>
marex: does "valgrind --leak-check=full" find anything?
mattrope has joined #dri-devel
FireBurn has joined #dri-devel
pcercuei has quit [Read error: No route to host]
alyssa has joined #dri-devel
pcercuei has joined #dri-devel
<alyssa>
v3d people: Any advice on handling coordinate shaders?
<alyssa>
seems like ir3 does the split after optimization, but doesn't share up till that point
<alyssa>
* Note that for a6xx and later, we do this after ir3_cp to ensure
<alyssa>
* we can re-use same VS_CONST state group.
<alyssa>
* that the uniform/constant layout for BS and VS matches, so that
<alyssa>
This sounds like a hack. It would indeed solve my problem on Bifrost... lol.
lemonzest has quit [Quit: WeeChat 3.3]
jernej has quit [Remote host closed the connection]
jernej has joined #dri-devel
iive has joined #dri-devel
JohnnyonFlame has joined #dri-devel
<robclark>
alyssa: fwiw, prior to a6xx, at draw time we generate separate cmdstream for draw vs binning passes.. so the binning VS has it's own const state.. with a6xx we can use (mostly) the same cmdstream for both passes, so to avoid emitting duplicate const state we make sure that BS and VS have the same const state layout.. other than that detail, BS is pretty easy.. it is just VS with all the outputs that are not
<robclark>
gl_Position/gl_PointSize stripped out
<zackr>
are there any dri-devel ml admins online? I see two emails that didn't get to the list: "[PATCH v2] drm/vmwgfx: Bump the minor version" Message-Id: <20211209024924.3298137-1-zack@kde.org> and the review for it from Martin Krastev Message-ID: <0ddf6527e8395201dbb23456a8f6f9217391ae8a.camel@vmware.com>
* emersion
looks
<zackr>
or at least i can't see them in the archives
<emersion>
they aren't stuck in moderation
<emersion>
zackr: how long since they were sent?
<MrCooper>
some time ago there were issues so the archives didn't have all messages, might still be the case
<emersion>
mailman is down
<emersion>
so is certbot
<emersion>
hm
<tzimmermann>
emersion, i'm missing my PR for drm-misc-next
<zackr>
emersion: the bump minor last night and the reply about 8 hours ago
<emersion>
okay, seems like it's restarting up fine…
<zackr>
emersion: ah, that could explain it, did you get "[PATCH v2] drm/vmwgfx: Bump the minor version" through the list?
<emersion>
eh, has a lot of work to do, all cores are busy now :3
<emersion>
i think it's caused by that full disk issue
<emersion>
daniels fixed it, but apparently some processes crashed because of it
<emersion>
can't really tell, the logs have been rm'ed :P
<Venemo>
thanks. it's been waiting for 2 months now without a single comment
shashanks has quit [Ping timeout: 480 seconds]
jadahl_ is now known as jadahl
tzimmermann has quit [Quit: Leaving]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
<alyssa>
robclark: Nod.. just trying to figure out the right time to strip out the other outputs, and what data structures to use to represent things
<robclark>
If it weren't for wanting to keep identical const state, it probably wouldn't be too hard to do in nir.. OTOH if the backend does DCE it is pretty trivial to do in the backend (and I'm pretty sure what we currently do dates back to the TGSI frontend in the pre-nir days)
<alyssa>
*nods*
nchery has joined #dri-devel
<alyssa>
robclark: any reason ir3 doesn't split the compiles "late"?
<anholt>
alyssa: for vc4/v3d, I think both of them I just strip out the unused store_outputs in NIR and DCE
<alyssa>
like, do NIR->ir3, ir3 constant state stuff, and then ir3_clone() and compile the two variants from there
<anholt>
I want all of algebraic's instr selection stuff to apply after the DCE, and peephole_sel, and all that.
<alyssa>
(to reduce the compile time hit from compiling twice)
<alyssa>
anholt: hadn't considered peephole_sel, right..
<marex>
MrCooper: I suspect there might be two issues, one seems like etnaviv specific leak, the other like something in nir
<MrCooper>
valgrind could find both of those in principle
Duke`` has joined #dri-devel
<alyssa>
so there are compelling optimization reasons to do it both in nir or in the backend ... groan :v
<anholt>
generally the CS ends up short enough that I've never considered its compile time an issue
<anholt>
coordinate shader, that is
<alyssa>
yeah, that's fair
<robclark>
alyssa: about the only thing we'd save by doing it "late" is nir->ir3.. because removing instructions changes scheduling, RA, etc..
<marex>
MrCooper: or maybe it is me introducing more issues by using ASAN
<marex>
MrCooper: lemme check
<alyssa>
robclark: right, and nir->backend is the cheapest part of the compile anyway.
<robclark>
right
<alyssa>
I think I'll copy what a6xx does for now, since the const state needs to be shared on bifrost
<MrCooper>
marex: ah, I guess ASAN has to store some information somewhere :)
<alyssa>
and if for some reason that's not good enough, can cross that bridge when we get there
shashanks has joined #dri-devel
<marex>
MrCooper: should that storage grow during the lifetime of a non-leaky process though ?
<MrCooper>
not sure, but seems plausible offhand
remexre has joined #dri-devel
<jekstrand>
Venemo: It'd be nice if there were perf numbers to go with it
<pendingchaos>
!12910 gave me a roughly -15% to -18% change (depending on thread count) in compile time for a collection of shaders with my 5950x
<pendingchaos>
-33% change with a less powerful cpu
<jenatali>
:O
<pendingchaos>
IIRC !524 was intended to improve performance with multithreaded compilation, but !12910 seems to still help with a single thread
<pendingchaos>
I haven't tried radeonsi or any other compilers, but I guess the impact is smaller for radeonsi since llvm is slow
eukara has quit []
ifreund has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
ella-0 has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
ella-0_ has quit [Read error: Connection reset by peer]
ngcortes has joined #dri-devel
<ngcortes>
nb. there will be a short downtime of the internal intel mesa CI results site this morning while I release another patch.
mszyprow has joined #dri-devel
idr has joined #dri-devel
LexSfX has quit []
jkrzyszt has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
<remexre>
this is possibly the wrong channel to ask this, but is svgatextmode still the "right" tool to configure a second monitor, resolution, etc. before X or Wayland are started?
<ngcortes>
intel mesa ci internal results site is back online
<airlied>
remexre: unlikely
frieder has joined #dri-devel
frieder has quit []
Kayden has quit [Quit: to the office!]
<remexre>
any idea what the right tool would be nowadays? (or is this an opportunity to write my own, lol)
hansg has quit [Remote host closed the connection]
mlankhorst has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
yk has quit [Read error: Connection reset by peer]
<alyssa>
Remark on sharing constant state between position/varying shaders -- the position shader is expected to be smaller than the varying shader, and runs at least as often
<alyssa>
That suggests the heuristic of giving position shaders priority on pushing constants
<alyssa>
"Push as much of the position shader's uniforms as possible. If any space is left over, then push as many varying shaders uniforms as possible."
<alyssa>
Motivated reasoning admittedly ... this means I can compile the position shader first, and the varying shader second, and just teach the UBO analysis pass to not clobber existing pushes
<anholt>
does your varying shader not also have to compute position again?
<anholt>
(so it would need the same ubo loads that position does)
<anholt>
in which case, yeah, you definitely want those ones.
<anholt>
does anyone have a nir pass laying around that takes a phi of with a vec src where some of the srcs are the same on both sides and make it into a vec of the phi of the changing subset?
<anholt>
sorry, some of the src components are the same on both sides
<alyssa>
anholt: The varying shader does not need to recompue position, no
<alyssa>
With the possible exception of transform feedback? Not entirely sure how XFB interacts with this
<anholt>
alyssa: interesting! different from bcm and qcm
<alyssa>
Delightful :p
<alyssa>
anholt: Keep in mind up until Valhall, userspace was responsible for allocating memory for all the varyings
<alyssa>
Mali's geometry pipeline is a bit... behind
<anholt>
for those two you end up doing position again. and XFB happens in the bin shader. (or if you're qcm and in the funny not-binning but tiled-rendering mode, then in the first tile's pass over all the geometry)
* alyssa
shaves a yak
zamundaaa[m] has joined #dri-devel
<robclark>
fwiw, what gets written back to memory for binning pass on adreno is not pos/psize.. but a compressed "visibility stream" about which vertices are visible in which tile/bin.. the idea being that re-calculating things during the actual draw pass is less expensive than the extra memory bandwidth of outputting pos/psize (plus I guess most VS have some overlap in calculation of position and varyings).. I guess bcm is similar
mbrost has quit [Ping timeout: 480 seconds]
Kayden has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<alyssa>
robclark: seems reasonable
mbrost has joined #dri-devel
<marex>
uh ... is something going on with gitlab ?
<marex>
that's with etnaviv, it isn't there with lima
Duke`` has quit [Ping timeout: 480 seconds]
<robclark>
yeah, does sound that way.. could be some missing context or screen cleanup.. assuming it isn't simply the app not cleaning up when it exits.. you'd have to check if lima instruments it's gem bo allocation
<marex>
lima does not instrument it, but with lima there is also no almost 40 MiB of still reachable data
<robclark>
so valgrind isn't going to otherwise properly account for mmap'd gem bo's, so if a driver is not instrumented, valgrind is likely to undercount
mattrope has quit [Ping timeout: 480 seconds]
vivijim has quit [Ping timeout: 480 seconds]
<marex>
robclark: the only other one which does counting is freedreno, right ?
<idr>
ssh access to gitlab was working, but now I get:
<marex>
urgh, kmscube died with etna_resource_alloc:285: Problem allocating kms memory for resource
mbrost has quit [Ping timeout: 480 seconds]
<robclark>
marex: for some of the drivers, the instrumentation might be in libdrm.. IIRC I mostly copied libdrm_intel when I added the valgrind instrumentation for freedreno
mattrope has joined #dri-devel
<marex>
robclark: I wonder if kmscube just doesn't do any cleanup when it exits
<robclark>
it's possible, a lot of things don't
<alyssa>
Oh, and I need to compile non-IDVS variants in case rasterizer discard is used. Fun.
<alyssa>
Into the key it goes.
<marex>
robclark: I'll set up the imx53 with freedreno tomorrow and see what happens there
mlankhorst has quit [Ping timeout: 480 seconds]
<marex>
robclark: so yes, the imx53/freedreno does indicate VG_BO_ALLOC leak too, so it is kmscube which does not do any cleanup