bluetail has quit [Read error: Connection reset by peer]
bluetail5 has joined #dri-devel
Major_Biscuit has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
agd5f_ has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Remote host closed the connection]
agd5f has joined #dri-devel
agd5f_ has quit [Ping timeout: 480 seconds]
agd5f_ has joined #dri-devel
<zmike>
bl4ckb0ne: as promised
<bl4ckb0ne>
thanks!
aravind has quit [Ping timeout: 480 seconds]
agd5f has quit [Ping timeout: 480 seconds]
<dcbaker>
hakzsam: if the last thing on the release blockers gets sorted. I haven’t looked yet to see if it has
<dcbaker>
eric_engestrom: thanks for pointing that out, I would have missed it
Peuc has quit [Quit: Peuc]
kzd has joined #dri-devel
ice9 has quit [Ping timeout: 480 seconds]
Peuc has joined #dri-devel
bgs has joined #dri-devel
hazl has joined #dri-devel
fab has joined #dri-devel
junaid has quit [Remote host closed the connection]
<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
<ishitatsuyuki>
hazl, can you enable performance overlay and see if your GPU utilization is close to 100%?
kts has quit [Quit: Konversation terminated!]
<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
<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
<hazl>
it's just... cranking things way down doesn't change much on its progress towards 60
<ishitatsuyuki>
when CPU bound, that can happen
<ishitatsuyuki>
probably Deck using a lower resolution also makes it more CPU bound that a typical PC setup
macromorgan is now known as Guest5491
Guest5491 has quit [Read error: Connection reset by peer]
<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
macromorgan has joined #dri-devel
<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
<ishitatsuyuki>
well, in general, don't mess with anything on Deck if you want the verified experience ;)
<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
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
mbrost has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
phasta has quit [Remote host closed the connection]
idr has joined #dri-devel
gildekel has quit [Quit: Connection closed for inactivity]
<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'
<hakzsam>
ah
smiles has quit [Ping timeout: 480 seconds]
<karolherbst_>
dcbaker: any idea on how to deal with b_ndebug/NDEBUG and bindgen + meson?
<karolherbst_>
I can add that flag myself, but I'd rather have meson do that I think
<karolherbst>
maybe meson should add a --cfg ndebug thing on its own?
<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
<karolherbst>
okay
<karolherbst>
might also make sense to backport it, but I guess as I depend on meson-1.0 already anyway...
<dcbaker>
I added it to the 1.0.2 milestone, that’s a simple patch for an obvious bug
<karolherbst>
I'll probably create an issue for the general cfg handling in relations to `b_ndebug` because the current situation isn't great :(
mbrost has joined #dri-devel
nchery has joined #dri-devel
<dcbaker>
Yeah, at the very least we should be turning off debug_asserts
<dcbaker>
But an issue would be good
<jenatali>
Out of curiosity, have people done any attempts at benchmarking / optimizing some of Mesa's containers?
<jenatali>
Looks like we're seeing some pretty significant decreases in driver overhead by switching from Mesa's hash table to std::unordered_map
<airlied>
pretty sure the hash table has seen a few rounds of optimisations over time
<airlied>
but if std:: anything beats it, then there must be some bad paths :-P
<jenatali>
Well, only looking at MSVC's STL right now, which is actually pretty decent
frieder has quit [Remote host closed the connection]
<jenatali>
At least, within the bounds of what's required by the standard
<airlied>
jenatali: did you replace hash tables across the board or only in specific places?
<jenatali>
Just one spot
<airlied>
at least on Linux unordered map seems to be fnv which xxhash claims to be faster than
<airlied>
but maybe some other aspect of how it's being used might make a difference
<jenatali>
It's a u64 table, so it's not the hashing that's the problem I think
<zmike>
I've had perf zero in on set/hashtable lookups more than once
<zmike>
part of why I've tried to avoid using it
Zopolis4 has joined #dri-devel
junaid_ has joined #dri-devel
Haaninjo has joined #dri-devel
cybersyn has joined #dri-devel
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
<jenatali>
Yeah our dev who tried it was seeing a 7% improvement on overall frame times for a driver overhead benchmark
<cmarcelo>
jenatali: which table was changed for this improvement?
<jenatali>
cmarcelo: One in our driver
ruper has quit []
ngcortes has quit [Ping timeout: 480 seconds]
djbw has joined #dri-devel
<anholt_>
looks like d3d12 would really like a "try insert, return error on duplicate" behavior to avoid search and then insert on fail.
<anholt_>
(not uncommon!)
tzimmermann has quit [Quit: Leaving]
<jenatali>
Yeah
<jenatali>
I think also embedding data in the nodes would help
<jenatali>
Which C++ templates let you do
illwieckz has quit [Read error: Connection reset by peer]
ngcortes has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<anholt_>
yeah, fair.
abc has quit [Remote host closed the connection]
<anholt_>
though that would often extend the already nasty scope of lifetime management issues with the ht.
illwieckz has joined #dri-devel
mbrost has joined #dri-devel
<jenatali>
Yep. I think at least for this one we might actually use the STL container... Not sure
oneforall2 has quit [Remote host closed the connection]
agd5f_ has quit []
kzd has quit [Quit: kzd]
<jenatali>
anholt_: Re: skipping flushes (!21344) - were you trying to say we shouldn't apply that workaround?
agd5f has joined #dri-devel
kzd has joined #dri-devel
gouchi has quit [Remote host closed the connection]
konstantin has joined #dri-devel
kzd has quit [Quit: kzd]
kzd has joined #dri-devel
konstantin_ has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
kzd has quit [Quit: kzd]
kzd has joined #dri-devel
junaid_ has quit [Ping timeout: 480 seconds]
junaid has quit [Ping timeout: 480 seconds]
Zopolis4 has quit []
Duke` has quit [Ping timeout: 480 seconds]
oneforall2 has joined #dri-devel
<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.
<jenatali>
Yep, fair
<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
<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
foxrider has joined #dri-devel
foxrider has quit []
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
bgs has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]