07:35 tzimmermann: airlied, do you accept another PR for drm-misc-next-fixes before sending the drm PR to upstream?
07:37 airlied: tzimmermann: yeah I can
07:39 tzimmermann: ok, thanks. i'll send something out tomorrow at the latest. if it's too late, i'll cherrypick the patches into -misc-fixes
09:52 hakzsam: is 23.0 going to be happen this week?
09:53 wens: r/sb c
12:33 eric_engestrom: dcbaker: ^ for hakzsam's question
13:27 mivanchev: hey, I can't login to freedesktop, says my account is avaiting approval
13:27 mivanchev: can anyone here pleas, uhm, approve it or whatever is necessary
13:27 mivanchev: I wanted to fork Mesa
13:35 FLHerne: mivanchev: have you had the validation email and clicked the link in it?
13:36 mivanchev: yes
13:37 mivanchev: it says "Email was already confirmed, please try signing in"
13:38 FLHerne: You can clone mesa without an FDO account anyway, `git clone https://gitlab.freedesktop.org/mesa/mesa.git/` or whatever
13:39 FLHerne: hm, I don't remember there being any manual approval step
13:39 mivanchev: yes but I need to maintain the fork too
13:39 FLHerne: is it asking you for approval just to sign in, or to perform some particular action?
13:44 mivanchev: I mean I could also just maintain the fork over at github :/
13:44 mivanchev: I guess it's not a big deal
13:45 mivanchev: however next time i wanna send in a patch i have to register anyhow
13:53 hakzsam: a618 spurious failures https://gitlab.freedesktop.org/mesa/mesa/-/jobs/36756745 ?
15:56 zmike: bl4ckb0ne: as promised
15:56 bl4ckb0ne: thanks!
16:04 dcbaker: hakzsam: if the last thing on the release blockers gets sorted. I haven’t looked yet to see if it has
16:04 dcbaker: eric_engestrom: thanks for pointing that out, I would have missed it
16:20 hazl: does anyone happen to have elden ring and ds3 and have experience with profiling? i'm noticing both games don't seem to want to go over 45 FPS or so on a Steam Deck, and I'm wondering if there's some kind of strange issue limiting them. I don't know if the vkd3d on the deck is using the application_override[] patches for ER, but I'm willing to tinker with it/maybe find a new patch for DS3
16:26 ishitatsuyuki: hazl, can you enable performance overlay and see if your GPU utilization is close to 100%?
16:28 hazl: it's generally around 80% in DS3, CPU isn't ever all that high and turning off SMT didn't really hurt performance. RAM usage is usually really high
16:30 ishitatsuyuki: then I think it's more or less a CPU bound situation (interpreting CPU usage is hard because multi cores), it looks like most people runs DS3 at high settings on the Deck and get around 50. 45 doesn't sound too far from that
16:31 hazl: it's just... cranking things way down doesn't change much on its progress towards 60
16:31 ishitatsuyuki: when CPU bound, that can happen
16:31 ishitatsuyuki: probably Deck using a lower resolution also makes it more CPU bound that a typical PC setup
16:33 ishitatsuyuki: I'll check later if there's any low hanging fruit wrt CPU performance, but a lot of time we can't do anything from the outside if the game is optimized poorly
16:34 hazl: https://i.imgur.com/2FheR4u.png this screenshot is making me think maybe i should go revert my change to UMA frame buffer size unless I misunderstand that
16:35 ishitatsuyuki: well, in general, don't mess with anything on Deck if you want the verified experience ;)
16:38 hazl: yeah that was when i was scrambling to try to push elden ring to 60fps, i'll revert it after reinstalling elden ring to look at the numbers there. I saw the flame graphs that were posted on Mike Blumenkrantz's blog and didn't know how to generate those or if they'd be helpful
17:24 daniels: hakzsam: '2023-02-21 13:29:26.086751: Error: Found duplicate result for dEQP-VK.image.queue_transfer.3d.64x31x1.r8g8_srgb,UnexpectedPass at line 1324'
17:24 hakzsam: ah
17:25 karolherbst_: dcbaker: any idea on how to deal with b_ndebug/NDEBUG and bindgen + meson?
17:25 karolherbst_: I can add that flag myself, but I'd rather have meson do that I think
17:51 karolherbst: uhhh
17:51 karolherbst: adding '--cfg' args to rust targets is also broken ;'(
18:05 karolherbst: nvm.. figured out what's wrong, will send patches
18:55 karolherbst: dcbaker: https://github.com/mesonbuild/meson/pull/11430
18:58 karolherbst: but having to do something like this is still annoying: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21451/diffs?commit_id=9ea66a9d851c46563dac6f73e845b8c0a7078523
18:58 karolherbst: maybe meson should add a --cfg ndebug thing on its own?
18:58 dcbaker: karolherbst: thanks. I reviewed that and added to the stable milestone. On the ndebug thing, I’m not sure I understand exactly what needs to happen there. I’m also off work today, so I’ll ask again tomorrow
18:59 karolherbst: okay
19:01 karolherbst: might also make sense to backport it, but I guess as I depend on meson-1.0 already anyway...
19:07 dcbaker: I added it to the 1.0.2 milestone, that’s a simple patch for an obvious bug
19:08 karolherbst: I'll probably create an issue for the general cfg handling in relations to `b_ndebug` because the current situation isn't great :(
19:20 dcbaker: Yeah, at the very least we should be turning off debug_asserts
19:21 dcbaker: But an issue would be good
19:25 jenatali: Out of curiosity, have people done any attempts at benchmarking / optimizing some of Mesa's containers?
19:26 jenatali: Looks like we're seeing some pretty significant decreases in driver overhead by switching from Mesa's hash table to std::unordered_map
19:27 airlied: pretty sure the hash table has seen a few rounds of optimisations over time
19:29 airlied: but if std:: anything beats it, then there must be some bad paths :-P
19:29 jenatali: Well, only looking at MSVC's STL right now, which is actually pretty decent
19:30 jenatali: At least, within the bounds of what's required by the standard
19:32 airlied: jenatali: did you replace hash tables across the board or only in specific places?
19:32 jenatali: Just one spot
19:34 airlied: at least on Linux unordered map seems to be fnv which xxhash claims to be faster than
19:34 airlied: but maybe some other aspect of how it's being used might make a difference
19:37 jenatali: It's a u64 table, so it's not the hashing that's the problem I think
19:41 zmike: I've had perf zero in on set/hashtable lookups more than once
19:41 zmike: part of why I've tried to avoid using it
20:14 jenatali: Yeah our dev who tried it was seeing a 7% improvement on overall frame times for a driver overhead benchmark
20:17 cmarcelo: jenatali: which table was changed for this improvement?
20:18 jenatali: cmarcelo: One in our driver
20:27 anholt_: looks like d3d12 would really like a "try insert, return error on duplicate" behavior to avoid search and then insert on fail.
20:27 anholt_: (not uncommon!)
20:34 jenatali: Yeah
20:34 jenatali: I think also embedding data in the nodes would help
20:34 jenatali: Which C++ templates let you do
20:39 anholt_: yeah, fair.
20:42 anholt_: though that would often extend the already nasty scope of lifetime management issues with the ht.
20:49 jenatali: Yep. I think at least for this one we might actually use the STL container... Not sure
21:29 jenatali: anholt_: Re: skipping flushes (!21344) - were you trying to say we shouldn't apply that workaround?
22:14 anholt_: jenatali: I think that the workaround may not be cheating at the specific benchmark you're measuring, but may cheat at other components of gfxbench. and I'm generally really skeptical of people trying that cheat in various places. but I haven't NAKed it elsewhere, either, just giving you lots of side eye.
22:16 jenatali: Yep, fair
22:17 jenatali: If it was a benchmark that was intending to measure submit overhead, then yeah flushing a lot would make sense. And we could (and maybe should?) try to lower our submit overhead and/or have more batches in flight - though that would have memory cost
22:19 jenatali: So I guess what I'm trying to say is, at least for us, it makes the benchmark more representative by shifting the focus to what it's actually trying to measure