01:40 <alyssa> mifritscher is right, we just need to remarket T820 as a hardware RNG

02:14 <anarsoul> :)

02:14 <alyssa> anarsoul: Oh, no, I haven't done gl_FragDepth yet

02:14 <alyssa> Isn't that ES3...?

02:38 <anarsoul> yes

02:38 <anarsoul> or ES2 extension

03:28 <narmstrong> seems quite en expensive RNG

07:29 <urjaman> openscad throws a segfault (and this later part is my understanding from reading the backtrace and source) trying to read the result of an Occlusion query

07:33 <urjaman> points at line 2533 of pan_context.c ... the transfer.cpu address is not a null (and doesnt immediately look bad to me, 0xa89da080) but gdb confirms to me that that is not accessible :/

11:53 <alyssa> urjaman: That's quite likely

11:53 <alyssa> occlusion queries are not uh

11:53 <alyssa> very tested

11:59 <urjaman> yeah i've been trying to figure out what the correct logic would be for this, but the piece of memory for the query is allocated with panfrost_allocate_transient, which to me seems ... maybe not optimal?

11:59 <alyssa> Oh

11:59 <alyssa> Yes that is

11:59 <alyssa> probably wrong :p

12:00 <urjaman> i mean atleast i cant immediately find another example of it being used for GPU->CPU, only for CPU->GPU stuff

12:00 <alyssa> Yeah

12:00 <alyssa> Hey uh

12:00 <alyssa> urjaman: Replace that allocate transient with allocating a BO

12:01 <alyssa> panfrost_bo_create(screen, size, flags)

12:01 <alyssa> Er

12:02 <alyssa> panfrost_batch_create_bo actually

12:02 <alyssa> that way it gets bound appropriately methinks....?

12:02 <urjaman> okay i'll look that up and try to do it (after i get food tho, so i'll be back)

12:03 <alyssa> foood

12:19 <alyssa> Okay, I need to stop putting off tableizing load/store

12:21 <alyssa> Oh that was easier than I expected ;p

12:37 <urjaman> tableizing? o.O

12:54 <alyssa> You know

12:54 <alyssa> putting it in a table

12:54 <alyssa> Tedious, but it will come in handy

12:55 <robmur01> as distinct from tabling, which is to put *on* a table :P

13:05 <urjaman> i'm not quite sure the batch_create_bo is right for this

13:06 <urjaman> my first attempt came up with a segfault with the cpu pointer being 0 and the bo reference having a count of 0

13:08 <urjaman> i'm more thinking allocate on either create (or begin, but even that sounds like lazy allocation right as it is needed) of the query, and get rid of it when the query is destroyed

13:10 <urjaman> (or read the value and "get rid of it" (the bo cache will help with this :P) on the query end, and just present the value on the get result

14:39 <narmstrong> ok I nailed a skips file for t820, but it's pretty brutal

14:39 <narmstrong> https://gitlab.freedesktop.org/narmstrong/mesa/blob/ab2b5d541799d933fb63f53ca29d2278b9545219/.gitlab-ci/deqp-panfrost-t820-skips.txt

14:43 <urjaman> alyssa: https://urja.dev/query_fix_test.patch this one avoids the occlusion query segfaulting

14:44 <urjaman> i'm still not sure if it's working correctly, especially as openscad doesnt render properly, but it could also be something else

14:49 <urjaman> found the first bug in my solution :P

14:55 <urjaman> btw alyssa, specifically in the use-case of the start and end values for the computed queries, overflow doesnt matter

14:55 <urjaman> unsigned overflow is defined, and the result = end - start will always work, so it's a bit funny how they're 64-bit to avoid overflow

15:01 <urjaman> https://urja.dev/openscad_llvmpipe.png https://urja.dev/openscad_panfrost.png

15:02 <urjaman> ^ there's a little reference to see how it misrenders (the inside of the cut cube disappears, and the axis lines on the negative side are not dotted for some reason...)

15:04 <urjaman> re: the cube-minus-cube: i just wrote some random code until i could see it misbehaving (my actual project disappears entirely for some reason)