00:23karolherbst: it makes no sense
00:24karolherbst: imirkin: https://gist.github.com/karolherbst/534bb0d7f71acc3e19ce28b2db89dc37
00:26imirkin: probably worth double-checking the decoding
00:26imirkin: in nvdisasm
00:30karolherbst: the heck
00:30imirkin: the CAS encoding is a bit funky
00:30imirkin: it takes those 2 params as one encoded reg
00:30imirkin: where it has to be N+1
00:30imirkin: or something
00:30imirkin: that's why it just gets a 2-wide arg in nv50 ir
00:31imirkin: or maybe both regs are taken, but they have to be sequential or else? dunno
00:31imirkin: but it does seem like we're doing that
00:31karolherbst: I guess we can assume that the 0 write to $r2 helps
00:32karolherbst: but it still makes no sense
00:36karolherbst: probably it's some stupid sched stuff
00:37karolherbst: that's a new
00:37karolherbst: imirkin: I found a combination of opts where it passes with sched enabled but fails with sched disabled
00:43karolherbst: ohh, it's compute, mhhh
00:43karolherbst: need my demmt stuff
00:43karolherbst: too lazy to port it to the new kernel though
00:43karolherbst: driver version
00:48karolherbst: imirkin: if that helps, it's also broken with your 2D/3D stuff reverted
00:52karolherbst: oh no :(
00:52karolherbst: this is an ugly test
00:54karolherbst: the hell
00:54karolherbst: how is that even supposed to work without a loop
00:55karolherbst: imirkin: what are your thoughts? https://gist.githubusercontent.com/karolherbst/4746c89a7e4579528f72dce58b15b518/raw/1f0e0243ae5c9c0aefd1c7737d793c490023ce1f/gistfile1.txt
00:55karolherbst: barrier needed?
00:57karolherbst: although.. how could that help
01:48karolherbst: yeah.. there is some randomness to this issue at least
01:57karolherbst: imirkin: any idea what I could try before going to bed?
01:57karolherbst: ohhh mhh
01:58imirkin: i don't think we do that for SURED*
01:58imirkin: probably should
01:58karolherbst: yeah.. let me try that
01:59imirkin: that cctl thing should always be 'true' btw
01:59imirkin: since SURED can't work on shared memory
02:00imirkin: handleCasExch won't be quite right actually
02:00imirkin: but you get the idea.
02:00imirkin: look at how it adds the cctl, and do that.
02:00imirkin: you don't need the other stuff of the CAS handling
02:00imirkin: that's already handled.
02:01imirkin: and just add the cctl unconditionally (for SUREDB/P)
02:13karolherbst: imirkin: like this? https://gist.githubusercontent.com/karolherbst/08af1d23091c445d2358c7da2dfbf75c/raw/4b5870d57d0bfd9f65e0fe6b1e784e8fb43bdd86/gistfile1.txt
02:13karolherbst: something went wrong here
02:17karolherbst: imirkin: https://gist.githubusercontent.com/karolherbst/08af1d23091c445d2358c7da2dfbf75c/raw/c89783a7dca86887e00f5ee36d99b5dc848ce70a/gistfile1.txt
02:18karolherbst: ... the args are confusing
02:19karolherbst: ahh yeah.. I messed up :)
02:23karolherbst: Passed: 1/1 (100.0%)
02:24karolherbst: it... ehh
02:24karolherbst: something is just messed up here
02:24karolherbst: I need to take a look tomorrow
02:31imirkin: hmm ... GL_NV_compute_shader_derivatives is only turing+?
02:33imirkin: karolherbst: tsk tsk tsk
02:33imirkin: i'm going to nuke that one
02:33HdkR: Theoretically could be implemented on older archs, just won't be efficient
02:33imirkin: oh, with "manual" derivatives?
02:34imirkin: i.e. run one lane at a time
02:34HdkR: Yea, manually do it
02:34imirkin: like we do in certain cases already
02:34imirkin: which aren't handled by txd
02:35imirkin: but it'd have to be extended to ddx/ddy and textureQueryLod
02:35imirkin: aka "Not Worth It (tm)
02:35HdkR: I presume that card is specifically for CL 2.0 features?
02:35imirkin: it's a GL ext
02:35imirkin: and it's under OpenGL features :)
02:35imirkin: intel implemented the ext
02:36HdkR: ah :)
04:29imirkin: karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4520 -- look ok?
09:21karolherbst: imirkin: yeah.. I just wanted to verify the PIPE_CAP_DRAW_INFO_START_WITH_USER_INDICES cap
09:21karolherbst: will do it today
09:32karolherbst: should be fine, r-b me
10:40RSpliet: imirkin: 76a77bd6 nvc0: enable GL_NV_viewport_array2
10:40RSpliet: nvc0_program.h: /* also applies go gp and tp */
10:40RSpliet: Is that "go" a typo?
11:21RSpliet: Looks like Takashi returned the favour and fixed one of our audio problems :-D
11:22RSpliet: Looks like one of their users is having more trouble with nouveau, but can't find the right place for bug reports against the nouveau kernel module. Should I point him to the mailing list?
11:22karolherbst: RSpliet: huh?
11:22karolherbst: RSpliet: we have this btw: https://gitlab.freedesktop.org/drm/misc/-/issues
11:23karolherbst: some are moving nouveau kernel bugs in there
11:23RSpliet: Do Ben or Lyude use that?
11:23RSpliet: If not, it's pointless for people to report there...
11:24RSpliet: Not as pointless in the ALSA bugzilla, but heck, here we are
11:28karolherbst: not our bug :p
11:36karolherbst: imirkin: mhhh.. I don't think cctl is the way to go here... because we would also need to calculate the proper address based on the coordinations and everything
11:36karolherbst: or I missed something
11:36imirkin: RSpliet: been using go too much ;)
11:37RSpliet: Better than using goto much
11:39karolherbst: ahh.. my uvm stuff dosen't work anymore *sigh*
11:39karolherbst: and it needs patches to valgrind as well :/
11:39karolherbst: this is super annoying
11:46imirkin: RSpliet: btw, mailing list is best, imo
12:30karolherbst: yay.. we pass the GLES2 CTS :)
12:30karolherbst: well.. the mustpass list tests at least
12:32karolherbst: ohhhhh :O
12:32karolherbst: the CTS has the copy image stuff I think broke
12:33karolherbst: GLES3 CTS: Failed: 81/3615 (2.2%)
12:34karolherbst: imirkin: KHR-GLES3.copy_tex_image_conversions.forbidden.texture2d_texture2d
12:35karolherbst: [GL_RGBA4]=>[GL_R8] conversion [src target=GL_TEXTURE_2D, dst target=GL_TEXTURE_2D] supported contrary to GLES3.0 spec.
12:35karolherbst: this is the stuff I tried to fix back then
12:36imirkin: i'll check it out.
12:37karolherbst: mhh "KHR-GLES3.packed_pixels.rectangle.rgba"
12:37karolherbst: this is the other fail
12:37karolherbst: in the 3.0 CTS
12:37karolherbst: packed_pixels stuff
12:37karolherbst: and KHR-GLES3.packed_depth_stencil.blit.depth24_stencil8 + 32f_stencil8 :D
12:37karolherbst: but I though we have this issue with the GL one as well
12:37karolherbst: or thought it was fixed
13:27karolherbst: mhh, the other fails might be the same issue actually
13:27karolherbst: the blits not
13:31karolherbst: ohh, we pass all 3.1 and 3.2 tests though, nice :)
13:31imirkin: i think that means we don't have to pass the 3.0 tests =]
13:31karolherbst: I don't think it means that :p
13:32karolherbst: that stencil stuff is odd though
13:32karolherbst: or it's still broken with GL as well
13:32imirkin: i'll look at that copy_tex_image_conversions thing tonight, assuming i remember
13:33karolherbst: yeah.. although I assume there is no better fix than what I came up with
13:33karolherbst: hopefully I am wrong
13:33imirkin: i've also been making some progress on GS passthrough ... i think i wired up the attribute last night, now need to make things link
13:33imirkin: karolherbst: i think your fix is fine actually
13:33imirkin: the code as it was before was just plain wrong
13:33karolherbst: yeah.. just adds a new format table we have to maintain
13:33imirkin: perhaps it can be implemented in a better way, dunno
13:33imirkin: but the general idea of your impl is correct
13:33karolherbst: that's what I am hoping for
13:34imirkin: i.e. stop looking at TexFormat, and look at internalFormat instead
13:34imirkin: coz TexFormat doesn't reflect the internal format, it reflects the storage format
13:34imirkin: internal format might have been meant to reflect the storage format at some point many moons ago, but given that they require various things that not all hw supports, that's not feasible
13:36karolherbst: those tests showed a memory corruption bug as well
13:36karolherbst: I remember now
13:36imirkin: if only there were a place where you could make notes like that
13:37karolherbst: I think I sumbitted a patch actually for that
13:37imirkin: memory corruption in CTS or mesa?
13:37karolherbst: not sure.. I have a random crash, that's why I remembered there was something
13:37imirkin: fwiw i've been pleasantly surprised at VK-GL-CTS's willingness to take patches from me to fix various things
13:38karolherbst: test pattern: KHR-GLES3.packed_pixels.*rectangle.rgba*
13:39karolherbst: added the tests it affects to the MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/123
13:39karolherbst: soo... the crash
13:41karolherbst: imirkin: well, as long as your patches are correct.. otherwise jut submit their patches alongside their submission :p
13:42karolherbst: your way is less work for them :D
13:42imirkin: stuff like this: https://github.com/KhronosGroup/VK-GL-CTS/pull/189
13:43imirkin: not critical, and nobody-but-me-cares type stuff, i imagine
13:43karolherbst: crash: https://gist.githubusercontent.com/karolherbst/5985bf9b521336eecc3b6d79d239fea7/raw/9a3f468cbed5b962f77586e8e4cf166b997099fc/gistfile1.txt
13:44imirkin: oh boy
13:44karolherbst: transfer is NULL
13:44karolherbst: so *transfer crashes :)
13:44imirkin: that's not ideal.
13:45karolherbst: ohh with libasan it always crashes, nice
13:45karolherbst: heh,.. wait
13:45karolherbst: Mesa: User error: GL_OUT_OF_MEMORY in glTexSubImage
13:45imirkin: that's not a path to success
13:45imirkin: i guess something wrong in st/mesa with things returning null
13:46karolherbst: sometimes that error happens and there is no crash :/ mhh
13:47karolherbst: anyway, we should handle that better
13:47imirkin: good luck =]
13:47karolherbst: ahh crap.. my terminal froze
13:48karolherbst: mhh, stImage->transfer is already NULL.. k, static array
13:48imirkin: pro tip: don't attach to X from a terminal running in that X server. i expect same goes for wayland clients and your compositor.
13:49karolherbst: wayland ;)
13:49imirkin: don't attach with gdb *
13:49karolherbst: ahh yeah
13:49karolherbst: you shouldn't do that :D
13:49karolherbst: but my issue was more like that I have infinite scrollback and sometimes.. it gets full
13:50karolherbst: like.. really full
13:50imirkin: you reach infinity? :)
13:52karolherbst: well.. crashing user sessions *
13:52karolherbst: + huge terminal scrollback cache files are not a good combination
14:03karolherbst: imirkin: https://github.com/karolherbst/mesa/commit/931f502be0daf9561ca61f0c4a187b3ca33c3659
14:03karolherbst: maybe that's a bit too harsh
14:04karolherbst: but.. I think that's fine :)
14:04imirkin: karolherbst: seems right
14:04imirkin: or at least not obviously wrong
14:04karolherbst: ups.. shortcut hell
14:04imirkin: i'd have to look at what st_texture_image_map does to be sure
14:04imirkin: but sounds right
14:04karolherbst: imirkin: yeah.. will post it and see what others thing
14:05karolherbst: the returned pointer is used
14:05imirkin: probably if pipe_transfer_map fails
14:05imirkin: yeah, that needs to be undone
14:05imirkin: (see line 2308 in st_cb_texture.c)
14:05karolherbst: what is weird, that the else -> else case doens't get triggered
14:06karolherbst: the crash is inside that st_texture_image_unmap thing though, mhh
14:06karolherbst: let's dig a bit deeper
14:06imirkin: don't call st_texture_image_unmap
14:06imirkin: call pipe->transfer_unmap
14:07karolherbst: yeah, I know
14:07imirkin: oh, i see what you mean
14:07karolherbst: .. something is fishy here
14:07imirkin: iirc the transfers are stored in some shared thing
14:07imirkin: could be threading shenanigans
14:08karolherbst: the CTS is single threaded though
14:08karolherbst: mhh yeah, who knows
14:09karolherbst: now I see the bug :)
14:09karolherbst: yeah.. we just need to guard the call into st_texture_image_unmap
14:11karolherbst: imirkin: https://github.com/karolherbst/mesa/commit/e6608890671e12aff147a92caff3875e856ac8bc
14:11karolherbst: stImage.transfer is the NULL pointer
14:12karolherbst: and that gets accessed in unmap
14:12karolherbst: but checking the return value feels more natural
14:14karolherbst: looks to be broken since forever
14:14imirkin: i mean, if texDest is null, going into that if/else is not good
14:15karolherbst: is't guarded against that, no?
14:15karolherbst: the if then body mhh
14:15karolherbst: yeah.. that's broken as well
14:16karolherbst: mhhh.. yeah.. actually, my first patch was better.. just missing the unmap
14:16karolherbst: and while at it, we can also check map :D
14:20karolherbst: imirkin: anything missing? https://github.com/karolherbst/mesa/commit/b812e2b345be35039ca8dea437e728596ada33ee
14:21imirkin: looks reasonable
14:21imirkin: but again, i'm not looking SUPER carefully
14:21karolherbst: yeah.. hopefully others will look as well
14:21karolherbst: it looks like an issue which could hit every driver :)
14:42karolherbst: fincs: what I am wondering about is, if there are any extensions devs would like to use in terms of increasing perf or so
14:42karolherbst: that would be nice knowledge
14:42fincs: Most of the users we get are just porting existing stuff
14:43karolherbst: yeah.. but they also have "if (ext_available) ..." code
14:43karolherbst: just wondering..
14:43karolherbst: also, CPU profiling would be helpful
14:43fincs: Heh, I don't think most people who are porting stuff are that experienced
14:44fincs: It's a bit sad, really
14:44fincs: It's all about emulators and savegame managers (and warez tools, urgh)
14:45karolherbst: I am also wondering how to support the proper shader cache as well
14:45karolherbst: what's happening right now btw?
14:45fincs: No shader cache at all
14:45karolherbst: mhh :/
14:45fincs: And considering the fact that it's a fragile system I don't think it can be supported in any meaningful way
14:46karolherbst: I don't think it's that fragile.. sometimes GL is just annoying
14:46karolherbst: e.g. catching all variants will be problematic
14:47karolherbst: but starting with a hot cache could help
14:47fincs: There's also the problem of multiple versions of mesa/etc
14:47karolherbst: even if it's only covering 95% of all cariants
14:47karolherbst: yeah well.. if you rebuild your project against an update mesa, the cache needs to be updates as well, sure
14:48fincs: I guess we are going to have a switch-mesa update soon :p
14:49karolherbst: well.. you should wait for the next release or pick up all the fixes as well
14:49fincs: Yes that is what I am waiting for
14:49fincs: Next release (20.1 right?)
14:50fincs: Otherwise I'd say the upgrade work is complete (i.e. rebasing/adjustments)
14:56karolherbst: imirkin: " Failed: 1/7790 (0.0%)" :'(
14:56fincs: However, I've yet to break up some of the changes we've done into smaller (potentially upstreamable?) commits, as well as roll some of the changes I did for UAM back into mesa
14:56karolherbst: that's a random fail
14:57fincs: Hopefully I can get into it by the end of the month
14:57karolherbst: fincs: rebasing on every release and upstream some of the trivial bits should be good enough, no?
14:57fincs: Yeah but I need to actually separate the trivial bits :p
14:57fincs: And port over some of the UAM changes over to actual mesa
14:58fincs: Would it be OK if I made a "for-upstreaming" branch where I'd dump stuff?
14:58karolherbst: it's your git :p
14:59fincs: Sure but I mean, if you or other devs would look at it as a whole or if you'd prefer more piecemeal stuff in separate branches
14:59karolherbst: doesn't matter as long as you don't expect us to check that branch regulary :p
14:59karolherbst: we can submit individual patches
14:59karolherbst: or emrge them
14:59fincs: I can format-patch too if needed
14:59karolherbst: but usually it's easier to do submission per work
15:00fincs: Mkay, I'll take that into account
15:00fincs: I guess I have plenty of time for making it into 20.1
15:47karolherbst: okay.. so that vertex_attrib is a tfb fail as well
15:47karolherbst: similiar to the gles one
15:48karolherbst: KHR-GL45.packed_pixels.varied_rectangle.r8i probably is related to the crash where sometimes we fail to maip
15:48karolherbst: imirkin: ^^ my findings about randomly failing tests
15:59imirkin: KHR-GL45.vertex_attrib_binding.advanced-iterations passes for me
16:05karolherbst: it's a randoml failing test
16:05karolherbst: does tfb stuff
16:07imirkin: not for me
16:07karolherbst: I am not sure if it fails if you only run this one test though
16:07imirkin: i mean, i believe you, but if it doesn't fail for me, hard to debug
16:07imirkin: i ran the whole group
16:08karolherbst: yeah, passes for me as well
16:08karolherbst: I ran the full mustpass file
16:08imirkin: can you put up the TestResults.qpa snippet for the failure somewhere?
16:08imirkin: or is it just the ever-helpful "test has failed, have a nice day" message?
16:09karolherbst: it was more helpful then tat
16:09karolherbst: found 9 instead of 10... something
16:09imirkin: that's a start
16:09karolherbst: sounded like the gles fails
16:09karolherbst: so I was thinking we might want to fix those first and see if that helps
16:09imirkin: what were the gles fails?
16:09imirkin: (the non-copy image ones)
16:10karolherbst: dEQP-GLES3.functional.transform_feedback.random.separate.lines.6 eg
16:10karolherbst: the pause resume ones
16:11karolherbst: that test also fails randomly
16:11karolherbst: but also if you run it alone
16:19imirkin: ok, if i run random.* it fails
16:19imirkin: randomly, might i add
16:19imirkin: but just one at a time, yeah, works
16:19imirkin: that will require ... analysis
16:19imirkin: but at least i can repro
16:20imirkin: subsequent random.* runs all pass
16:20karolherbst: maybe I am more lucky here, because my GPU runtime suspends and VRAM gets cleared
16:21karolherbst: I'll check out that mapping issue btw.. something is up there for sure
16:23karolherbst: meh :/
16:23karolherbst: if I call st_texture_image_map after it failed inside gdb, it succeeds
16:34karolherbst: bo_new returning ENOENT
16:35karolherbst: ahh.. and now 0
16:38karolherbst: kernel bug
16:38karolherbst: if I retry abi16_bo_init without suspending it succeeds on the second attempt
16:38karolherbst: without runitme suspending I mean
16:38karolherbst: I thought that might change stuff ...
16:41imirkin: ok, but like ... st_cb_texture.c should still be fixed
16:41imirkin: it'd be good if the map call didn't fail
16:41karolherbst: sure :)
16:41imirkin: but given that it does, it shouldn't fall over either
16:41karolherbst: but I think this one is resonsible for our CTS run fails
16:42karolherbst: did you ever ran the full thing and got an error besdies out of mem?
16:42karolherbst: because I think it was always this one
16:42imirkin: i never got out of mem
16:42imirkin: i just got a PTE error of some kind
16:42karolherbst: might be the same bug...
16:42imirkin: always in the same spot
16:42imirkin: but i could never repro without running the _full_ suite
16:42imirkin: i tried running like the 100 preceding tests
16:43karolherbst: anyway, I am quite happy that I am able to trigger this map failing quite reliably
16:43karolherbst: 27 GLES tests.. fails around in 20% of all runs
16:47karolherbst: nice :) I can actually unload nouveau while gdb is running
16:47karolherbst: never actually tried that
16:48karolherbst: drm_gem_handle_create fails mhhh
17:14pmoreau: Hey karolherbst, did you had the opportunity to run the cl_khr_il_program series on the CTS?
17:15pmoreau: I just got it working, and a few tests do pas, but some other fail in spirv_to_nir.
17:16karolherbst: pmoreau: I didn't, no
17:16karolherbst: but yeah..
17:16karolherbst: I wouldn't focus on the fails because...
17:16karolherbst: we still fail a lot of random CL stuff
17:16pmoreau: Okay, no worries.
17:17pmoreau: Well, the basic linkage test crashes, soooo
17:17pmoreau: I would hope that something like linkage_import_function_link does succeed, even if we do not support everything.
17:18pmoreau: I’ll dig into it since I still have a few days off, and org domains properly resolve again.
17:33karolherbst: classic.. the closer I get the less common the fail is
17:34pmoreau: Oops, apparently we never check that spirv_to_nir does not return a NULL pointer, before dereferencing it.
17:34karolherbst: yeah well :D
17:34imirkin: karolherbst: it's the heisenbug principle
17:34pmoreau: Translate fast, crash fast!
17:34karolherbst: pmoreau: check on my clover
17:35karolherbst: check on my clover_support_hmm_wip branch
17:35karolherbst: I have quite a lot of stuff there
17:35karolherbst: maybe something like this as well
17:35karolherbst: nouveau_vma_map returns that error
17:35karolherbst: I think I am quite close now
17:37pmoreau: You do not: https://gitlab.freedesktop.org/karolherbst/mesa/-/blob/clover_support_hmm_wip/src/gallium/state_trackers/clover/nir/invocation.cpp#L91-95
17:37karolherbst: well, then I don't :p
17:37pmoreau: What do you have on that branch? Do I need to rebase the cl_khr_il_program series on top of it? I guess I definitely do for my NV50 OpenCL patch, right?
17:38karolherbst: I arrived at nvif_object_mthd.. am I now allowed to quit?
17:38karolherbst:just assumes it reaches nvkm_uvmm_mthd_map after a while
17:38imirkin: you know there's a trace thing which prints all this shit
17:40karolherbst: oh well.. but yeah, it hits nvkm_uvmm_mthd_map :)
17:43karolherbst: nice.. nvkm_umem_search returns ENOENT :)
18:10karolherbst: ohh well. at this point it's one for skeggsb :)
18:17imirkin: karolherbst: please check that caps thing today
18:17imirkin: or i'll just push
18:18karolherbst: push then, worst case I find regressions a week later :p