00:02 airlied: fw/hw combo, mostly designed around userspace command submission
00:18 bnieuwenhuizen: wait, does nvk have userspace submission?
00:19 airlied: nope
00:20 airlied: just saying what the gpu does
00:25 bnieuwenhuizen: fabric clocks might be improved though?
00:25 bnieuwenhuizen: wrong chat bleh :(
02:00 airlied: zmike: zink_set_color_write_enables: Assertion `!disable_color_writes || !ctx->clears_enabled' failed.
02:00 zmike: well then stop doing that
02:01 zmike: maybe I'll redo that thing after my current boondoggle
02:03 airlied: like I can figure out if I can implement EXT_color_write_enable, but zink should probably not die if I don't have it
02:03 airlied: but some rasterizer discard + prim gen stuff going on
02:04 zmike: I don't know that it's been tested at any point in the last century without it
02:05 zmike: really this is the thing where it's supposed to bind a null fs instead of using cwe to avoid potential obscure fs side effects but I haven't had the time to make that happen
02:07 airlied: https://paste.centos.org/view/raw/9e8b2093 "fixes" it
02:08 zmike: hm
02:10 zmike: I think I'm too deep into my couch to assess the effects of that
02:11 airlied: yeah it's not too urgent, it's probably not a path anyone cares about a lot
02:11 zmike: but I think doing that will run into other issues since nvk is going to be in the !track_renderpasses bucket
02:12 zmike: maybe deleting cwe will fix it
02:12 zmike: we'll see
02:14 karolherbst: mupuf: yeah.. soo.. recovery isn't the most stable thing atm :D
02:15 karolherbst: I _think_ there is a race on the kernel side if too many recoveries are happening at the same time, but I didn't find the time to really dig into this as this sounds like one of those issues you look at it for months before finding the problem
09:52 mupuf: airlied, karolherbst: FYI, it seems like it really only hangs at the beginning or not at all
09:52 mupuf: so... concurrency issue when bringing up command submission?
09:53 mupuf: https://gitlab.freedesktop.org/eric/mesa/-/jobs/46893749 <-- running the full vkcts now
09:53 mupuf: should take ~1.5h... not too bad!
10:28 karolherbst: mupuf: mhhh.. maybe context initialization is messed up then? dunno
10:29 mupuf: so far, it looks like it crashes every other time
10:29 mupuf: I have had issues like this on amdgpu too: polaris10 would crash when X would start
10:30 mupuf: but if it started... then all would be fine
10:32 karolherbst: yeah.. dunno, never seen that behavior on ampere
10:38 mupuf: Still going strong: Pass: 221910, Fail: 8092, Crash: 13, Warn: 3, Skip: 907928, Timeout: 7, Flake: 547, Duration: 47:31, Remaining: 32:18
11:05 mupuf: karolherbst: well, it did crash :D https://pastebin.com/raw/hBWe8uCw
11:06 karolherbst: yeah...
11:06 karolherbst: anyway, I think there are some memory bugs lurking in the driver
11:07 karolherbst: maybe a kasan run would even be feasible here... would be interesting at least
11:07 karolherbst: but might also be some threading problem and those are more annoying to track down
11:12 mupuf: agreed, should build a kernel with all the sanitizers
11:13 mupuf: karolherbst: who would be best to contact for these issues?
11:14 karolherbst: uhm... good question. Somebody with spare time and willingness willing to investigate those?
11:14 karolherbst: *willingness
11:19 mupuf: karolherbst: who maintains nouveau.ko nowadays?
11:19 karolherbst: Ben, me and Lyude, depending on how much time everybody has
11:20 karolherbst: Ben is mostly focusing on GSP bring up though
11:20 karolherbst: and Lyude is mostly busy with other things, mostly
11:46 mupuf: karolherbst: I see
11:46 mupuf: Well, I don't want to be a drag on the development, like airlied said
11:47 mupuf: maybe we should first get the big reworks done before trying to stabilize
11:47 karolherbst: yeah, that's the current plan
11:47 karolherbst: once GSP is in we Ben will have more time for other things as well
11:47 mupuf: GSP is indeed a massive change
11:48 mupuf: Poor Ben, always doing god's work :D
11:48 karolherbst: I'm mostly focusing on fixing bugs the most users are hitting, and channel recovery messing up is sadly not the most urgent issue to fix here :')
11:50 karolherbst: anyway.. we need more people on the driver :D
17:20 karolherbst: gfxstrand: so.. for global mem initializers I'm not quite sure if I want `spirv_to_nir` to call wiht a NULL entry point or add a special one `SPIRV_NIR_ENTRYPOINT_INITIALIZER` (or add fields for iniitalizers/finalizers to `spirv_to_nir_options`) to indicate I want to only extract global mem iniitializers. My current plan is to emit those initializers _only_ for initialiazer kernels so nir passes don't start assuming contents of variables (
17:20 karolherbst: e.g. constant folding or other fun bits). Any thoughts/remarks?
18:04 jenatali: karolherbst: Are you differentiating between constant initializes vs constructors?
18:04 karolherbst: I don't yet
18:04 jenatali: I'd expect to extract constant initializer data as just data, and constructors as a different entrypoint
18:04 karolherbst: initializer/finalizer kernels are really really poorly spced (not at all) so I have no idea what to assume here
18:04 jenatali: No need to run a shader to initialize globals when you can just upload data
18:05 karolherbst: yeah.. atm I just pull the initializer
18:05 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24515
18:05 karolherbst: uhmm..
18:05 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24515/diffs?commit_id=2b71cf705d0e1aafe8ddff653ca6396567cca654#9a64d7388f55cb0ac2ab2d2a3ae2ce75aae2f3fc_380_380
18:05 jenatali: I definitely saw specs for them
18:06 karolherbst: interestingly, it all just worked using nir_lower_vars_to_explicit_types + nir_gather_explicit_io_initializers
18:06 karolherbst: I just added some safeguards, like droping nir_variable initializers for entry point kernels
18:06 karolherbst: jenatali: really? I couldn't find anything
18:06 jenatali: Initializers run before the first kernel of a program (I'd handle this like I handle memory migration between devices) and finalizes run sometime before destruction
18:07 jenatali: Might be in a SPIR-V spec or in the API spec instead of the language spec
18:07 karolherbst: ohh, yeah, I didn't mean those details
18:07 karolherbst: I meant more like , can you have multiple?
18:07 karolherbst: in what order to they run?
18:07 jenatali: Oh, no you can't
18:07 karolherbst: well
18:07 karolherbst: where is that stated?
18:07 jenatali: A program can have at most one of each I thought
18:08 jenatali:shrugs
18:08 karolherbst: why is it called CL_PROGRAM_SCOPE_GLOBAL_CTORS_PRESENT then?
18:08 karolherbst: ctors
18:08 karolherbst: "This indicates that the program object contains non-trivial constructor(s) that will be executed by runtime before any kernel from the program is executed."
18:08 karolherbst: anyway...
18:08 karolherbst: it's poorly speced
18:09 karolherbst: (and also deprecated)
18:09 jenatali: Oh, ok maybe you can
18:09 karolherbst: yeah, but if you can, what's the proper order to execute them in?
18:09 karolherbst: can they have data dependencies between each other?
18:10 karolherbst: I kinda wished something would tell me the answers to those questions
18:10 karolherbst: maybe I simply bring it up on the next CL WG meeting
18:11 jenatali: karolherbst: considering they come from C++, I'd assume they follow the same rules as C++, order is indeterminate
18:11 karolherbst: anyway.. my plan is to only support global constant initializers and reject any spirv having initializer/finalizer kernels until that's all figured out
18:12 karolherbst: mhhh
18:12 karolherbst: sounds fishy, but okay :D
18:12 karolherbst: anyway.. if we want to support it, spirv_to_nir should just generate an entry point calling into all of those in some order when we either set a special entry_point or use spirv_to_nir_option flags for that
18:13 karolherbst: and then the nir_shader also has a function body, where now it doesn't
18:13 karolherbst: (or when no such ctor/dtor exists)
18:14 jenatali: Sounds good
18:15 karolherbst: I'm mostly just unsure if I preder special entry point constants or adding flags to spirv_to_nir_option instead
18:59 tnt: Anyone know if there is an IRC or ml or whatever resources for the intel-compute-stack thing ?
19:26 karolherbst: github I think
19:26 karolherbst: is the only thing
19:28 karolherbst: tnt: might make sense to ask in #intel-gfx
19:42 tnt: karolherbst: thanks, will give that a shot.