ChanServ changed the topic of #zink to: official development channel for the mesa3d zink driver || https://docs.mesa3d.org/drivers/zink.html
xroumegue has joined #zink
fahien has joined #zink
fahien has quit [Remote host closed the connection]
fahien has joined #zink
airlied has joined #zink
<Soroush> zmike: the block_size calculation in unbreak_bos needs to round up the divide by 16 instead of the current floor.
<Soroush> glsl_get_explicit_size can and will return non-16 byte aligned sizes, so without the roundup I again get the same OOB issues when testing std140 UBOs.
pendingchaos_ is now known as pendingchaos
fahien has quit [Ping timeout: 480 seconds]
<zmike> Soroush: test case?
<Soroush> A lot of cts cases that test UBO/SSBO, but for example take KHR-GL33.shaders.uniform_block.random.scalar_types.2
<Soroush> the spirv it produces will do static OOB for BlockC in the frag shader
<zmike> Soroush: hm so you mean instead of block_size /= sizeof(float) * 4; use block_size = DIV_ROUND_UP(block_size, sizeof(float) * 4);
<Soroush> zmike: exactly, when I tested that, it fixed all those cts cases. conceptually, it makes sense too.
<zmike> okay, well that's simple enough
<zmike> do you want to make a MR?
<Soroush> zmike: I have never made a MR for mesa, is there a page explaining the process?
<Soroush> thanks, I'll create a MR for it later today.
<zmike> tremendous
fahien has joined #zink
<Soroush> zmike: ooh, I don't have permission to create a new MR.
<zmike> is that a thing?
<zmike> cc daniels
<daniels> no
<daniels> well
<daniels> only temporarily
<daniels> if you've forked the repository, you should have access in about 15min
fahien has quit [Quit: fahien]
anholt has joined #zink
omegatron has quit [Quit: What happened? You quit!]
<anholt> zmike: really confused by how the last_val thing for time elapsed queries could do the right thing. you want to sum up the deltas from each (end - begin).
<anholt> but, also, wouldn't the end timestamp have to be written to a different query id or something so that they're not just both reading the same result value?
<zmike> anholt: yeah I was hoping I could repro your scenario for testing
<zmike> but I can't
<zmike> and all the unit tests I have for elapsed time have similar before/after results
<zmike> so I can't really test
<anholt> Have you tried the glretrace --pframes case?
<zmike> yes
<zmike> that's the case I specifically tried
<zmike> I've tried it on every driver on every display server possible
<zmike> and I see nothing like what you see
<zmike> time elapsed probably does need more handling for calculating the results since it wasn't implemented to split across cmdbufs like this
<anholt> coooool. apitrace is defaulting to using GL_TIMESTAMP for its GPU duration query. so zink fixes won't matter because it's just doing the wrong thing all on its own :/
<zmike> ah good, that's at least one small mystery
<anholt> so let's say your gpu's been on for some days, and your timer is not disjoint. Then you multiply your big old u64 timestamp by (float)timestampPeriod.
<anholt> suddenly, your timestamp only increments every few frames, but when it does it catches up.
<zmike> ah
<zmike> well my gpu has been on for many days, so that checks out
<zmike> anholt: is overall fps not sufficient for your benchmarking? or are you looking for frame timings for something specific
<anholt> zmike: the traces CI uses time elapsed of last replayed frame in the loop, to try to isolate "how fast is rendering" as opposed to "how long does it take us to start up, and also run some frames?"
<anholt> and that does seem like a good thing to be able to measure and compare.
<zmike> I see
<anholt> I can crank up --loops to try to limit the effect of startup time, but since I was hoping to chew through comparing a lot of traces, not having judgement per trace would be nice.
<ajax> woefully incomplete but basically correct i think
<zmike> hmmm
<zmike> it sounds correct
<zmike> and I can ack it
<zmike> but probably you're going to want a Real Opinion
<ajax> we'll see how CI likes it i suppose. but i'm pretty sure i'd be happy with it for 22.next
<ajax> well. happier. lot of other gunk you can clean up around there but.
<zmike> if you run the glx glob in piglit with zink I imagine you'd see immediate changes
<ajax> yes, but i'm lazy and it's changing code that hits dri3 too
<ajax> may as well get some coverage
<zmike> ci will run it for you anyway
<ajax> aw yiss, two xpasses in llvmpipe
<ajax> and all over the place in dri3 too
<ajax> victory lap