ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
tursulin has quit [Read error: Connection reset by peer]
pnowack_ has joined #dri-devel
pnowack has quit [Ping timeout: 480 seconds]
sadlerap1 has joined #dri-devel
sadlerap has quit [Ping timeout: 480 seconds]
cphealy_ has joined #dri-devel
agx has quit [Read error: Connection reset by peer]
fxkamd has quit []
pnowack_ has quit []
fxkamd has joined #dri-devel
agx has joined #dri-devel
cphealy has quit [Ping timeout: 480 seconds]
<ajax> zackr: known bug in el9 atm
<ajax> we disabled everything but the platform probe methods because doing pci as well gets things stupid confusd
<ajax> but we didn't fix fbdev to _have_ a platform probe method, yet
<ajax> on my plate though
iive has quit []
cphealy_ has quit []
<zackr> ajax: ah, thank you! you don't happen to have a bug number do you?
cphealy has joined #dri-devel
eukara has quit []
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
fxkamd has quit []
mclasen has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
lemonzest has quit [Quit: WeeChat 3.3]
lemonzest has joined #dri-devel
eukara has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Remote host closed the connection]
The_Company has quit []
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
gpuman has joined #dri-devel
<airlied> mareko, krh: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14133 I tried to start with bufferobjs to merge gl/st objects
<airlied> not sure it's my best work, but I think it probably the direction we might want to head.
nchery has quit [Ping timeout: 480 seconds]
macromorgan is now known as Guest8045
Guest8045 has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
macromorgan is now known as Guest8047
Guest8047 has quit [Read error: Connection reset by peer]
mbrost has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
gpuman_ has joined #dri-devel
gpuman has quit [Ping timeout: 480 seconds]
jhli has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
idr has quit [Quit: Leaving]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
kevinx has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
camus has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
danvet has joined #dri-devel
mlankhorst_ has joined #dri-devel
agd5f_ has joined #dri-devel
boistordu_ex has joined #dri-devel
linearcannon has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
<airlied> mareko: some other misc bits are in my st-merge-wip branch
macromorgan is now known as Guest8051
macromorgan has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
Guest8051 has quit [Remote host closed the connection]
mlankhorst_ is now known as mlankhorst
<mlankhorst> morning
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
jkrzyszt has joined #dri-devel
cafuffu has joined #dri-devel
tzimmermann has joined #dri-devel
mszyprow has joined #dri-devel
<tzimmermann> airlied, danvet. i wanted to prepare a PR for drm-misc-next, but the previous one is still pending. could you please merge https://lore.kernel.org/dri-devel/YaSVz15Q7dAlEevU@linux-uq9g.fritz.box/ ?
<danvet> tzimmermann, it's build-testing, I'll ping you when it's pushed
<tzimmermann> danvet, thank you
tursulin has joined #dri-devel
rellla has quit [Quit: ZNC 1.6.5+deb1+deb9u2 - http://znc.in]
rellla has joined #dri-devel
Haaninjo has joined #dri-devel
ced117 has quit [Ping timeout: 480 seconds]
ced117 has joined #dri-devel
alatiera7 has joined #dri-devel
alatiera has quit [Ping timeout: 480 seconds]
alatiera7 has quit []
alatiera has joined #dri-devel
rasterman has joined #dri-devel
<danvet> tzimmermann, pushed
<danvet> (script got stuck had to kick it)
<tzimmermann> ok
pnowack has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
Haaninjo has joined #dri-devel
gruetzkopf has joined #dri-devel
cafuffu has quit [Remote host closed the connection]
gruetze_ has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
rasterman has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
JohnnyonFlame has joined #dri-devel
adjtm has joined #dri-devel
camus has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
hansg has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
mclasen has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<javierm> tzimmermann: hi. Yes, I just came back from holiday and going through my email. Should i push to drm-misc-next or -fixes ?
Company has joined #dri-devel
<tzimmermann> ah, ok
<javierm> tzimmermann: I also plan to push https://lore.kernel.org/lkml/20211126001333.555514-1-javierm@redhat.com/t/ to drm-misc-next
<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> (Newer Malis split coordinate/varying shaders.)
* alyssa also needs to overhaul how varyings are handled, wee..
<alyssa> (Newer Malis don't have any sort of vec4 varying code. You just get an address to do global stores to.)
<alyssa> Then again pretending it's all vec4 and letting glsl packing do its thing is prrrrrobably good enough.
<alyssa> Mainly waffling between adding is_coord to the program key, compiling twice and DCE'ing in NIR,
<alyssa> or compiling once and splitting in the backend, DCE'ing in the backend, and then just splitting off at the very end
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
<alyssa> The latter approach makes it easy to share push constants between the stages, which is needed on Bifrost (but not Valhall)
<alyssa> Not sure there's anything else worth sharing
mclasen has quit []
mclasen has joined #dri-devel
<alyssa> I guess sysvals too as an off shoot of push constatns
mszyprow has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
<alyssa> It looks like ir3 also does binning shaders, let's see how ir3 handles it
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
jernej has joined #dri-devel
<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
<zackr> emersion: ah, i see them now. thanks!
<emersion> sweet
<Venemo> jekstrand: Can you please take a look at this? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12910
Duke`` has quit [Ping timeout: 480 seconds]
<jekstrand> Venemo: I saw. I'll try to look
<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)
<airlied> remexre: fbcon isn't really configurable
<airlied> you can pass some stuff on the kernel cmdline
<remexre> does using fbcon mean that modesetting is an "invalid concept" then?
<remexre> I'm trying to avoid rebooting every time I have to plug in a monitor, heh
<airlied> it should hotplug the console, though the size it picks at boot is the limit
<airlied> due to the design of fbcon
<ajax> anholt: re !14096 does an rv370 count as "original r300" here?
camus has joined #dri-devel
<anholt> should, I actually just mean not-r500
mipmeb has joined #dri-devel
<airlied> ajax, anholt : btw you also might have some opinion on directions on my st-merge-wip branch
<airlied> though the low hanging fruit are very low, and non-low hanging ones are definitely a lot higher
camus1 has quit [Read error: Connection reset by peer]
<anholt> I'm +1 on the general st-merge ideas I've seen going past, but not paying much attention. focusing on trying to get !8044 ready.
<ajax> airlied: i definitely like the general idea of hauling everything up out of src/mesa/state_tracker/
jkrzyszt has joined #dri-devel
mipmeb has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
<alyssa> makes deleting classic feel a lot more justified retroactively 😆
Haaninjo has joined #dri-devel
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
<airlied> I think collapsing the twin binary system of state handling between mesa/st is going to be the "fun" bit
eukara has joined #dri-devel
anarsoul has quit [Quit: ZNC 1.8.2 - https://znc.in]
anarsoul has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
LexSfX has joined #dri-devel
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> this ... hangs for me
<marex> (so does git fetch from that remote)
<Sachiel> yeah, https seems to be dead
<Sachiel> ssh works though
<marex> oh
<marex> git://git.freedesktop.org/git/mesa/kmscube/ this works :)
Haaninjo has quit [Quit: Ex-Chat]
<mdnavare> hwentlan_: siqueira: Do you know if we disable Free sync on the monitor/ panel, how the panel indicates that to the source?
<marex> hmmmmmm, https://paste.debian.net/hidden/1bb29237/ is this VG_BO_ALLOC supposed to show up in valgrind output ?
<marex> robclark: MrCooper: ^
<marex> it looks like some BO didn't get free'd ?
<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
<marex> robclark: https://paste.debian.net/hidden/3fd54cd6/ lima looks like this
mbrost_ has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
<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:
<idr> git@gitlab.freedesktop.org: Permission denied (publickey,keyboard-interactive).
<marex> maybe I should try the imx53 ...
<idr> That seems... bad.
<Sachiel> everything died here
<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
pcercuei has quit [Ping timeout: 480 seconds]