00:44 karolherbst: imirkin: if you are bored, there are lik hundreds of failing gles3 tests :)
00:45 karolherbst: well.. more like 1k
00:45 imirkin: make a list.
00:45 imirkin: pastebin it
00:46 karolherbst: I will put it in the trello card once I am done
00:46 imirkin: ok
01:22 imirkin: karolherbst: btw, i'm going to push NV_viewport_array2 stuff tonight unless you have objections
01:22 fincs: ( ͡° ͜ʖ ͡°)
01:24 fincs: Btw, you won't believe this, but I was asked today by a Switch emulator dev about some weird shader code, and it turns out we found a game that uses shader interlock
01:24 fincs: So much for "nothing uses it" lol
01:25 imirkin: ooo well
01:35 HdkR: fincs: Which game uses it? :)
01:35 fincs: Super Mario Party
01:35 HdkR: pfft, ffs
01:36 HdkR: Have fun implementing that hot garbage :P
01:36 fincs: Not me though :p
01:37 imirkin: well, if it's just like "add a function to your library, call it for this glsl intrinsic", it's actually pretty easy to implement
01:37 fincs: That's exactly what it is
01:38 fincs: But good luck doing it in reverse
01:38 imirkin: not my prob
01:38 imirkin: give me the library functions
01:38 imirkin: i'll hook it up in nouveau
01:38 fincs: Probably copyrighted code/etc :p
01:38 imirkin: oh
01:38 imirkin: hrmph
01:38 imirkin: yeah, good call
01:38 imirkin: too used to open-source
01:38 HdkR: ooo, interlock in Nouveau would help an emulator I know of that's using it for OIT though :P
01:39 imirkin: HdkR: get the code published
01:39 imirkin: no one uses nouveau anyway
01:39 fincs: The code itself is pretty boring and disgusting though
01:40 fincs: Lots of warp ticket shit
01:40 imirkin: not terribly surprising.
01:41 imirkin: if you can write up a textual description of what it does, i could try to reimplement
01:41 fincs: Someone else did iirc, need to remember who it was
01:41 imirkin: don't care who, just need the text =]
01:41 fincs: I mean in order to ask them :p
01:41 fincs: (Also I need to figure out myself how it works)
01:41 fincs: Also I know the reg that specifies the fragment interlock layout
01:42 HdkR: imirkin: Sadly I haven't worked at that company for over a year now :)
01:43 imirkin: HdkR: ah ok. i haven't kept track :)
01:43 fincs: Oh, that's a shame
10:37 karolherbst: ahhh
10:37 karolherbst: trello become shit
10:48 karolherbst: ahh, most of the tests are recent regressions, nice
11:04 karolherbst: imirkin: you broke tests with enabling viewport_swizzle :/
11:05 karolherbst: bunch of stencil ones
11:05 karolherbst: dEQP-GLES2.functional.fragment_ops.depth_stencil.stencil_ops.*
11:05 karolherbst: probably more
11:08 karolherbst: ahh yeah.. something is broken
11:08 karolherbst: (gdb) p vp->swizzle_y
11:08 karolherbst: $4 = PIPE_VIEWPORT_SWIZZLE_POSITIVE_Z
11:08 karolherbst: (gdb) p vp->swizzle_z
11:08 karolherbst: $5 = PIPE_VIEWPORT_SWIZZLE_POSITIVE_Y
11:08 karolherbst: I'd expect those values to be swapped :p
11:09 karolherbst: ehh
11:09 karolherbst: (gdb) p vp->swizzle_w
11:09 karolherbst: $6 = PIPE_VIEWPORT_SWIZZLE_NEGATIVE_X
11:21 karolherbst: imirkin: the swizzle never gets set actually :/
11:21 RSpliet: <enum name="VIEWPORT_SWIZZLE_POSITIVE_W_NV" value="0x9358"/>
11:21 RSpliet: Should be 0x9356
11:22 karolherbst: also true
11:22 karolherbst: but not the bug I think :p
11:23 karolherbst: but it did affect the values though
11:23 karolherbst: but yeah
11:23 karolherbst: it just looks like random values
11:24 karolherbst: let me add this fancy address sanitizer to be sure
11:27 karolherbst: ehh
11:27 karolherbst: those are definetly random, but.
11:27 karolherbst: still written to
11:27 karolherbst: or at least libasan doens't catch those
11:30 karolherbst: ahhh
11:30 karolherbst: imirkin: cso_set_viewport_dims
11:32 karolherbst: will post an MR soon
11:32 karolherbst: RSpliet: with your fix included except you want to show as the author :p
11:34 RSpliet: I mean, I am applying for jobs right now... Nah, just add a Reported-by or sth
11:34 karolherbst: wow
11:34 karolherbst: that fixes 696 regressions :)
11:34 karolherbst: Passed: 696/719 (96.8%)
11:43 karolherbst: imirkin: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4567
11:43 karolherbst: RSpliet: yeah.. now I forgot the reported by :D will add it
11:44 RSpliet: Thanks, appreciate it
11:44 karolherbst: done
11:44 karolherbst: bugs like those are annoiny to track down though :/
11:47 karolherbst: nice
11:47 karolherbst: runpm fixes autoselected for 5.6,5.5 and 5.4 :)
11:48 karolherbst: hoped the gp gr init one would autosel as well :/
11:50 RSpliet: My laptop is hoping that the snd-hda-intel runpm fixes will get pulled for 5.7 and earlier :-P Not too keen on regularly rolling my own kernel rpms again
11:51 karolherbst: uff.. I am rolling my own kernel out for a year or so :D
11:51 karolherbst: 5 months actually
11:52 karolherbst: ahh probably picked due to the bugzilla tag
11:52 karolherbst: mhhh
12:04 karolherbst: ahh, much better now: Failed: 23/17346 (0.1%) :)
12:28 karolherbst: the heck :/
12:40 karolherbst: imirkin: also
12:40 karolherbst: https://github.com/karolherbst/mesa/commit/198a024f068ab1ca9ceb04c67efc8b08cc111c3c
12:41 karolherbst: nvidia even writes both values
12:41 karolherbst: removed the curly braces: https://github.com/karolherbst/mesa/commit/3a6c6efa2dccf84d6868693fac6fb2e30b517a71
12:56 karolherbst: with that: Failed: 7/17346 (0.0%)
12:56 karolherbst: mhhh
14:39 karolherbst: ehh
14:39 karolherbst: nvidia sets POLYGON_OFFSET_FACTOR inside mme
14:39 karolherbst: :/
14:40 fincs: Heh, not in nvn though
14:40 imirkin: karolherbst: oops =]
14:41 karolherbst: imirkin: yeah.. stuff like this is tricky to catch :p
14:41 karolherbst: only testing helps :D
14:42 imirkin: anyways, R-b: me
14:42 imirkin: feel free to push
14:42 karolherbst: right now I look into that dEQP-GLES2.functional.polygon_offset.default_factor_1_slope fail
14:42 imirkin: that stuff's annoying.
14:42 karolherbst: https://trello.com/c/nF2PqeE8/36-deqp-326-gles-20
14:42 karolherbst: most is already fixed locally
14:42 karolherbst: just the polygon_offset and the first two
14:42 karolherbst: but those are mesa bugs
14:42 imirkin: https://github.com/karolherbst/mesa/commit/3a6c6efa2dccf84d6868693fac6fb2e30b517a71
14:42 imirkin: uhhh
14:42 karolherbst: yeah....
14:43 imirkin: well, i didn't add that class_3d >= GM200_3D_CLASS for _no_ reason
14:43 karolherbst: I know
14:43 karolherbst: but this commit causes no regression
14:43 karolherbst: fun fact
14:43 karolherbst: nvidia sets both
14:43 imirkin: yeah
14:43 imirkin: perhaps with GM200 it's non-deterministic which it uses?
14:43 imirkin: dunno
14:44 imirkin: or look at the commit where i did it, perhaps i said why
14:46 karolherbst: ahh, good idea
14:47 karolherbst: actually
14:47 karolherbst: it wasn't you
14:47 karolherbst: https://cgit.freedesktop.org/mesa/mesa/commit/?id=a0e57432b76c
14:47 karolherbst: uhhh
14:48 karolherbst: let's check that piglit test then
14:48 imirkin: pendingchaos: --^
14:48 pendingchaos:doesn't remember much
14:48 imirkin: wise.
14:48 karolherbst: heh
14:49 karolherbst: spec@!opengl 1.1@polygon-offset broken here
14:49 karolherbst: spec@!opengl firstname.lastname@example.org works
14:49 karolherbst: yeah..
14:50 karolherbst: my commit fixes the 1.1 one
14:50 fincs: For reference, NVN sets both line width registers to the same thing
14:50 karolherbst: and 1.4 passes still
14:50 karolherbst: fincs: yep.. I already traced nvidia :p
14:50 fincs: :)
14:50 karolherbst: probably because gm20x is broken or so
14:50 imirkin: fincs: such waste.
14:50 fincs: Who knows
14:50 imirkin: a whole extra register being set
14:50 fincs: But just to be safe, nouveau should too
14:50 imirkin: how can you suffer such a huge perf impact...
14:50 karolherbst: :D
14:50 imirkin: think of all the fps you're losing
14:50 karolherbst: ey.. I could check that on gm20b actually
14:51 karolherbst: let's see
14:51 imirkin: pendingchaos: were you testing on GM20x or GP10x?
14:51 karolherbst: uhh. don't want to build piglit there
14:51 pendingchaos: I don't remember
14:51 karolherbst: pendingchaos: do you remember which GPU you had?
14:51 imirkin: hehe
14:51 karolherbst: 9XX soemthing or 10XX something :p
14:52 pendingchaos: before the 1060, I had a 970
14:52 karolherbst: yeah well..
14:52 karolherbst: k
14:53 karolherbst: do you know _when_ you got the 1060?
14:57 pendingchaos: seems around october 2018
14:58 karolherbst: okay.. that would be way after the patch
14:58 karolherbst: so probably tested on gm206 then
14:59 pendingchaos: actually I was looking at the wrong email and it was probably december 2016
14:59 karolherbst: :/
14:59 karolherbst: you are sending mixed signals, I don't like this :D
14:59 karolherbst: hah
15:00 karolherbst: there was no 1060 in 2016 :p
15:00 karolherbst: ohh wait
15:00 karolherbst: there were :O
15:00 karolherbst: july 2016 actually
15:00 pendingchaos: seems the test only failed on GM20x: https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=nouveau&date=2018-04-20
15:01 karolherbst: mhhh
15:01 karolherbst: interesting
15:01 karolherbst: I actually have a proper gm206 here as well
15:01 karolherbst: I could do some traces there
15:13 karolherbst: " NotSupported (polygon offset tests require depth buffer)" on gm20b :(
15:15 karolherbst: ohh.. ehh
15:15 karolherbst: I wanted to chec line_width
15:47 imirkin: karolherbst: were you going to look at the piglit tests? or should i just push?
15:47 karolherbst: imirkin: which MR?
15:48 imirkin: https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/253
15:48 imirkin: https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/254
15:48 karolherbst: imirkin: I meant, the mesa MR, but I guess you meant the fix for the regressions?
15:49 imirkin: these are piglit tests for the NV_viewport_* exts
15:50 karolherbst: well, looks fine, but I also didn't read the spec.. sp
15:52 imirkin: ok, i'm just going to push
15:53 imirkin: karolherbst: btw, that runpm fail fix is insufficient right, also needs the on/off thing?
15:53 karolherbst: imirkin: not everywhere
15:53 karolherbst: but yeah.. the on/off thing should be backported as well
15:54 karolherbst: really only affects a few gp107 and gp108 chips
15:54 imirkin: which are, unfortunately, very popular
15:54 imirkin: in laptops
15:55 karolherbst: I know
15:56 karolherbst: heh.. uff
15:56 karolherbst: I need https://github.com/karolherbst/mesa/commit/3a6c6efa2dccf84d6868693fac6fb2e30b517a71 on gm20b as well...
15:57 imirkin: probably the change is bogus, but reflecting of another issue
15:57 imirkin: reflective
15:57 imirkin: or it's for pascal
15:57 imirkin: dunno
15:57 karolherbst: dunno
15:57 imirkin: can't check now
15:57 karolherbst: I should check on my gm204 as well
17:14 karolherbst: imirkin: well.. I can confirm that pendingchaos original patch broke it for me on gp107.. so I would assume that this was something special to gm20x now
17:15 imirkin: karolherbst: even the specific test he was talking about?
17:15 karolherbst: especially that one, yes
17:15 imirkin: ok
18:22 karolherbst: imirkin: gm204: https://gist.githubusercontent.com/karolherbst/3e18aa027960c1fce1c4ab6de2740f35/raw/8630caf52b208f357ce9d72f0ea7f8a9e78b7bb0/gistfile1.txt
18:23 karolherbst: didn't switch over to nouveau yet though
18:43 karolherbst: crap... that laptop doesn't boot anymore...
18:43 karolherbst: crappy plymouth
19:01 karolherbst: heh, nice.. now I figured out why on boot I don't get an IPv4
19:01 karolherbst: something starts up the network before NetworkManager even launches
19:11 karolherbst: imirkin: ehh.. that test fails on mesa 20.0.4 on a gm204 as well...
19:14 imirkin: heh
19:14 karolherbst: yeah...
19:14 karolherbst: I check that commit which was supposed to fix it :)
19:16 karolherbst: imirkin: uhm... guess what
19:17 imirkin: there's more to it?
19:17 karolherbst: either that or pendingchaos made a mistake
19:17 karolherbst: pendingchaos' commit broke it on my gm204
19:17 imirkin: ok, well let's just revert then
19:18 karolherbst: let me read thourgh the logs a bit first though.. maybe there is something we missed
19:19 karolherbst: my current explanation would be, something in piglit changed
19:19 imirkin: or alternatively he had his GPU in a weird state, or other local patches which altered the situation
19:19 imirkin: iirc he was working on conservative raster
19:19 imirkin: and sample positions
19:22 karolherbst: imirkin: https://github.com/pendingchaos/mesa/commits/nv-line-width-fix-v2
19:22 karolherbst: mhhh
19:22 karolherbst: doesn't look like it
19:23 karolherbst: assuming it was tested based on that
19:23 imirkin: yea dunno
19:23 karolherbst: dunno either
19:24 karolherbst: moved to piglit 032830f2f121515648f5f60bfd1a48eeee4d5958
19:24 karolherbst: but with my commit it passes there as well
19:26 karolherbst: :O
19:26 karolherbst: okay...
19:26 karolherbst: so.. this is weird
19:26 karolherbst: it used to work
19:26 karolherbst: I have an year old piglit run where that test was passing
19:27 karolherbst: while testing this MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/412
19:28 karolherbst: let me try to get to a state where this is the case
19:30 karolherbst: it used to work in november.. huh
19:35 karolherbst: ohh
19:35 karolherbst: that's intel
19:35 karolherbst: okay...
19:35 karolherbst: the other one is nv137 for real..
19:42 karolherbst: imirkin: do you think anything in the kernel could affect this?
19:45 karolherbst: this is super weird...
19:51 HdkR: karolherbst: Good job on getting SVM merged
19:51 karolherbst: yeah, finally :D
19:53 karolherbst: ahh, there is another article
19:53 karolherbst: *sigh* :D
19:53 HdkR: You got caught in the news :P
19:54 karolherbst: still
19:54 karolherbst: the nouveau patches aren't pretty
19:55 karolherbst: especially this one: https://github.com/karolherbst/mesa/commit/f79ab5beb91bfcdf5af88c933d861ac7d36627fb
19:55 karolherbst: because.. it doesn't work
19:55 karolherbst: well for compute it does
19:55 HdkR: ooo pinned_memory
19:55 karolherbst: yep
19:55 karolherbst: you need this with SVM
19:55 karolherbst: well
19:55 karolherbst: system SVM actually
19:55 HdkR: Are you saying that you broke Dolphin since it uses pinned_memory? :P
19:55 karolherbst: HdkR: imagune you create a CL buffer with USE_HOST_PTR
19:56 karolherbst: and now.. because you are stupid you pass in the SVM pointer backing this buffer _and_ the buffer into the same kernel
19:56 karolherbst: imagine the fun
19:56 HdkR: Of course, super fun
19:57 karolherbst: well, if you don't support the RESOURCE_FROM_USER_MEMORY cap, clover does copies of the buffers and stuff
19:57 karolherbst: so nothing of this works
19:57 karolherbst: had to track down a couple of those bugs
19:57 HdkR: ah
19:57 karolherbst: ended up with requiring PIPE_CAP_RESOURCE_FROM_USER_MEMORY :D
19:57 karolherbst: yeah..
19:57 karolherbst: it's painful
19:58 karolherbst: should talk with skeggsb again to provide a proper kernel API for graphics as well
19:59 HdkR: What's the SVM function that has an ARM suffix?
19:59 karolherbst: that's SVM backported from 2.0 to 1.2
19:59 karolherbst: soo.. it doesn't have the migration stuff
20:00 HdkR: huh
20:00 karolherbst: HdkR: https://www.khronos.org/registry/OpenCL/extensions/arm/cl_arm_shared_virtual_memory.txt
20:01 HdkR: and it's deprecated. I guess once they started supporting 2.0 in their driver?
20:01 karolherbst: well, yeah
20:01 karolherbst: still comes in handy for clover :p
20:02 HdkR: Yea, lets you expose the extension early
20:02 HdkR: Still quite a bit to go for 2.0 I guess?
20:02 karolherbst: yes
20:02 karolherbst: biggest thing is generic pointers I guess
20:02 karolherbst: and maybe some API features
20:02 karolherbst: would like to implement images first though
20:03 HdkR: Images sound reasonable, would end up looking like compute images
20:03 karolherbst: yes and no
20:03 karolherbst: it's really closer to normal GL textures
20:03 karolherbst: just.. different
20:03 HdkR: Does CL add the derivative support?
20:04 karolherbst: dunno
20:04 karolherbst: I have some WIP patches actually
20:04 HdkR: I guess, does it have filtering on images?
20:04 karolherbst: HdkR: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/bae441aea5584e50e7c37076ad37ddfb56bd58e9
20:05 karolherbst: HdkR: yeah... it does
20:05 HdkR: woo compute derivatives then :P
20:05 karolherbst: sampler_t is weird in CL
20:05 airlied: HdkR: we can go straight to 3.0 :_
20:05 karolherbst: it's a bitfield
20:05 airlied: :-P
20:05 karolherbst: :D
20:05 airlied: gl 2.x is an evolutionary dead end
20:06 airlied: cl 2.x
20:06 karolherbst: airlied: actually.. how is the version stuff checking out?
20:06 HdkR: hah
20:06 karolherbst: I mean, what if an application checks for 2.1 or so
20:06 airlied: karolherbst: I assume apps will have to target CL3.0 explicitly
20:07 karolherbst: probably...
20:07 karolherbst: but there is no CL API for "is this at least 3.0" or is there?
20:07 HdkR: I guess CL 3.0 will be the "oops, we hecked up" and rolls back some "features"?
20:07 airlied:would have to read the spec again, and that means logging into places
20:07 karolherbst: :D
20:07 HdkR: :D
20:08 airlied: HdkR: though since this channel is public, I cannot confrim or deny opencl 3.0 exists
20:08 HdkR: CL 3.0 doesn't exist, There is only 2.2 :)
20:09 airlied: but if a theoretical cl 3.0 happened, we could jump straight to it once we get 1.2 done :-P
20:09 airlied: so let's write printf already
20:09 karolherbst: please no
20:09 karolherbst: :D
20:09 fincs: Can we retcon gl 4.6 spirv shit too please? Doesn't seem like there's much point in it
20:09 karolherbst: fincs: actually there is
20:09 karolherbst: better than compiling glsl, isn't it?
20:09 fincs: Pfft
20:10 fincs: Still needs the entire translation and compilation shebang
20:10 HdkR: printf is pretty straightforward with SSBOs, atomics, and a ringbuffer though. Just make sure only threadid 0 is the one that touches it :P
20:10 karolherbst: fincs: yeah, but that's just 15% of the CPU cycles spent on
20:10 karolherbst: :p
20:10 fincs: And who will use it?
20:10 karolherbst: well.. it's more but string parsing is super expensive
20:10 fincs: Especially when GL is already declared to be a dead end
20:10 airlied: HdkR: what happens if I want to printf something from threadid 5 :-P
20:11 karolherbst: fincs: it's useful for embedded devices
20:11 fincs: Still needs to support GLSL
20:11 karolherbst: cutting of the lexer and parser helps a lot
20:11 HdkR: airlied: printf_idx :D
20:11 fincs: Plus, I thought "embedded devices" were GLES and/or Vulkan?
20:11 fincs: Not desktop GL?
20:11 airlied: fincs: I suspect gl4.6 is the last hurrah anyways
20:12 fincs: And I think NV doesn't support GL 4.6 last time I checked
20:12 karolherbst: does dolphin supports spirv with gl already?
20:12 karolherbst: fincs: they do
20:12 karolherbst: for a long time
20:12 HdkR: karolherbst: Not yet. I think D3D is the blocker for it
20:13 fincs: I've always seen them report 4.5?
20:13 karolherbst: fincs: they report 4.6 here
20:13 karolherbst: and I doubt it's pascal+ only
20:13 HdkR: Last I checked it was GL 4.5 core, GL 4.6 Compat
20:13 karolherbst: :D
20:13 HdkR: But that may have changed
20:13 fincs: Lmao relegated to compatibility profile
20:14 karolherbst: it's there since 382 or so
20:14 fincs: Still, I really don't see the point of spirv in desktop GL
20:14 fincs: Especially when Vulkan exists
20:14 karolherbst: fincs, HdkR: https://gist.githubusercontent.com/karolherbst/c03f9478d9dc81fa524ac3fd25ef3ba9/raw/ca240c58985f319b10e9c57a5eca1f5c8cce865c/gistfile1.txt
20:14 karolherbst: so... there it is 4.6
20:15 HdkR: Nice
20:15 karolherbst: it's there for a while now, but I won't test older versions :p
20:15 HdkR: So in a year it changed at some point :)
20:16 fincs: It must have changed recently, because I remember distinctively "lol NV didn't bother with 4.6"
20:16 karolherbst: nope
20:16 karolherbst: it's there for a long time already
20:16 karolherbst: windows officially supports it since april 2018
20:16 karolherbst: nvidia on widnows
20:16 fincs: That's strange
20:16 fincs: Because the timeframe in which I started messing around was late 2018
20:17 HdkR: ¯\_(ツ)_/¯
20:17 HdkR: It's here now so eh
20:22 karolherbst: I just hope there is no hand written spir-v already :/
20:24 karolherbst: imirkin: so.. I am out of ideas.. I will post the fix
20:37 imirkin: k
20:37 karolherbst: any ideas about those polygon_offset fails btw?
20:37 imirkin: yeah, they're very confusing.
20:37 imirkin: ;)
20:37 imirkin: i dunno, i'll have a look later
20:38 imirkin: esp if there's some kind of note somewhere about what fails
20:38 karolherbst: not really.. just rendering is slightly off
20:38 imirkin: i mean like a list of tests
20:38 karolherbst: ohhh.. wait
20:38 karolherbst: I think I see it
20:39 karolherbst: we never set POLYGON_OFFSET_FILL_ENABLE
20:39 karolherbst: but nvidia does
20:39 imirkin: uh what?
20:39 imirkin: for lines shouldn't matter
20:39 karolherbst: https://gist.githubusercontent.com/karolherbst/26e986f677b7bf552893091a303d820b/raw/25848f4c80d9073bd665f775e95c6c4090294b78/gistfile1.txt
20:40 imirkin: we should be setting it...
20:40 karolherbst: ohh.. different file
20:40 karolherbst: mhh
20:40 karolherbst: ahh
20:40 karolherbst: 0
20:40 karolherbst: :D
20:40 karolherbst: in the blitcts setup
20:41 karolherbst: we don't use it anywhere else
20:41 karolherbst: so I'd assume that's it then
20:41 imirkin: SB_BEGIN_3D(so, POLYGON_OFFSET_POINT_ENABLE, 3);
20:41 imirkin: SB_DATA (so, cso->offset_point);
20:41 imirkin: SB_DATA (so, cso->offset_line);
20:41 imirkin: SB_DATA (so, cso->offset_tri);
20:42 imirkin: in the rast cso
20:42 karolherbst: ohhh
20:42 imirkin: yeah, not intuitively obvious that it covers all 3, but ... it does
20:42 imirkin: certainly not greppable :)
20:42 karolherbst: I see
20:42 karolherbst: yeah..
20:42 imirkin: in a perfect world, those would be SB_IMMED or something for higher greppability
20:42 imirkin: but what are you gonna do
20:47 karolherbst: I know what :)
20:47 karolherbst: I just parse our pushbufs :p
20:47 karolherbst: "unknown mode 3" *sigh*
20:47 karolherbst: NVC0_FIFO_PKHDR_NI
20:47 karolherbst: mhh
20:48 karolherbst: ahh
20:48 karolherbst: that's the same method multiple times
20:49 karolherbst: https://gist.githubusercontent.com/karolherbst/d3fd7eef859092908664ee5b9869be80/raw/4f6aa349395dd6294175b024ab8b34944f347157/gistfile1.txt
20:49 karolherbst: " GP104_3D.POLYGON_OFFSET_FILL_ENABLE = TRUE" :)
20:59 karolherbst: ohhh
20:59 karolherbst: the first draw is fine...
20:59 karolherbst: the second is which causes issues
21:05 karolherbst: nope.. the first draw is already broken
21:05 karolherbst: mhh
21:08 karolherbst: anyway, here the MR for the line width stuff: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4575
21:09 imirkin: karolherbst: r-b: me
21:13 karolherbst: imirkin: what worries me the most is that nvidia actually executes a macro for that polygon stuff
21:13 karolherbst: :/
21:14 karolherbst: or maybe just uses a macro to set those values.. dunno
21:17 karolherbst: imirkin: GP104_3D.COLOR_MASK_COMMON = FALSE vs TRUE
21:17 karolherbst: could that cause issues here?
21:18 imirkin: that's just the independent blend stuff
21:20 karolherbst: you say that, but " Passed: 1/1 (100.0%)"
21:20 karolherbst: that's what nvidia ends up doing: https://gist.githubusercontent.com/karolherbst/077ce95bbb9951ddb46961faee8bc8ae/raw/72009e60013f32ecda513e508f9c1d5b850d085f/gistfile1.txt
21:21 karolherbst: if I do the same, the test passes...
21:21 karolherbst: but.. hell
21:21 karolherbst: no idea :D
21:22 karolherbst: ohh, I see
21:22 karolherbst: mhhh
21:23 karolherbst: okay.. I messed up, it fails again when I set the same mask as nvidia
22:24 karolherbst: ehh
22:24 karolherbst: dEQP-GLES3.functional.transform_feedback.random.separate.lines.6 doesn't fail if the system is under heavy load :/
22:25 imirkin: could be we're not waiting for something
22:26 imirkin: depends what the test does
22:26 karolherbst: yeah.. I guess so
22:26 imirkin: e.g. if it's doing pause/resume
22:26 imirkin: or draw tf stuff
22:26 imirkin: annoyingly the first half of the tesla series doesn't support this "advanced" TF stuff
22:26 imirkin: so pretty much all TF tests fail
22:26 karolherbst: :(
22:27 imirkin: at least the GTF ones
22:27 imirkin: coz they mix it up
22:27 imirkin: or CTS ... or something. i forget.
22:27 imirkin: anyways, i was annoyed :)
22:27 karolherbst: ohh heh.. we might want to run the undefined sanatizer a bit more often :D
22:27 imirkin: technically we shouldn't expose GLES3 on there
22:28 imirkin: but it seems silly to drop such a big GLES rev for a stupid thing like that
22:28 karolherbst: yeah..
22:31 imirkin: i wish there were usage stats out there
22:31 imirkin: like "feature X on gpu Y"
22:32 imirkin: like ... who would ever use pause/resume in the first place? and even worse -- DrawTransformFeedback - when is that ever useful except in contrived demos that show off the feature
22:32 imirkin: i know it's like the poor man's compute, but come on
22:33 karolherbst: imirkin: https://gist.github.com/karolherbst/192d0b2a31af5b78b280faa943d3716e
22:33 karolherbst: that looks familiar...
22:33 imirkin: yeah, on fermi, before we were setting that TFB_UNFUCKUP_OFFSET_QUERIES thing
22:34 imirkin: i'd have to look at what it's doing
22:34 imirkin: it's not obvious from that log
22:34 karolherbst: tfb is like the only thing broken additionally.. besides some msaa stuff
22:35 imirkin: but yeah, all those tests fail on g84
22:35 karolherbst: mhh, and some texture stuff
22:35 karolherbst: "dEQP-GLES3.functional.shaders.texture_functions.textureoffset.sampler3d_fixed_fragment" ehhh
22:35 imirkin: coz they start with regular TF stuff, and then continue to the pause/resume bits
22:35 imirkin: this is on a maxwell/pascal board, right?
22:35 karolherbst: yes
22:36 imirkin: fails on both GP107 and G84
22:36 karolherbst: heh
22:40 karolherbst: mhh.. that texture stuff looks more interesting and less annoying to fix :D
22:42 imirkin: ok
22:43 imirkin: a long time ago we had layout issues with 3d textures
22:43 imirkin: and texelFetch would fail with various random things
22:43 imirkin: but i fixed those ages ago
22:43 imirkin: (basically once the third dimension would get minified to 1, it assumed all further levels were 2d. which didn't work well.)
22:44 imirkin: texture offsets should be fairly straightforward.
22:49 karolherbst: imirkin: mhh, doesn't sound like the case here
22:49 karolherbst: shader does stuff like this: o_color = vec4(textureOffset(u_sampler, v_texCoord, ivec3(7, 3, -8)))*u_scale + u_bias;
22:50 karolherbst: or do you mean if that happens on one level, all the others are screwed up .. yeah maybe that's the case here.. let me see
22:51 imirkin: i mean - texture layout shoudl work now
22:51 imirkin: i was just mentioning it
22:51 karolherbst: ahhh
22:51 karolherbst: okay
22:51 imirkin: does it pass with llvmpipe?
22:52 karolherbst: ahh eh.. it fails with iris
22:53 karolherbst: passes with swrast though
22:53 karolherbst: had llvm disabled for silly reasons.. let's see
22:55 karolherbst: imirkin: passes with llvmpipe
22:55 imirkin: if it fails with iris, i don't feel so bad
22:55 karolherbst: yeah...
22:55 imirkin: that means there's something funny there
22:55 karolherbst: well
22:55 karolherbst: if it passes with llvmpipe?
22:57 karolherbst: ahh eh
22:57 karolherbst: okay.. now I don't feel bad
22:58 karolherbst: fails with nvidia as well
23:15 karolherbst: imirkin: the GL CTS should be fine on maxwell, right?
23:15 karolherbst: I might run it over the weekend then
23:15 karolherbst: well.. as long as nothing broke in the meantime :)
23:33 imirkin: karolherbst: other than the fact that it dies half-way through, yes, totally fine
23:34 imirkin: all the tests, individually, pass
23:38 karolherbst: mhhh
23:38 karolherbst: okay
23:38 imirkin: dunno if it's specific to my setup in some way
23:38 karolherbst: I expect some hard to track memory leak.. but yeah
23:38 imirkin: maybe it was with GK208? i forget.
23:38 karolherbst: I saw the same here on gp107
23:39 karolherbst: and other gpus
23:39 imirkin: anyway, i'm moderately sure that all CTS pass at least individually
23:39 karolherbst: okay
23:39 imirkin: as well as GTF
23:39 karolherbst: will probably do a mustpass list today
23:39 karolherbst: ahh
23:39 karolherbst: yeah. I should probably get the gtf stuff working as well
23:39 imirkin: (after all my various fixes, which you should have as well)
23:40 karolherbst: the gles stuff looks fine now as well.. just some errors others have as well except the tfb and msaa bits
23:40 imirkin: note that the VK-GL-CTS branch with the gl 4.6 tag is missing the GLX hookup, so nothing works
23:40 karolherbst: ahh anbd polygon_offset
23:40 imirkin: you have to run it with EGL, or use my patch to make GLX work
23:40 karolherbst: I am on wayland anyway
23:40 imirkin: (which in mainline VK-GL-CTS but not on that branch)
23:40 karolherbst: 4K laptop and 23" extern FHD display are no good match if you use X :)
23:40 imirkin: hehe ok
23:41 karolherbst: per display DPI scaling is really nice :)
23:41 imirkin: i have 2 identical monitors, so that problem doesn't come up :)
23:41 karolherbst: yeah..
23:42 karolherbst: ohh, I wanted to implement the robustness bits now that we have interfaces for detecing dead channels
23:42 imirkin: i did the no-op hookup
23:42 karolherbst: yeah
23:42 imirkin: which was enough to get CTS to pass
23:42 karolherbst: and we also have a bit for that synced submission stuff
23:43 karolherbst: I want to hook that up as well :)
23:51 karolherbst: huh dEQP-GLES31.functional.image_load_store.2d.atomic.comp_swap_r32ui_return_value
23:51 karolherbst: why does this tail
23:52 imirkin: missing cctrl?
23:52 imirkin: cctl
23:52 HdkR: oo cas
23:52 imirkin: i mean it shouldn't
23:52 karolherbst: I thought I fixed something there...
23:53 imirkin: passes for me
23:53 imirkin: yeah, we've had patches float around
23:53 imirkin: that just give up and always start issuing cctl's after any atomic shit
23:53 karolherbst: imirkin: on kepler?
23:53 imirkin: everywhere
23:53 karolherbst: I meant, where did you test
23:53 imirkin: GP107
23:53 imirkin: er
23:53 imirkin: GP108
23:53 karolherbst: heh
23:54 airlied: running those full cts-runner's run is some sorta pain
23:55 karolherbst: heh
23:55 karolherbst: imirkin: NV50_PROG_OPTIMIZE=0 fixes it :(
23:57 imirkin: probably makes enough move in the middle
23:57 imirkin: to make it all work out
23:57 karolherbst: doubtful
23:57 karolherbst: there are already enough movs
23:58 imirkin: MAOR!
23:58 karolherbst: well.. there are 6 before each sustp
23:58 karolherbst: and some before suredb
23:58 karolherbst: mhhh
23:58 karolherbst: let's see