07:32 <icecream95> alyssa: I'm having trouble finding the calls to set_sampler_views using the features implemented in "Fix set_sampler_views for big GL". Was there any point in that commit?

13:07 <alyssa> was just trying to implement the gallium api...

13:08 <alyssa> apparently mesa/st doesn't use it. cursed.

13:09 <alyssa> nor does any other st? why is this in the gallium api?

13:09 <alyssa> at any rate, that sounds like a #dri-devel question

14:49 <jekstrand> I thought set_sampler_views was for texture views in GL

21:47 <icecream95> panfrost_instance_id seems to be broken for a vertex count of 1...

21:48 <alyssa> icecream95: midgard only, wontfix? ;-p

21:59 <icecream95> alyssa: "will look again when I'm slightly more awake". Have you been sleeping for the past two weeks?

22:00 <icecream95> (!16343)

22:00 <alyssa> probably

22:01 <alyssa> first patches there are r-b

22:01 <icecream95> I'm a bit concerned, if you can't tell whether you are awake or not

22:04 <icecream95> first how many? all except for the stencil tracking?

22:04 <alyssa> first 3, i mean

22:04 <alyssa> in patch 4:

22:04 <alyssa> + } else if (batch->clear & PIPE_CLEAR_STENCIL) {

22:04 <alyssa> + z_rsrc->constant_stencil = true;

22:04 <alyssa> I think you need to also set z_rsc->stencil_value = batch->clear_stencil?

22:05 <alyssa> I can't tell if that has a behaviour effect, but if you don't, the documented invariant of stencil_value is broken

22:05 <alyssa> ("The stencil value if constant_stencil is set")

22:05 <icecream95> Nothing changes stencil_value, I see what you mean

22:06 <icecream95> You must be awake now then?

22:06 <alyssa> Apparently so :-)

22:06 <alyssa> after spending a week feeling stupid trying to understand aco's RA, everything else feels so much easier ;-p

22:07 <icecream95> But I suspect that no-one would ever complain even if that bug was not fixed

22:07 <alyssa> which bug?

22:07 <alyssa> the one I just complained about? :D

22:07 <icecream95> stencil_value

22:08 <icecream95> The assumption is that if you are not using the stencil buffer, it's unlikely that you care if it is 0 or 255

22:08 <alyssa> ah well

22:09 <alyssa> Even if the code works as-is, that the documented invariant is broken means it's liable to break later when something starts to rely on that invariant

22:10 <icecream95> I should probably write some Piglit tests for this. Annoyingly shader_runner does not appear to support stencil buffers

22:10 <alyssa> Actually, the bug seems more severe

22:10 <alyssa> doesn't this break all stencil clears?

22:11 <alyssa> glClearStencil(0xfa); glClear(STENCIL); glStencilMask(enable); glDraw(); glFlush();

22:11 <alyssa> glClearStencil(0xfa); glClear(STENCIL); glStencilMask(enable); glDraw(); glFlush();

22:11 <icecream95> Only stencil clears where the stencil buffer is not used in the same batch

22:11 <alyssa> I'm not so sure?

22:11 <alyssa> oh, right, I see

22:11 <alyssa> glClearStencil(0xfa); glClear(STENCIL); glFlush();

22:12 <alyssa> glClearStencil(0xca); glClear(STENCIL); glStencilMask(enable); glDraw(); glFlush();

22:12 <alyssa> maybe that is the broken sequence?

22:12 <alyssa> first frame has a stencil clear but no stencil draw, so constant_stencil = true

22:13 <alyssa> next frame, constant_stencil is true, so clear_stencil is overriden with z_rsrc->stencil_value, which is zeroed (or maybe uninit)

22:13 <alyssa> so the second frame will clear with 0x00 instead of 0xca

22:16 <alyssa> icecream95: https://rosenzweig.io/hmm

22:16 <alyssa> I think this is what you meant?

22:58 <icecream95> alyssa: For the second bug you pointed out, I'm sure that I carefully ordered things to make it work correctly... I guess I wasn't careful enough then

23:00 <alyssa> Happens to the best \s/

23:01 <icecream95> Both bugs are caught by existing Piglit tests, there is no need to write more

23:01 <alyssa> Woo

23:01 <icecream95> Oh wait the first one isn't

23:10 <alyssa> I should try that MR with Manhattan on Bifrost ... shader-db claims it gets rid of all the spilling in manhattan

23:10 <alyssa> It would help to have arm64/linux builds of gfxbench....

23:12 <icecream95> Use the Windows ARM build? It couldn't be *that* hard to get Panfrost working on Windows, could it?

23:12 <alyssa> it could :p

23:13 <alyssa> In order of most to least reasonable: use an apitrace/renderdoc, use Android, use FEX with a Linux x86 build

23:13 <alyssa> HdkR: Does gfxbench work on FEX yet? ;p

23:15 <icecream95> Even less reasonable: Run Windows in a VM, and pass GPU jobs over TCP to the host to avoid having to write a kernel driver

23:16 <icecream95> Windows supports the BSD sockets API doesn't it? I already have the code written for that

23:21 <icecream95> But adding a glFlush is enough to break one of the Piglit tests

23:21 <alyssa> I should stop coding for the day and eat dinner...

23:29 <alyssa> icecream95: FWIW, I intend to merge a subset of !15874 -- the nodearray patches (which I understand), but not the SIMD patches (which I don't), or the split/adjacent stuff (it seems a lot cleaner to just support vec8 natively..? I realize that goes against your goal to make LCRA wow efficient, but I'd rather use a bit more memory to keep things simpler (and leave open the possibility of hybrid or SSA RA

23:29 <alyssa> someday)

23:30 <alyssa> With the "scalar IR" patches I merged today, vec8 support shouldn't require any changes to e.g. optimization passes.

23:31 <alyssa> (It *will* need dynamically allocated sources for vec8 collects, to avoid raising MAX_SRCS to 8. I was intending to make that change anyway. Hard req for phis, I would add.)

23:34 <alyssa> Took a while for it to click that...

23:34 <alyssa> 1. The interference matrix is necessarily sparse. We'd get O(N) space/time if it was *all* sparse.

23:35 <icecream95> Supporting vec8 in RA would double memory bandwidth used (which seems to be the bottleneck, at least with NEON) unless we accept a much lower cap on node_count or use __attribute__((packed))

23:35 <alyssa> 2. For a sufficiently high threshold, there are O(1) rows of the matrix with more nonzeroes than the threshold, so correctly implemented nodearrays are *also* O(n) space/time.

23:36 <alyssa> 3. hence sparse/dense switching is purely constant factor to all-sparse. I assume you've profiled this, else you wouldn't have bothered implementing it

23:37 <icecream95> "correctly implemented". You mean correct as in theoretically optimal, or as in something which actually performs well enough?

23:37 <alyssa> I mean that it does what it says on the tin and doesn't have some silly bug where everything is dense, or something like that :-p

23:38 <alyssa> #2 is worth commenting on

23:38 <alyssa> erm

23:39 <alyssa> it would be if my brain weren't shutting down right now from lack of food

23:39 <alyssa> I should probably go fix that

23:39 <icecream95> Filling a nodearray randomly is O(n^2) time because insertion has to move a bunch of elements out of the way

23:39 <alyssa> woof, I was just thinking about iteration time for the solve

23:40 <icecream95> Doing O(1) insertion is possible for interference (but not liveness), but it doesn't make it faster by enough to be worth the extra complexity

23:41 <alyssa> Sure