00:00 airlied: Chaekyung: llvmpipe GL 4.5 support :-P
00:05 mareko: inlined uniforms help perf for uber shaders
00:06 Chaekyung: Dave Airlie (199) llvmpipe list is very long. https://gitlab.freedesktop.org/mesa/mesa/-/blob/2e080767bbb40918e6667151f9248fceff6724b3/docs/relnotes/20.2.0.rst
00:08 mareko: I have written a simple NIR pass that looks at conditions in ifs and if they only contain uniforms, those uniforms are marked for inlining at draw time
00:13 Chaekyung: Had to look it up, "New IR, or NIR, is an IR for Mesa intended to sit below GLSL IR and Mesa IR." So everything using the NIR will be faster thanks to you mareko
00:14 Chaekyung: I hope it is OK that I write that on some site nobody reads, I assume that isn't another trade secret. ;)
00:14 imirkin: mareko: so basically negating the point of ubershaders?
00:15 airlied: they are just taxishaders now
00:15 airlied:hides in a corner
00:17 mareko: Chaekyung: it's fine
00:18 mareko: imirkin: ubershaders are a silly idea
00:19 imirkin: mareko: well, presumably they were added after some benchmarking
00:19 mareko: I'm pretty sure they were not
00:19 Kayden: ooh, run-time uniform specialization?
00:19 imirkin: HdkR: --^
00:20 Kayden: wanted to do that for several years
00:21 HdkR: Hm?
00:21 Kayden: what do you mean by inlining at draw time? making shader variants based on those uniform values and recompiling/optimizing away the dead code?
00:21 imirkin: HdkR: when you added ubershaders to dolphin, were they faster?
00:21 mareko: Kayden: yes
00:21 HdkR: imirkin: Ubershaders were very explicitly added because their runtime performance was slower
00:22 imirkin: not sure i follow that logic...
00:22 Kayden: is that done in a background thread or something, so you can use the version with uniforms at first, then swap it out for future draws when you have the specialization finished?
00:22 HdkR: The only driver stack that they were roughly as fast as the specialized was Nvidia's D3D11 driver
00:22 mareko: Kayden: yes, no stalls
00:22 imirkin: mareko: aha, the no-stalls thing makes sense it'd be better. ok
00:22 Kayden: awesome
00:22 Kayden: you might want to look at loop induction variables as well
00:22 Kayden: in the future
00:23 HdkR: As long as it still compiles the ubershader with the correct branching and only specializes in the background then Dolphin won't make a note of it in a blog post
00:23 imirkin: HdkR: so if the perf was lower with ubershaders, why were they added?
00:23 imirkin: the stalls thing?
00:24 HdkR: Yea, Dolphin uses the ubershader while a worker thread compiles the specialized shader. So it reduces stuttering which is Ubershader's only purpose
00:24 Kayden: mareko: did you add it to the st variants system, or in radeonsi's keys?
00:24 Kayden: presumably I need u_threaded_context and PIPE_CAP_SHAREABLE_SHADERS and so on to be able to use this
00:24 mareko: Kayden: you won't need either
00:24 mareko: Kayden: radeonsi keys
00:25 HdkR: Barring driver implementation details, Currently Dolphin disables the shader compilation thread on i965 and Nouveau because driver issues :P
00:25 Kayden: ok, neat
00:25 imirkin: HdkR: ok, makes sense
00:25 mareko: st/mesa sends 1-4 uniform uint32 along with the constant buffer (that can be uploaded, so driver can't/don't have to read it)
00:26 HdkR: Some games will generate hundreds of shaders in a frame so removing the stuttering is more important than runtime perf in that case
00:26 mareko: actually 0-4 uniforms
00:27 Kayden: mareko: would you mind CC'ing me and idr when you post the MR? would love to take a look at it
00:29 mareko: it was easier than I expected
00:30 Kayden: awesome
00:31 mareko: imirkin: uber shaders are almost always bad if they increase register usage or the number of ins/outs
00:32 imirkin: mareko: yeah, the specialize-in-background thing makes more sense
00:32 imirkin: i had thought you'd be stalling
00:34 Kayden: especially combined with shader cache
00:34 HdkR: If you stall then I'd have to write a strongly worded message in disagreement about behaviour :)
00:34 mareko: you may need the shader cache if you don't have parallel compiles; radeonsi doesn't cache optimized shader variants
00:35 Kayden: mareko: do you have any kind of thresholding for "this uniform changes all the time" vs. "there are really only 1-3 values that they actually use"?
00:36 mareko: Kayden: no, if a condition value is based on uniforms, all those uniforms will be inlined (but at most 4)
00:36 Kayden: what if the condition is like if (x < 200) though and there are 150 different values for x
00:37 mareko: hopefully not :)
00:37 Kayden: hehe, okay :)
00:37 Kayden: yeah, I don't know if that would actually be a case you'd hit or not
00:37 Kayden: might be worth clamping the number of variants though just to avoid pathological cases
00:38 Kayden: I assume you've found some case where this helps performance a bunch?
00:38 Kayden: I remember seeing this in a bunch of older GL demos back in the day, but I haven't looked at modern things to see how much it would help :(
00:38 HdkR: Watch out for Dolphin's case, it's total amount of state is in the hundreds of bytes range :P
00:39 mareko: I also have a mega series of commits optimizing uniform and state var updates
00:39 linkmauve: of bits* IIRC.
00:39 linkmauve: Like 300 bits or so.
00:39 mareko: Kayden: viewperf13
00:39 HdkR: ah, I thought it was nearly 300 bytes, misremembered :)
00:39 Kayden: ahh. figures
00:44 mareko: I'm also considering implementing state binning
00:45 robclark: mareko, Kayden: adreno even has a fun `brac` branch instruction for pre-computed branch conditions (ie if a branch only depends on uniforms, the driver can determine which path is taken at draw time).. the rough theory was to add support for that to krh's (still on a branch) uniform folding pass
00:46 Kayden: robclark: how's that different from normal?
00:46 imirkin: robclark: are you sure that's not "branch to address from uniform"?
00:46 imirkin: since that's a common one to have for implementing subroutines
00:46 robclark: apparently the hw can do something faster when it realizes it is not divergent?
00:47 Kayden: at least our branches actually jump when the condition is uniform
00:47 Kayden: on intel
00:47 robclark: imirkin: no, it is brac.N where N is an offset into a bitmask the driver passes..
00:47 Kayden: but the thinking here was that you'd be able to optimize away a bunch of code if you constant folded the uniform's actual value into a bunch of code
00:48 Kayden: in particular loop induction variables might be interesting, since you could maybe unroll the whole thing and remove variable indexing
00:48 mareko: the main benefit for me is to decrease register usage and eliminate inputs/outputs; conditional are enough for that
00:48 mareko: *conditionals
00:48 robclark: variable indexing isn't super expensive for us.. it is baked into the isa (but does incure some delay slots potentially)
00:49 robclark: for register usage, I guess driver could track regfootprint per branch condition?
00:49 Chaekyung: Does Intel Iris (or anything else) use NIR or is it just LLVMpipe, RadeonSI and Nouveau?
00:50 robclark: iris uses nir
00:50 mareko: Chaekyung: intel was first I think
00:50 Kayden: we were :)
00:50 robclark: *cough* I think freedreno was first ;-)
00:50 Kayden: really?
00:51 mareko: I'm not sure what loop unrolling would bring us, maybe better register usage?
00:51 Kayden: thought it was i965, iris obviously didn't exist then
00:51 dcbaker[m]: Not i965?
00:51 robclark: Kayden: ofc, i965 was first if you are counting non-gallium drivers
00:52 robclark: (I thought the question was about gallium / mesa/st drivers)
00:52 mareko: this is moot if you consider who helped create NIR and who paid for it
00:52 Chaekyung: "NIR is short for New IR.[1]. IR stands for "Intermediate Representation". It is used by the Freedreno, Intel Iris, LLVMpipe, RadeonSI and Nouveau OpenGL graphics drivers. Applications create OpenGL shaders, NIR turns them into intermediate representations and the graphics driver back-ends turn them into graphics displayed on the screen."
00:52 robclark: mareko: not disputing that
00:52 Chaekyung: is that accurate _and_ simple enough that someone who never heard of a NIR before would understand it?
00:53 robclark: Chaekyung: also panfrost?
00:53 Kayden: don't remember the status of etnaviv at this point either
00:53 robclark: (and I guess lima, and some experimental support for etnaviv?)
00:53 Kayden: well...the last part...OpenGL shaders are written in a high level language. NIR is the optimizing middle part of the compiler. the back-end produces assembly code that can run on your GPU.
00:54 Kayden: it doesn't exactly produce graphics
00:54 Chaekyung: robclark: thank you.
00:54 dcbaker[m]: I think it's easier to enumerate the Mesa drivers not using NIR at this point
00:54 Kayden: but you know your target audience better than I do :)
00:54 Kayden: yeah, NIR is used by basically everything that isn't old these days
00:55 robclark: with anholt's work, I think we are getting closer to the point where *everything* uses nir, and a few drivers still have a nir->tgsi step
00:56 Kayden: true! :)
00:56 Chaekyung: Kayden: I try very hard to imagine I used Windows not Linux the last 20 years and I've just installed my first Linux distro and I read an article about a new version of some strange thing called "Mesa" and something I never heard of called NIR is somehow optimized
00:56 dcbaker[m]: Well, other than classic drivers
00:57 bnieuwenhuizen: and clover on radeonsi
00:57 imirkin: dcbaker[m]: i think that leaves only r200 which has shaders and is a classic driver (and isn't i965)
00:57 dcbaker[m]: Who wants to write r100g? 😀
00:57 imirkin: oh, and swrast obviously.
00:59 airlied: bnieuwenhuizen: the clock is ticking on that one :-p
00:59 dcbaker[m]: And really old Nvidia
00:59 imirkin: dcbaker[m]: no shaders supported with vieux
00:59 imirkin: the nv2x's did support ARB_vp and NV_texture_shader, but that support was never added in mesa
00:59 imirkin: (not for the least of reasons that nv2x's are nearly impossible to come by, since they're all AGP. or in xbox's)
00:59 dcbaker[m]: Easiest gallium driver ever?
00:59 bnieuwenhuizen: airlied: tried the nir path yet?
01:01 imirkin: dcbaker[m]: all of those pre-DX9 boards only have fixed function though. the shader capabilities are very limited, and not comparable to what you get with GL 2.x.
01:02 dcbaker[m]: True.
01:03 dcbaker[m]: Really someone just needs to write a gallium driver for ivy bridge and Haswell so we can just dump classic
01:04 ccr:listens to the crickets chirping.
01:04 dcbaker[m]: Lol
01:05 dcbaker[m]: Or just wait a few more years for Haswell to get old enough no one cares..
01:09 ccr: that will probably take more than few years, at least from user perspective. from developer perspective, probably not as long.
01:41 mareko: do those old classic drivers even work?
01:48 dcbaker[m]: Idr is the one who would know that
01:53 jekstrand: i915 does
01:53 jekstrand: r200/300? I don't even know who has that hardware. I think idr has some of it.
01:58 dcbaker[m]: I think idr has r100 and r200 and some old Nvidia
01:58 airlied: bnieuwenhuizen: I had the basic working 6 months ago on nir/llvm
01:58 dcbaker[m]: Not sure about r300
01:59 airlied: once CL lands a few more bits I'll get back to it and make sure it doesn't regress vs the llvm path
02:01 airlied: bnieuwenhuizen: aco support might be a bit more work :-P
02:18 airlied: jekstrand: it's okay, by the amount fo iterations it took me I'm not qualified to write CI changes
02:26 DrNick: I have an R200 in a box
02:26 airlied:has some in cardboard boxes :-P
02:26 DrNick: I do not have a motherboard with AGP
02:26 soreau:still has his old P4 with RV350 in it
02:26 soreau: haven't booted it in years though
02:28 jekstrand: airlied: :)
04:49 Chaekyung: If anyone has time to waste (which may be unlikely), let me know if I missed anything important. https://linuxreviews.org/Mesa_20.2.0_Is_Released
04:53 airlied: Chaekyung: I don't hink mareko's nir changes are in 20.2
04:53 airlied: also nvidia don't own arm yet
04:54 airlied: also the scoreboard is a bit off
04:54 airlied: a lot of employers are wrong
05:09 Chaekyung: they are?
05:12 Chaekyung: I admit I did some quick and simple searches, if you could mention the errors that you know off-hand are wrong then that would be excellent. If you have time, that is.
05:13 mattst88: I'm not even sure where you got some of these. "Arch BTW"?
05:15 Chaekyung: mattst88: https://rhysperry.com/ I tried to find out and failed
05:15 Chaekyung: so I came up with .. that. :-(
05:15 mattst88: that sentence means "I use Arch [Linux], by the way"
05:15 mattst88: he and connor are contracting for Valve, afaik
05:18 Chaekyung: Thank you very much mattst88. I fixed those two now. With 174+88 additonal points Valve's still #2 with 620 points.
05:21 airlied: Chaekyung: Michel Danzer is at Red Hat, Eric Anholt is at google
05:21 airlied: not sure who mikeb is with but not samsung afaik
05:22 Chaekyung: I see many NIR commits by mareko in https://gitlab.freedesktop.org/mesa/mesa/-/blob/2e080767bbb40918e6667151f9248fceff6724b3/docs/relnotes/20.2.0.rst but nothing that sounds like the optimizations he mentioned
05:26 airlied: anholt: with tracie are the different pixels colored? I can't spot the difference with the pow changes :-P
05:28 airlied: https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/4729862/bgfx/14-shadowvolumes.rdc/
05:28 airlied: for e.g. says 51 pixels, but I'm not seeing where :-P
06:41 eric_engestrom: Chaekyung: I'm not sure where you got that I now work at Datapred (which is correct) but my Mesa contributions were from before that, when I worked at Intel :)
06:53 pepp: airlied: the diff pixels are in red in the 3rd (grayscale) image
06:55 pepp: eg there's one near the rabbit's eye
06:55 airlied: pepp: ah wow I was expecting more of a cluster
06:56 airlied: pepp: thanks! looks like I can just update checksums, they don't seem at all important
07:40 Chaekyung: eric_engestrom: thank you
08:22 MrCooper: airlied: might want to dig into why piglit run seems to ignore -j for the cl profile
08:51 airlied: MrCooper: oh wierd may need a -c
08:51 MrCooper: not necessary for GL profiles though
09:03 airlied: MrCooper: yeah cl tests never got parallel on hw likely due to dfiver fail
09:03 airlied: should be fine for llvmpipe!
09:07 MrCooper: airlied: IIRC they do run in parallel with -c though, seems a bit inconsistent
09:10 danvet_: dolphin, just ask linux-next sfr to add drm-intel-gem-next
09:10 danvet_: the for* branches are kinda just for the auto-switching during the merge window
09:12 dolphin: but isn't it broken if we don't do the switching?
09:12 dolphin: all the patches go to -next even if drm-next closes
09:14 danvet_: dolphin, hm right
09:15 danvet_: but that then doesn't the coordination problem with e.g. hch
09:28 pendingchaos: Chaekyung: rhysperry.com is someone else
09:55 Chaekyung: oh no
09:58 Chaekyung: pendingchaos: I removed the link. Sorry about wrongly assuming that there wouldn't be more than one person with that name using Linux. Is the other information accurate?
10:09 pendingchaos: looks fine
12:32 mszyprow|home: hi, can one help me merging the "[PATCH v10 02/30] drm: prime: use sgtable iterators in drm_prime_sg_to_page_addr_arrays()" (https://lore.kernel.org/linux-iommu/20200904131711.12950-3-m.szyprowski@samsung.com/ ) to drm-misc-fixes?
12:32 mszyprow|home: here is the rationale: https://lore.kernel.org/dri-devel/CADnq5_OP4pEg7Cg9E=TUB0viSX8rTALQoFck=ueTh=phTtUfEA@mail.gmail.com/ (the fix is needed in v5.9 for AMDGPU)
12:33 mszyprow|home: I've already sent a pull request containing this patch to drm-next, but this will not cover the v5.9 release
12:34 mszyprow|home: and now it is a bit late, so drm-misc-fixes would be probably the fastest way of handling this fix
12:37 dolphin: <danvet_> but that then doesn't the coordination problem with e.g. hch
12:37 dolphin: danvet_: ^ -EPARSE
12:42 danvet_: dolphin, well if we still have the patches outside of linux-next I mean
12:42 danvet_: e.g. -rc6 done, the patches in -gem-next aren't going 5.10 anyway
12:42 dolphin: agreed
12:42 dolphin: in this specific case they are both Cc: stable fixes, so problem should get sorted out
12:43 dolphin: but we should fix this for the common case.
12:47 dolphin: I think what we should fix here is that cherry-picking Fixes to -next-fixes and -fixes should happen from drm-intel-gt-next, too
12:48 dolphin: j4ni, vivijim: ^^
12:49 dolphin: feel free to cherry-pick the gt-next fixes and the end of the queue
13:37 dcbaker[m]: neobrain: create a she'll script for the 32 bit PKG config that's sets PKG_CONFIG_LIBDIR to the pkg-config directory in /lib32 (or whatever the correct for is) and then call the main pkg-config binary
13:37 dcbaker[m]: *sorry for the typos, I'm on my phone
13:38 jekstrand: hehe
13:39 dcbaker[m]: It's also 6:30 am here, lol
14:37 mareko: tarceri: I've found a problem with the NIR linker, but my fix breaks GL_ACTIVE_UNIFORMS: https://pastebin.com/raw/5VvMSLjf
14:51 jekstrand: airlied: Could I get you to review the vallium patches in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5275
15:29 mareko: a better name and pun on vulkan than vallium would be lavapipe
15:29 jekstrand: I'm in favor of that rename :)
15:30 mareko: airlied: ^^
15:33 jekstrand: The one downside is that l < r so it might load before RADV.
15:36 mareko: so it should be called aaalavapipe to make sure nothing else is loaded :)
15:40 ajax: back in the bad old days when we'd write out an xorg.conf based on your available hardware, we kept a list of pci id map files for each driver
15:40 ajax: looking suspiciously like the modalias lines you get from modinfo
15:40 ajax: and i just rigged it up so that more precise id matches (fewer wildcards, basically) were better
15:41 ajax: why would we not do that for vulkan drivers? radv would claim v1002d*sv*sd*... and lavapipe would claim v*... and thus lavapipe would lose
15:43 ajax: (seriously, ascii sorting?)
15:45 danvet_: daniels, ping for some r-b on the latest ebusy series
15:50 daniels: danvet_: you've shamed me into a r-b
16:12 bnieuwenhuizen: jekstrand: In practice it seems to be reverse create time of the json file and not alphabetical at all ;)
16:13 jekstrand: heh
16:13 bnieuwenhuizen: (disclaimer: verified experimentally on EXT4)
16:28 danvet_: bnieuwenhuizen, oh is it readdir() order?
16:28 danvet_: but then I think that's hashed
16:30 MrCooper: bnieuwenhuizen: I bisected a regression (unredirected fullscreen windows show as solid white in mutter 3.38 Wayland) to https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6783/diffs?commit_id=c6c1fa9a2638800155b31701190af7baccb0c18f , any idea offhand how that might break?
16:33 MrCooper: maybe because it's now doing DCC stuff even for imported textures?
16:34 pepp: MrCooper: I noticed this one as well, thanks for doing the bisection
16:35 MrCooper: no worries :)
16:38 bnieuwenhuizen: MrCooper: thanks, will take a look. what app did you use for rendering, and is that X11 or wayland?
16:39 bnieuwenhuizen: oh I might have a clue
16:40 MrCooper: I was bisecting with glxgears -fullscreen on mutter Wayland, but I just tried mutter on Xorg and it's broken as well
16:42 MrCooper: (FWIW, in the former case only the version of Mesa used by mutter itself (and maybe Xwayland) matters, not glxgears)
16:42 bnieuwenhuizen: MrCooper: does this help? https://gitlab.freedesktop.org/bnieuwenhuizen/mesa/-/commit/08b873ecd453ab07b8e4487465de8bd32b48a49f
16:43 bnieuwenhuizen: seems like one of the rebases missed things :(
16:47 MrCooper: looking good on top of that commit, will test master now
16:49 MrCooper: dropping the RADEON_SURF_IMPORTED check in gfx9_compute_miptree is OK?
16:52 bnieuwenhuizen: MrCooper: it should be because we now create the retile map on the import side as well, so we need the content there :)
16:52 bnieuwenhuizen: but yes, dropping the IMPORTED there is probably what broke things
16:55 MrCooper: it does fix it on master as well
16:58 vsyrjala: scary comment. that gives me an idea for a new igt ;) thanks
17:16 pepp: bnieuwenhuizen: yep, your patch fixes the issue here as well
17:31 airlied: mareko: good name, i might rename it
17:31 airlied: the device select later shoild dtrt now anyways
17:31 airlied: just have to make sure distros build it
18:23 airlied: jekstrand: will give it a spin now
18:49 Kayden: mareko: +1 for lavapipe lol
18:50 Kayden: oh, hey, we shipped a release. nice :)
18:55 vivijim: airlied: about the fixes on drm-intel-gt-next... should we have a drm-intel-gt-fixes for avoiding any potential blockage on the other fixes or does look okay to you to just move with one unified fixes flow so we modify dim tool?
18:56 vivijim: dolphin: ^
18:57 airlied: vivijim: for now let's do what's easiest, which seems like just one fixes
18:57 airlied: at least fixes generally aren't a major body of work to redo
18:58 vivijim: makes sense, thanks
19:10 airlied:crosses fingers, llvmpipe gl4.5 cts submitte
19:11 airlied: jekstrand: seems to regress vallium, will try dig in a bit later
19:14 jekstrand: airlied: :-/ I did some testing locally but not any full CTS runs or anything
19:14 airlied: (or maybe not, I'll have to clean my tree out and rerun
19:14 airlied: dEQP-VK.compute.basic.ssbo_unsized_arr_multiple_groups
19:15 airlied: seems to hit an assert it wasn't before
19:21 mareko: Kayden: do you need to sort draws by states for iris?
19:23 Kayden: mareko: what kinds of state are you thinking of bunching together?
19:23 airlied: jekstrand: I'll dig into it today, once I've woken up a bit more
19:23 Kayden: binning by render target might be handy to reduce cache flushes, but not sure
19:24 mareko: Kayden: rasterizer states
19:24 bnieuwenhuizen: optimizing for context states now?
19:25 mareko: considering it
19:25 bnieuwenhuizen: might be interesting with PBB and all
19:26 mareko: I want to minimize state changes by reordering draw calls
19:26 mareko: we already reorder draw calls for Begin/End, which works fabulously
19:27 rcdrone: daniels: i still see errors if i try to clone my forked repo
19:28 mareko: u_threaded_context is great, because it gets context calls in batches, which can be analyzed and reordered
19:32 airlied: jekstrand: btw are you sure the per-gen trampoline actually buys you anything?
19:33 airlied: I suppose it's all tied into the gen state stuff anyways
19:33 jekstrand: airlied: It's how our whole recompile system works
19:34 jekstrand: airlied: We can't rip it out
19:35 jekstrand: airlied: We could return the trampolines from GetDeviceProcAddr but they're going to exist one way or another.
19:48 airlied: okay vallium->lavapipe rename MR posted :-P
19:49 karolherbst: what is bad about vallium :p
19:49 bnieuwenhuizen: airlied: don't forget to change the name of the label ;)
19:51 airlied: karolherbst: searching for it has a lot of drug company references :-P
19:51 airlied: bnieuwenhuizen: yes once it's merged
19:51 karolherbst: mhhhh
19:51 karolherbst: right...
19:52 airlied: and lava moves pretty slowly
19:52 mareko: also it's a lava pipe between vulkan and llvm
21:05 mareko: which NIR pass eliminates if (false)? nir_opt_dead_cf doesn't
21:29 jekstrand: mareko: nir_opt_if, maybe?
21:33 DPA: I've 3 problems I've trouble to figure out the cause of. Both only happen with glamor.
21:33 DPA: 1) With etnaviv+xorg+glamor (and with non-compositing WM), some parts of the screen don't update when they should: https://dpa.li/temp/etna-xorg-glamor.mp4
21:33 DPA: 2) Rotating the screen will result in a black screen, even if rotating it back, and even if turning the output off and back on with xrandr.
21:33 DPA: 3) A prime shared output will stay black.
21:33 DPA: Does anyone know what could cause these thing? Or can anyone give me a hint what I should check / look for?
21:47 Rush__: hey there, does anybody know if ubuntu ships a debug symbols package for /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so ? trying to debug a memory leak with valgrind
21:48 airlied: Rush: should be in the mesa debug
21:49 Rush: airlied: do you know the package name by any chance?
21:49 kisak: Rush: https://wiki.ubuntu.com/Debug%20Symbol%20Packages
21:50 Rush: I was looking for libgl1-mesa-dri and libgl1-mesa-dri-dbg
21:50 Rush: but libgl1-mesa-dri-dbg doesn't exist
21:50 Rush: kisak: thanks, I already followed this articles :)
21:51 kisak: libgl1-mesa-dri-dbgsym?
21:52 Rush: kisak: no luck
21:54 airlied: jekstrand: posted the regressed cts tests, unsized ssbo handling seems to have busted somehow
21:54 jekstrand: airlied: Right...
21:58 Rush: quick question. Is there a way to limit "GPU memory" in llvmpipe?
22:02 airlied: Rush: not really
22:03 airlied: Rush: why?
22:03 Rush: airlied: is it possible that what I'm seeing as a memory leak is simply mesa lazily managing some graphics memory? I have a server application for which I create an OpenGL context that's long-lived and valgrind is showing memory leaks in some texture-allocated memory.
22:04 Rush: I was looking for debug symbols to actually look at the code responsible for allocating those textures
22:04 Rush: I am looking at this as I almost ran out of 128GBs of memory on my server :-P
22:05 airlied: I doubt mesa will lazily manage 128GB of RAM
22:05 airlied: seems kinda more likely the app isn't cleaning up something
22:06 airlied: llvmpipe_resource_create_all and llvmpipe_resource_destroy
22:06 airlied: are pretty much the alloc/free
22:06 Rush: airlied: yeah that's my thought. I am not blaming mesa at this point. :D a lot of people are using mesa for gaming, scientific applications so it's highly unlikely mesa is at fault
22:07 airlied: Rush: check the number of texutre handles you are getting back on the client side
22:07 airlied: if you are calling glGenTextures and aren't doing proper glDeleteTextures etc
22:09 Rush: airlied: thank you. Will add some extra code to track that.
22:14 jekstrand: airlied: Updated the branch. All those tests pass now
22:18 airlied: jekstrand: kicking off another run, will let you know
22:18 jekstrand: airlied: thanks
22:57 airlied: jekstrand: r-b added
22:58 jekstrand: airlied: \o/
22:58 jekstrand: Now if only I could get someone to RB the final patch....
22:58 jekstrand: cmarcelo: ^^
22:59 jekstrand: cmarcelo: !5275
23:00 airlied: jekstrand: the removal one?
23:00 jekstrand: airlied: yeah
23:06 airlied: jekstrand: is the push constant chunk at the end meant to bein that patch?
23:06 jekstrand: airlied: Which patch
23:06 airlied: the removal patch
23:07 jekstrand: airlied: It could probably be moved up a patch or two
23:07 jekstrand: Let me see if I can do that
23:08 airlied: just seems out of place in the ssbo/ubo patch
23:09 airlied: but since you get rid of vtn_type_block_size maybe it'[s fine
23:09 Rush: my Ubuntu turned out to be out of date (19.10). On 20.04 debug symbols are installing correctly. btw. Should GL_ARB_texture_filter_anisotropic be reported for llvmpipe? it's not listed on "glxinfo" but in docs it's reported that it's available as a no-op
23:09 jekstrand: airlied: I can also drop block_size higher up
23:10 jekstrand: airlied: Moved.
23:10 airlied: Rush: need to fix the docs to remove that
23:11 airlied: jekstrand: okay r-b for updated version
23:11 jekstrand: airlied: Thanks
23:12 airlied: Rush: anisotropic is the only feature blocking GL 4.6
23:12 Rush: airlied: oh nice, so it's on the roadmap?
23:14 airlied: Rush: not really, since I've no clue how to implement it yet :-P
23:29 tarceri: mareko: Did you find a fix? If not I'll take a look