10:50 pmoreau: karolherbst: Rebased on the latest master, and added back the tags Rb and Ab tags.
10:58 pmoreau: karolherbst: Also, do you think we could get the IL MR (https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2078) in before 20 is branched out?
10:59 karolherbst: maybe, I can try to take a look, but I am quite busy until fosdem
11:00 pmoreau: Okay, no worries
11:01 pmoreau: I think you did look at most patches already. Would be good if curro could look at the series as well.
11:29 karolherbst: hopefully marge doesn't fail this time :D
11:30 pmoreau: Let’s hope so
11:32 karolherbst: \o/
11:33 pmoreau: \o/
11:33 pmoreau: Thanks!
11:36 karolherbst: I am wondering if we want to have a table for the extensions as well
11:36 karolherbst: still wondering what the most efficient way of function lookup is
11:37 karolherbst: pmoreau: did you test your IL stuff against the CTS btw?
11:38 pmoreau: I haven’t
11:38 karolherbst: if not I may wire it up in my runner script and see how well that works
11:38 pmoreau: Let me push the rebased version then, so that you can easily grab it.
11:39 karolherbst: pmoreau: and maybe we also want to implement the constant specialzation stuff as well :)
11:39 karolherbst: shouldn't be too hard
11:39 pmoreau: Oh yeah, we probably want that!
11:42 pmoreau: Added to the Trello board
11:45 karolherbst: I will try to focus on the structurizer now.. that will be painful though
11:45 karolherbst: you don't know any good papers on that topic btw?
11:45 karolherbst: or you RSpliet maybe?
11:45 pmoreau: I don’t think so; I think I had some paper about it, probably pointed out by Roy. Let me see if I can find them again.
11:48 pmoreau: I also need to add the linking flags to SPIRV-Tools at some point, cause those flags are probably required by the spec.
11:48 karolherbst: mhhh, probably
11:48 pmoreau: I rebased the IL branch to the latest master.
12:42 pmoreau: Oh, I also still need to update the dependencies thing. --"
16:17 RSpliet: triggered
16:17 RSpliet: "structurizer" is not a term I've come across. I don't know what that means in the context of a compiler.
16:18 RSpliet: "for generating structured control flow"
16:18 RSpliet: hmm...
16:18 pmoreau: Turn unstructured control flow into structured control flow, is what Karol means, if that makes more sense.
16:18 RSpliet: Yeah I googled for a bit, that makes sense
16:20 RSpliet: Nah I don't have any recommended reading on that. It sounds useful, but useless in the sense that source languages (GLSL, OpenCL C...) already have structure information encoded.
16:21 RSpliet: Obvs not sure whether SPIR-V does :-)
16:28 karolherbst: RSpliet: they don't
16:28 karolherbst: well, except glsl
16:28 karolherbst: but a C compiler can't generate structured control flow
16:28 karolherbst: same for OpenCL C
16:28 RSpliet: karolherbst: "C" is a structured language. You write if-statements and for-loops. The info is there.
16:28 karolherbst: nope, it's not
16:29 karolherbst: it has gotos
16:29 RSpliet: That does not invalidate the if-statements and for-loops.
16:29 karolherbst: it das invalidate the statement that C is a structured language
16:29 karolherbst: one counter example is enough and so on ;) you know the drill
16:30 karolherbst: anyway, llvm doesn't give us a structured control flow either
16:30 karolherbst: and with OpenCL 2.1 you have to consume unstructured spir-v as well
16:31 RSpliet: karolherbst: http://www.equestionanswers.com/c/c-structured-programming-language.php
16:31 imirkin_: RSpliet: structurizing is getting code into a *specific* structure
16:31 imirkin_: not just any structure
16:31 imirkin_: one that has "normalized" control flow
16:32 imirkin_: i.e. the CFG looks a certain way
16:32 imirkin_: no cross edges, iirc?
16:32 karolherbst: yeah, no cross edges
16:32 karolherbst: essentially you have to be able to generate how nir looks like ;)
16:32 karolherbst: *something that looks like nir
16:32 karolherbst: mhh, I guess you can have switches still
16:34 karolherbst: RSpliet: anyway, you can't say that a C program has structured control flow, as you can always have one with goto. And for certain compiler opts you actually either want analyzer passes to have the information where loops/ifs are or you are sane and structurize the control flow first
16:35 karolherbst: sadly... there doesn't seem to be much interest in that topic before GPU was a big thing as for CPUs it really doesn't matter all that much
16:35 karolherbst: mhh, the intel NEO stack has a structurizer as well
16:35 karolherbst: https://github.com/intel/intel-graphics-compiler/blob/master/visa/CFGStructurizer.cpp
16:36 karolherbst: but.. "// [TODO] algo description" ;)
16:36 imirkin_: / TOOD: add comments
16:36 imirkin_: heh
16:39 karolherbst: heh, the intel devs did the same mistake I was doing: in place structuring
16:39 karolherbst: that's super painful
16:41 karolherbst: I could ignore cross edges for now... would make everything super trivial :/
19:17 pmoreau: karolherbst: I had forgotten, but the specialisation thing was actually only added in OpenCL 2.2. It’s no reason to not have it, but it’s not needed for 2.1 support. :-)
19:18 karolherbst: yeah.. but it should be fairly trivial to add
19:18 karolherbst: we don't have to merge the full MR at once
19:18 pmoreau: Sure
19:19 pmoreau: Does anyone know where the initializer and finalizer are used in OpenCL 2.2? (See https://www.khronos.org/registry/OpenCL/specs/2.2/html/OpenCL_Env.html#required-capabilities-1.1)
19:20 karolherbst: uffff
19:20 karolherbst: I think that's spirv only
19:24 karolherbst: pmoreau: maybe that was added for static C++ objects or so
19:24 karolherbst: as if you init a c++ object on the stack there can be some code involved with that
19:24 pmoreau: Good idea
19:24 pmoreau: Let me see if I can dig it up in the spec somewhere
19:29 pmoreau: They are used for https://www.khronos.org/registry/OpenCL/specs/2.2/html/OpenCL_API.html#CL_PROGRAM_SCOPE_GLOBAL_CTORS_PRESENT and https://www.khronos.org/registry/OpenCL/specs/2.2/html/OpenCL_API.html#CL_PROGRAM_SCOPE_GLOBAL_DTORS_PRESENT I guess
19:31 karolherbst: ehh, no, you still only write your C++ code ;)
19:31 karolherbst: that's clGetProgramInfo output
19:31 karolherbst: but if you have non trivial ctors/dtors, you should return it that your compiler wasn't able to optimize those away :p
19:34 karolherbst: pmoreau: I think this should be mentioned somewhere in the OpenCL++ spec
19:36 pmoreau: “constructor(s) that will be executed by runtime before any kernel from the program is executed.” sounds exactly like the kind of code that would be tagged with the `Initializer` execution mode.
19:36 karolherbst: yes, but you wanted to figure out on how to use it, no?
19:36 karolherbst: or what code to write to get that
19:37 karolherbst: this is just the API for "does this kernel has init/fini functions?"
19:37 pmoreau: More like when it was used, cause I couldn’t find any direct references to it.
19:37 karolherbst: yeah.. I am sure it's just OpenCL C++ ctors/dtors
19:38 pmoreau: I reported https://github.com/KhronosGroup/OpenCL-Docs/issues/190 and we are wondering what to do when Initializer and Finalizer are used in a pre-OpenCL 2.2 world.
19:43 karolherbst: pmoreau: ehh.. CL 2.1 only mandates spir-v 1.0, right?
19:43 pmoreau: Yes
19:43 karolherbst: I guess we can only expose support for 1.0 then
19:43 karolherbst: this is a 1.1 feature, right?
19:43 pmoreau: It is
19:43 karolherbst: well, then it's obvious, no?
19:44 pmoreau: Except that an implementation could expose CL 2.1 and SPIR-V 1.0, 1.1, 1.2.
19:44 karolherbst: sure
19:44 karolherbst: but then it has to support all spir-v 1.1 and 1.2 features :p
19:45 pmoreau: Right
19:46 pmoreau: But in the OpenCL SPIR-V Environment Specification, what should be said about those execution modes. Currently the spec is claiming those are capabilities, not execution modes, which is why I reported a bug.
19:47 pmoreau: Does using Initializer in OpenCL 2.0 makes sense? Should the module be considered valid or not?
19:50 karolherbst: well, that gets fixed though
19:50 karolherbst: well, it doesn't matter what OpenCL says
19:50 karolherbst: if you get a spir-v with an init/fini entry point
19:51 karolherbst: you have to execute those around the called entry point
19:51 karolherbst: which... is trivial to support
19:51 karolherbst: we already support it... nearly
19:51 karolherbst: pmoreau: check vtn_emit_kernel_entry_point_wrapper
19:51 karolherbst: just needs some smaller adjustements
19:52 pmoreau: This is not around entry points, but rather before the first entry point in a program is called, and right before the program is destroyed.
19:52 karolherbst: yeah, that's called around entry points ;)
19:52 karolherbst: you create a kernel with an entry point
19:52 karolherbst: and in you wrapper you need anyway you call 1. init 2. entry_point 3. fini
19:53 pmoreau: Right, but I thought you meant it would be like 1. init, 2. entry_point_1, 3. fini, 4. init, 5. entry_point_2, 6. fini
19:53 pmoreau: Rather than 1. init, 2. entry_point_1, 3. entry_point_2, 4. fini
19:53 karolherbst: you can't call two entry points
19:53 pmoreau: You can call two kernels
19:54 karolherbst: you can call functions marked being a kernel, but those things are not the same
19:54 pmoreau: s/call/start
19:54 karolherbst: well you have to create new kernel objects for each entry point you want to use
19:54 pmoreau: A kernel is an entry point in your SPIR-V module
19:54 pmoreau: Right
19:55 karolherbst: anyway, you need an entry point wrapper otherwise you can't really handle the spir-v
19:55 karolherbst: and this wrapper just needs some additions
19:55 pmoreau: And according to the spec you get the 2nd behaviour, not the first one, because those ctors/dtors are at the *program* level, not *kernel* level.
19:55 karolherbst: doesn't make any sense
19:56 karolherbst: I mean, you have to compile your program when it's a program
19:56 karolherbst: which is a big mistake OpenCL did
19:56 karolherbst: so now you have those info APIs at that level
19:56 karolherbst: which is stupid
19:56 karolherbst: but at runtime you just wrap your executed kernel
19:57 pmoreau: It makes sense that if you share some global data between two kernels, you don’t have to set up and tear them down between every kernel call.
19:57 karolherbst: okay... and how do you write the code for that?
19:57 karolherbst: although.. mhh
19:57 karolherbst: no, that's not possible :)
19:58 karolherbst: how would you get a valid global memory pointer into the runtime?
19:58 pmoreau: Anyway, OpenCL has a say in what SPIR-V it accepts or not. Similar to Vulkan having restrictions in which SPIR-V it accepts.
19:58 karolherbst: you can't really have static global data, can you?
19:58 pmoreau: Dunno if they changed things with OpenCL C++
19:59 karolherbst: that would be an insane thing to add...
19:59 pmoreau: I haven’t looked at it much (if at all)
19:59 pmoreau: Hum, maybe this “These new types are designed to avoid many programming issues and it is recommended to use them for the static and program scope variables even if it is not required.”
20:00 karolherbst: yeah
20:00 pmoreau: So there is program scope variables, which I guess could be objects with non-trivial ctors/dtors.
20:00 karolherbst: static SomeClass someObj;
20:00 karolherbst: which includes the ctor call
20:01 karolherbst: and if you can't constant fold the ctor call, you need an init function
20:01 karolherbst: same for the dtor
20:01 karolherbst: (and in C++ you get the same)
20:01 karolherbst: it's a nice way to fix race conditions in lazy init of data
20:02 karolherbst: pmoreau: a28ff2229513d68ae39e2ea927d21b327a356348 eg
20:04 pmoreau: :-)
20:04 karolherbst: I even hope gcc constant folds that :D
20:06 pmoreau: Did you had time to wire up the series to the runner, btw?
20:07 karolherbst: not yet