00:00 jenatali: karolherbst: The end result is that there's a single pointer val that's the result of the selection (fmt in your example)
00:00 jenatali: That pointer has to point to either data that was assigned as a kernel arg, or data that's in the shader's constants
00:00 karolherbst: jenatali: but it can be a pointer to in kernel constant stuff
00:00 karolherbst: or pointer to memory the application freed
00:00 karolherbst: it can even be an SVM pointer :p
00:00 karolherbst: not joking
00:01 jekstrand: It has to be resolvable at compile time, whatever that means.
00:01 jenatali: karolherbst: Ooh, good point, I'll need to snapshot the args if I want to be able to pull strings from it
00:01 jekstrand: It would be interesting to throw some of these cases through an actual OpenCL driver and see what happens.
00:01 jenatali: I'm sure it'd fall over, they're not in the CTS
00:01 karolherbst: jenatali: better.. it can be a pointer within a struct :p
00:01 karolherbst: and now think about this with system SVM
00:01 jenatali: karolherbst: I'm blissfully ignoring SVM for now :)
00:01 karolherbst: :p
00:01 jenatali: And probably forever
00:02 jekstrand: Putting my Khronos spec author hat on, I suspect what they intended was "must be a literal string"; they just did a bad job of saying that.
00:02 karolherbst: yeah...
00:02 jenatali: jekstrand: That's how I read it too
00:02 karolherbst: I hope so
00:02 jekstrand: And then they made even worse hash of it when they ported it to SPIR-V
00:02 jenatali: But yeah, it's not just the format string, you can also have %s args
00:02 jekstrand: Those have to be literal strings
00:02 jekstrand: Well, in OpenCL C they do
00:03 jenatali: Right, same requirements as the format string
00:03 jenatali: Just, it's not only 1 string
00:03 jekstrand: I have no idea what the difference is between "literal string" and "resolvable at compile time". They use different words for two things that look like they should be the same.
00:03 jenatali:shrugs
00:04 karolherbst: I say we implement it the sane way and hope nobody complains
00:04 jenatali: I'm thinking, I pass the CTS, and hope to never have an app actually use this god-forsaken feature, so I probably don't care :)
00:04 karolherbst: and if somebody complains, we just say: we are conformant to the CTS :p
00:04 jenatali: Exactly
00:05 airlied: a) hey I can't debug by CL program, b) here have printf c) goto a
00:05 karolherbst: jenatali: so.. if we have the buffer parsing and everything in mesa, that would be fine.. not really looking forward coming up with all of that myself
00:05 jekstrand: For %s they say all of the following are invalid:
00:05 jekstrand: kernel void my_kernel(global char *s, ... )
00:05 jekstrand: {
00:05 jekstrand: printf("%s\n", s);
00:05 jekstrand: constant char *p = "`this is a test string\n`";
00:05 jekstrand: printf("%s\n", p);
00:06 jekstrand: printf("%s\n", &p[3]);
00:06 jekstrand: }
00:06 karolherbst: I'd just prefer that everything is already inside the buffer.. but if the runtime has to provide more data so be it
00:06 karolherbst: jekstrand: fun...
00:06 jekstrand: karolherbst: Those are all *invalid*
00:06 karolherbst: I am wondering why the p case is invalid, but yeah :p
00:06 karolherbst: that makes %s kind of pointless
00:06 karolherbst: unless fmt dan be dynamic :p
00:07 jenatali: karolherbst: You can see the parsing bits here: https://github.com/microsoft/OpenCLOn12/pull/3
00:07 gitbot: microsoft issue (Pull request) 3 in OpenCLOn12 "Hook up printf" [Open]
00:07 jenatali: It's... not exactly pretty, and I'm not super excited to try to get it to meet your high standards to get it into Mesa :P
00:09 jekstrand: jenatali: I don't think our standards are *that* high. :-P
00:09 jekstrand: jenatali: But, also, I 100% repect your desire to leave printf as a pile of ugly hacks and move on.
00:09 jekstrand: I would too
00:09 jenatali: Heh
00:09 jenatali: It's open, you're welcome to copy the good bits and rewrite the bad bits :P
00:10 karolherbst:never planned on seriously implementing printf
00:11 jenatali: karolherbst: Same to be honest. But then it was actually kind of fun
00:11 jenatali: I'm happy it's one less thing we'll need to ask for waivers on for certification
00:11 karolherbst: sure.. but for debugging you could also just modify the kernel and output the stuff you care about :p
00:11 karolherbst: ahh yeah..
00:12 karolherbst: replacing clover by a new CL frontend would have solved this issue as well :p
00:12 karolherbst: at least for me
00:13 jenatali: Solved what?
00:13 karolherbst: thinking about how to share the parsing code :p
00:13 jenatali: Ah
00:14 karolherbst: jenatali: but I have a nice idea on how to get rid of the casts, use an union :p
00:15 jenatali: Yeah, that'd be probably a bit nicer
00:16 karolherbst: ohh.. and I'd probably would like to have doubles and not floats
00:16 karolherbst: mhhh
00:16 jenatali: Yeah, we're not supporting doubles just yet, but all floats get promoted to doubles because of C's rules for calling variadic functions
00:17 karolherbst: jenatali: do you think you could rewrite the printf lowering to use a global memory pointer instead of a ssbo?
00:17 karolherbst: then I'd start thinking about having this pass inside mesa instead
00:17 karolherbst: although.... mhhh
00:18 karolherbst: nope, should be fine
00:18 jenatali: karolherbst: A global memory pointer is an SSBO for us
00:18 karolherbst: jenatali: I know, but you lower global memory pointers anyway
00:18 jenatali: I guess I could just move it to before the lowering for that, yeah
00:18 karolherbst: so I am wondering if it would make a difference at all
00:18 karolherbst: yeah.. because then I could just reuse it
00:18 jenatali: Do you want it to support 32-bit pointers?
00:19 karolherbst: why would it matter?
00:19 jenatali: I was a little less generic by assuming 64-bit in the lowering pass
00:19 karolherbst: ohh. mhhh
00:19 karolherbst: well.. kind of
00:19 karolherbst: we have gpus with only 32 bit pointers
00:19 karolherbst: like older nv ones as well
00:19 karolherbst: and probably over vendors as well
00:19 jenatali: Makes sense
00:19 karolherbst: tesla are 32 bit only eg
00:19 karolherbst: but they can't do GL compute :p
00:19 karolherbst: but OpenCL
00:20 jenatali: When I go to send this upstream I'll plan to rework it to support 32bits, operate on global mem instead of ssbo, and put it in core nir lowering instead of our dxil bits
00:20 karolherbst: jenatali: sounds good
00:23 imirkin_: 32-bit pointers but 40-bit VA space. great match.
00:24 jenatali: How's that work...?
00:24 karolherbst: imirkin_: well.. technically...
00:24 imirkin_: solution: you can have 8 (or 16?) 40-bit base pointers
00:24 karolherbst: 16 I think
00:24 imirkin_: from which you can address 32-bit
00:24 karolherbst: imirkin_: I never looked into how those get configured actually...
00:25 imirkin_: well, also i don't think there were ever tesla GPUs with > 4GB VRAM. so it's all a bit academic.
00:25 imirkin_: karolherbst: just class methods
00:25 karolherbst: do you set the 8 high bit and cut of the rest or what?
00:25 imirkin_: karolherbst: i don't remember if it's just the top 8 or a full 40-bit pointer
00:25 karolherbst: mhhh
00:25 karolherbst: but you have to clean it before passing it into the kernel is what I am worrying about
00:25 karolherbst: so.. is it more of an offset to the base one or...
00:26 karolherbst: jenatali: our global memory access has two levels of indirect.. like const buffers :p
00:26 karolherbst: not sure if both level can by non constants though
00:26 jenatali: Interesting
00:27 karolherbst: at least our backend only supports one indirect and one constant index
00:27 jenatali: For someone who helps build graphics APIs, I often find I know surprisingly little about those kinds of architecture details for a given GPU
00:28 karolherbst: jenatali: yeah.. also you probably don't wnat to know the reason why those GPUs can to OpenCL, but not GL compute :p
00:28 karolherbst: the reason is very stupid
00:28 jenatali: Well now I'm curious
00:28 karolherbst: can't write to images from fragment shaders :p
00:28 karolherbst: and also no ssbos
00:28 karolherbst: in fragment shaders
00:29 karolherbst: so you can't have image_load_store nor ssbo, which are kind of required in GL compute :p
00:29 jenatali: GL compute = fragment shader?
00:29 karolherbst: nope
00:29 karolherbst: compute shaders
00:29 karolherbst: but those extensions require you to support it from fragment shaders
00:29 imirkin_: global memory is only writable from compute shaders
00:30 imirkin_: images just become global memory writes - there's no special facilities to handle this
00:30 jenatali: Ohhh, got it. Yeah D3D lumps compute UAV (SSBO) access with pixel shader access too
00:30 imirkin_: curro wrote the logic for all this, but it wasn't all merged
00:30 imirkin_: this was the first D3D10 GPU, first real "compute" shaders, so it was all a bit new.
00:31 imirkin_: end of 2006 or so, i think
00:33 jenatali: Huh, I wonder if that's D3D11's ComputeShaders_Plus_RawAndStructuredBuffers_Via_Shader_4_x cap
00:34 karolherbst: probably
00:34 karolherbst: and probably not the only nvidia workaround :p
00:35 jenatali: Probably not
00:36 imirkin_: jenatali: D3D11 GPUs had full compute shaders like you'd expect
00:36 imirkin_: these were D3D10 GPUs, and the very first CUDA release
00:36 jenatali: Yeah looks like that lights up compute shaders without pixel shader UAVs on a FL10.x part
00:36 jenatali: imirkin_: D3D11 supports feature level 10, i.e. D3D10 hardware
00:36 imirkin_: ah interesting
00:37 imirkin_: i'm not super-familiar with windows stuff. not sure if nvidia's drivers supported that or if it was for something else.
00:37 jenatali: D3D11 even supports feature level 9 (i.e. D3D9 era GPUs) through a compat layer
00:39 imirkin_: ah, crazy, ok
00:39 imirkin_: i guess i always associated the d3d version with the feature level
00:39 imirkin_: didn't realize they were disconnected
00:40 imirkin_: (other than like d3d10.1)
00:40 jenatali: imirkin_: Yep. We even added feature level 12.0 and 12.1 for D3D11, at the same time we built/released D3D12 (which supports feature levels 11.0 thru 12.2)
05:20 danvet: mlankhorst, sfr has the conflict now too for the backmerge
07:14 emersion: mattst88: thanks!
07:57 emersion: oh well… kernel and libdrm don't agree on subpixel enum values
08:30 bbrezillon: karolherbst: looks like glsl_type::get_explicit_type_for_size_align() drops the packed attribute, but I don't know if that's intended
08:37 bbrezillon: karolherbst: if that is, we probably need a slightly different function for lower_io.c, because right now the packed and the field offsets are lost when we call nir_lower_vars_to_explicit_types()
08:48 austriancoder: robclark: as freedreno and etnaviv are using foreach_bit(..) I would love to move it to a common place, but I am unsure where the best place would be. maybe bitscan.h ?
09:57 pepp: karolherbst: do you mind taking a quick look again at https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/320 (I've made some small modifications since your R-b comment)
09:58 karolherbst: pepp: why do you use an explicit vs though? using none should be fine, no?
10:00 pepp: karolherbst: indeed, seems unneeded. I'll remove it
11:01 mlankhorst: danvet: sent a pull req, will look at how you'll resolve it. :p
11:16 pepp: karolherbst: odd: without explicit vs the atomic*Wrap tests fail on Mesa
11:23 karolherbst: pepp: huh, interesting
11:23 karolherbst: maybe it's needed for odd reasons afterall
12:07 pepp: karolherbst: I don't understand why it's needed. Maybe it's a radeonsi bug; can you test on nouveau?
12:48 danvet: emersion, does the /**< actually result in correct kerneldoc or more warnings?
12:48 danvet: and I was kinda hoping you'd document the entire drm_mode_get_connector struct :-)
12:48 emersion: ah, i haven't checked
12:48 karolherbst: pepp: yeah.. don't know if I come to it htough, have to deal with an internal regression first :/
12:48 danvet: the clash with libdrm is a bit annoying, maybe we could just define the magic numbers
12:48 emersion: yeah yeah, but when all enums are missing from the uapi…
12:48 danvet: with an apology?
12:49 danvet: emersion, connector type enum is there
12:49 danvet: well, the #defines
12:49 emersion: yeah
12:49 emersion: one very annoying thing is that there's an offset of 1 between the subpixel kernel enum and the libdrm one
12:49 danvet: btw the funky part of this is the drmGetConnectorCurrent thing
12:49 emersion: yeah
12:49 emersion: good point
12:49 danvet: that's a piece of uapi very much worth documenting imo
12:50 danvet: emersion, ofc if you don't feel like, pls disregard me volunteering you for more
13:04 emersion: on the contrary, thanks for the suggestions
13:04 emersion: i've been pushing back things like drmModeGetConnectorCurrent because i'm sitll not sure where to document it
13:05 danvet: emersion, I think in the ioctl struct is best
13:05 emersion: user-space people will never look up the ioctl, they'll look up the libdrm function
13:05 danvet: maybe we could put into the summary something standard like "used by DRM_MODE_GETCONNECTOR ioctl"
13:06 emersion: but making libdrm the only library allowed to talk to DRM is not nice
13:06 emersion: yeah, maybe
13:06 danvet: emersion, I know, but otoh uapi/drm/drm_mode.h is the best we have right now
13:06 emersion: @see DRM_MODE_GETCONNECTOR
13:06 danvet: I think media has some fairly nice infrastructure to make sure ioctl enums are all documented
13:06 emersion: could maybe even linkify this in the libdrm docs
13:06 emersion: once we generate a website
13:07 danvet: yeah that too
13:07 emersion: (cc pq)
13:13 danvet: mlankhorst, I guess backmerge next week would be good, könig hit the next merge conflict
13:21 mripard: anholt_: hi, could you review patches 1 and 2 of https://patchwork.freedesktop.org/series/78285/ ?
13:26 pq: There is already a strict process to sync DRM headers from kernel to libdrm. Documentation database could be part of that. Then libdrm docs can be both stand-alone and up-to-date.
13:35 MrCooper: tarceri: FYI, GitLab issues can be moved between projects
13:36 emersion: pq: how would that work?
13:36 pq: What do you mean how?
13:37 pq: I don't know what libdrm does for docs.
13:38 pq: Right now the kernel "exports" just the headers with a specific 'make' command, right? Make that 'make' command also "export" some doc file that libdrm project can consume.
13:38 pq: the header and the doc belong together anyway
13:39 emersion: ok
13:39 emersion: i think something like this will be desirable for props
13:39 emersion: or could be desirable
13:39 pq: might as well do it for everything UAPI
13:40 pq: then libdrm does not need to manually repeat the same stuff, and users find all docs in one place
13:40 emersion: well some doc comments are in the uapi header
13:40 pq: does libdrm doc build parse those?
13:40 emersion: libdrm doesn't have a docs infra iirc
13:41 emersion: it just generates man pages, and i've just only started to convert them to rst
13:41 emersion: libdrm does have some doc comments though
13:42 pq: this might be a long term plan
13:44 tarceri: MrCooper: if you are talking about the kernel bug report I didn't realise the kernel bug tracker was on gitlab until today. also it seems there was already an open bug report anyway
13:44 MrCooper: tarceri: the can also be marked as duplicates :)
13:45 MrCooper: (write "/duplicate <target issue>" in a comment)
13:46 tarceri: ah ok thanks :)
13:49 MrCooper: np; likewise "/move <target project>" for moving, the UI for moving doesn't always show all possible target projects
15:08 robclark: austriancoder: yeah, bitscan.h would make sense.. note though that the one in ir3 is a bit special, but I could rename it
16:30 pcercuei: sravn: got time to check out the DBI patches? :)
19:04 bbrezillon: jekstrand: should I keep your R-b on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5589?
19:22 jekstrand: bbrezillon: yup
19:58 Lyude: anholt_, j4ni - not right now, but at some point I actually do think we are going to want to start adding some backlight related connector properties
19:58 anholt_: Lyude: I don't think I have anything to do with backlights
19:59 anholt_: I mean, other than my opinion being "obviously, exposing it any other way than as a connector property is madness"
19:59 Lyude: wait oops, sorry lol-was thinking of your backlight issues and poked you without realizing
20:00 anholt_: only backlight issue I know of is that burned out led on my lenovo :)
20:00 Lyude: i am bad at names who was it I was talking to yesterday then
20:00 Lyude: oh duh, anarsoul
20:00 anholt_: you also pinged me yesterday or I would have let it slide :)
20:00 anarsoul: :)
20:01 anarsoul: Lyude: any patches to try so far?
20:02 anarsoul: or rather test
20:03 Lyude: anarsoul: not yet-i've been reading through the docs I got sent from a vendor a few months ago and am familiarizing myself with everything. I think shawn's patches might have skipped some things, since i'm seeing a lot of registers that aren't mentioned at all in his version
20:05 anarsoul: Lyude: there's always room for improvement, is it feasible to get Shawn's patch in first to unbreak OLED panels and send few fixups later?
20:06 Lyude: anarsoul: that's my focus first yeah, I just mentioned the extra registers because I want to make sure we actually probe the caps for this correctly
20:06 anarsoul: sounds good
20:06 Lyude: so i'm hoping in the next business day or two I will have something
20:08 anarsoul: btw, video fan in my XPS 15 failed the very first day when I received yet, I'm still waiting for Dell to react on my service request, but I may not be able to test patches for couple of weeks
20:08 Lyude: ah, np
20:08 anarsoul: if they don't respond till Monday I'll just return it and get something else
20:08 Lyude: shouldn't be a problem either way, tbh the most important part was knowing whether or not people's panels were more likely to work with the intel backlight interface or not
20:09 Lyude: i've got a couple of panels here that actually should support it (they also happened to work fine with the vesa backlight interface though, so this will be a first)
20:13 anarsoul: mine doesn't work with vesa interface
20:21 Lyude: anarsoul: i'm aware-just meant I haven't tried the intel ones on these yet because in theory they should work fine with both
20:34 anarsoul: Lyude: I'll be surprised if both interfaces are implemented correctly :)
20:38 Lyude: anarsoul: I wouldn't be-I'm fairly sure they implement both because the nvidia blob only uses the vesa interface (good for you nvidia!)
20:39 anarsoul: heh
20:39 anarsoul: :)
20:39 danvet: Lyude, btw did I miss the new version of vblank workers or still simmering?
20:39 anarsoul: I thought that panel is always connected to integrated video
20:39 Lyude: danvet: there should be a new one on the list already
20:39 Lyude: anarsoul: not on some hybrid machines, a lot of them still let you configure things through the bios
20:40 danvet: hm
20:40 anarsoul: Lyude: interesting
20:40 danvet: oh indeed missed it
20:41 Lyude: anarsoul: yeah-this kinda mislead us into thinking at first we could just get away with the vesa interface for everything
20:41 danvet: Lyude, btw did you intentionally not include the r-b on the first patch?
20:42 Lyude: danvet: nope, was an accident
20:52 Lyude: danvet: btw as well, we haven't had anyone review the igt tests for nouveau crc support yet
20:53 Lyude: (they basically stress test our handling of dropped CRC events in igt and confirm that we're correlating each crc with it's respective frame counter correctly)
20:53 Lyude: (along with just making sure all of the nouveau crc sources work)
20:59 danvet: Lyude, generic stuff that also runs on any hw supporting crc?
21:00 jekstrand: karolherbst: What's the latest spirv-llvm-translator? The one I've got built requires LLVM 7 and that seems a bit old to me. :-)
21:00 Lyude: danvet: no, it's very nouveau specific. remember how I asked you a while back about how well igt would handle a driver that occasionally misses a single CRC frame, assuming the driver doesn't lose track of which CRC goes to which frame?
21:01 Lyude: the tests are basically there to make sure both the kernel and igt actually handle it properly
21:01 jenatali: jekstrand: There's different branches targeting different LLVM versions
21:02 jekstrand: jenatali: Ah. The branch I've got had structurizing built-in
21:02 Lyude: remember - nvidia stores crcs in a DMA buffer that doesn't have an unlimited size, so we have to use the vblank workers to actually swap to a new empty CRC context whenever said buffers are almost full, and in the process it's apparently not possible in hw to avoid losing the CRC for a single frame when doing that
21:02 jekstrand: jenatali: Or are you using karolherbst's structurizer?
21:03 jenatali: jekstrand: We're using karolherbst's structurizer
21:03 jenatali: On top of the 10.0 branch of the translator
21:03 jekstrand: Ok
21:03 karolherbst: jenatali: you were probably on the one where we used llvm and a patch to the translator to do the structurizing
21:04 karolherbst: uhm
21:04 karolherbst: I meant jekstrand
21:04 jekstrand: karolherbst: Yeah, I think so.
21:04 karolherbst: yeah.. we ditched this idea as we also need to support accepting any spir-v :p
21:04 jekstrand: karolherbst: So the state-of-the-art is trunk + your NIR thing?
21:04 Lyude: -but- while we do lose a CRC randomly here and there, we can pretty easily tell which frame it went to so the frame counter on CRCs doesn't go out of sync. and for basically all of the igt tests we have right now, they seem to handle this just fine since igt will just wait for the next frame's crc when one gets dropped
21:04 karolherbst: jekstrand: pretty much.. I have a few patches, but nothing huge: https://gitlab.freedesktop.org/karolherbst/mesa/-/commits/clover_support_hmm_wip
21:05 karolherbst: and I need to rebase it probably
21:05 Lyude: it is very weird but unfortunately kind of necessary for nouveau :(, according to nvidia at least
21:05 jenatali: jekstrand: I'm personally also using a hacked up patch to the translator to pass the compiler CTS test: https://github.com/KhronosGroup/SPIRV-LLVM-Translator/pull/588
21:05 gitbot: KhronosGroup issue (Pull request) 588 in SPIRV-LLVM-Translator "Modify SPIR-V kernel linkage" [Closed]
21:06 sravn: pcercuei: DBI patches are on my TODO list to review, just falling behind on stuff. Will come back to them eventually, sorry for takign this long
21:06 karolherbst: jenatali: there is a khronos meeting to discuss the translator... or at least there was one
21:06 karolherbst: in case you want to bring some issues up there
21:07 jenatali: karolherbst: Good to know. I know there's IP concerns about MSFT participating in Khronos working groups, not sure how easy it'd be for me to be in that kind of meeting
21:07 jenatali:shrugs
21:07 karolherbst: jenatali: I doubt there is any issue though as the meeting is quite technical and usually discusses the spirv/llvm stuff only
21:07 karolherbst: but yeah
21:07 karolherbst: ...
21:08 karolherbst: there were others with secrets on the call ;p
21:09 jenatali: :p good to know. I'll bring it up here, thanks. It *mostly* works for us, just a couple bugs that I definitely don't have the expertise to fix
21:09 karolherbst: let me check if it's still ongoing
21:11 karolherbst: jenatali: on the opencl mailing list it's the tuesday meeting
21:12 karolherbst: jenatali: heh.. your issue was discussed :D
21:12 jenatali: karolherbst: Oh cool :p is someone gonna fix it for me? ;)
21:12 karolherbst: I don't think so :p
21:12 jenatali: Boo
21:12 karolherbst: but I guess you can join and find out
21:13 karolherbst: next one should be next week, seems to be bi-weekly
21:13 karolherbst: maybe I join as well :p
21:16 daniels: we are not using the LLVM structuriser - I did that early on, but karolherbst talked me out of it
21:17 daniels: karolherbst: we're using your NIR structuriser of the last revision I know of; about 3 weeks ago
21:17 karolherbst: ohh, cool
21:17 karolherbst: I hope I didn't break anything
21:17 daniels: when you revised Julian's series
21:17 daniels: CTS says nothing is your fault :)
21:18 karolherbst: yay
21:18 karolherbst: the bigger changes still need to be done though
21:18 karolherbst: still thinking if I really move to the single pass approach or not
21:18 daniels: jekstrand: on my to-do for next week is to prepare an integration branch on master which works on clover+llvmpipe; I'll ping you that
21:19 danvet: Lyude, hm I guess dunno whom you could poke for an ack
21:19 danvet: just shop around :-)
21:19 daniels: karolherbst: I don't have any useful comment on that; it's far beyond my depth
21:19 danvet: Lyude, also conditional r-b on patch 3 now, I think I found a few tiny details
21:19 Lyude: danvet: np, I'll get to it :)
21:19 Lyude: danvet: gotcha
21:19 airlied: daniels: any idea how hard piglit ci would be too add
21:19 karolherbst: airlied, daniels: any comments on the idea to do CL CI on top of llvmpipe with the CTS?
21:20 airlied: karolherbst: soubds good piglit is also useful
21:20 karolherbst: yeah.. no idea what piglits tests
21:20 karolherbst: but I'd rather trust the CTS :p
21:20 karolherbst: some tests are quite long though, so maybe just run basic?
21:21 airlied: piglit just has decent builtib coverage
21:21 karolherbst: ahh
21:21 jenatali: Basic took a lot of work to get to run, especially since it needed libclc work to get the async copy stuff to work
21:21 karolherbst: airlied: we only makes sense if we also have libclc stuff in?
21:21 karolherbst: jenatali: as long as it covers everything, it's fine
21:21 karolherbst: we don't want to run long tests anyway
21:21 karolherbst: so if it is done in 10 minutes, cool
21:21 jenatali: Heh... definitely not evertying
21:22 airlied: karolherbst: yeah need clc and sturcturizer in pre ci
21:22 karolherbst: yeah.. but real CI I'd offload to proper workers
21:22 karolherbst: llvmpipe test are usually running on the fdo infra
21:22 danvet: jenatali, btw did we chat about adding some more modern gpu memory management designs to linux eventually?
21:22 airlied: llvmpipe beeds some more backend work but i habe a bunch of that for vulkan
21:22 danvet: or was that someone else from the wsl2 dirext pass through discussion
21:22 karolherbst: airlied: the structurizer is probably the stuff I will finish next.. or just merge my nouveau svm bits :p
21:23 jenatali: danvet: It was probably me. I don't think anyone else from that discussion (except Sasha) has been on here
21:23 danvet: well I'm not sure it was here ...
21:23 jenatali: danvet: Oh, then probably not me since it doesn't sound super familiar :p
21:27 danvet: yeah I think that was with steve pronovost on the m-l thread, but somehow the archive of that is a bit busted
21:27 danvet: jenatali, reason is I just had a few discussions about some of the not entirely simple problems that extending the current memory model has
21:27 danvet: and type up a doc patch, since we're rediscovering this like once per year
21:27 danvet: in case you want to be cc'ed
21:28 jenatali: danvet: Sure, that'd be great. I'm sure Steve would love to as well
21:28 danvet: yeah cc'ing steve
21:28 jenatali: jenatali@microsoft.com in case you didn't have it
21:29 danvet: found you on that thread
21:29 danvet: maybe next week, there's a pile of other loose ends on that series
21:30 jenatali: Cool
21:30 karolherbst: ehh.. needing some reviews for https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4580 :/
21:31 karolherbst: I think...
22:05 jekstrand: karolherbst: How is shared memory accessed in OpenCL? Should I be looking for a "shared" keyword?
22:05 jekstrand: Or is it called something else?
22:06 jenatali: jekstrand: __local
22:07 jekstrand: And you just declare something __local in a global (not function) scope?
22:07 karolherbst: kernel input
22:07 jenatali: Inside a kernel function, or as kernel input
22:07 karolherbst: jenatali: inside a kernel function only works with a known size, right?
22:08 jenatali: karolherbst: Right. Arrays of known size inside a function, or pointer to unknown-size array as kernel arg
22:08 jenatali: And invalid to declare inside called functions or at global scope
22:08 karolherbst: just do the struct wrapper trick :p
22:08 jenatali: ?
22:09 karolherbst: struct { __local *ptr } a; and use a.ptr :p
22:09 karolherbst: even though it ends badly
22:09 karolherbst: or not
22:09 karolherbst: dunno :p
22:10 jenatali: Oh sure, you can declare pointers to __local wherever, the only thing that actually allocates it though is what I said
22:10 karolherbst: yeah.. but I am sure most runtimes will just accept that stuff :p
22:11 karolherbst: and you can probably juse use the unset ptr
22:11 karolherbst: *just
22:11 jenatali: We'll blow up :(
22:11 karolherbst: why though?
22:12 jenatali: Because that'll cause us create DXIL getelementptr instructions to access a global shared variable that doesn't exist, because no shared memory size was allocated
22:12 karolherbst: ahh ..
22:12 jekstrand: Looks like in some version of OpenCL they dropped the __
22:12 jekstrand: That explains why I'm not seeing in bit of OpenCL I'm looking at
22:12 jenatali: jekstrand: Yeah the non-__ keywords are #defines for the __ versions I think
22:12 karolherbst: yeah...
22:13 karolherbst: but I also prefer to write the address space in front of the *
22:13 karolherbst: more obvious if you declare .. silly pointers
22:13 karolherbst: like int local* global* constant* a; pointers :p
22:13 jenatali: D:
22:28 LaserEyess: I know this is a -devel channel but I'm looking for help debugging an incredibly hard crash in the latest 5.7 and 5.4 kernels, that I suspect is related to amdgpu
22:29 LaserEyess: I tried turning on drm debugging and kernel debugging but my logs show *nothing*, not even warnings
22:29 LaserEyess: it's a full system lock up, I can't even ping the machine, and it starts about 30 seconds to 5 minutes after I start my WM
22:29 LaserEyess: is there any other debugging value I can turn on to look for what's happening?
22:56 Lyude: oh danvet, how do you want these patches to be merged?
22:56 Lyude: should we just push them through nouveau?
23:56 apinheiro: anholt_, Im doing something wrong when reassigning issues to Marge?
23:59 apinheiro: ah, there is a "branch cannot be merged" issue