00:24 airlied: jekstrand, karolherbst : https://gitlab.freedesktop.org/airlied/mesa/-/commits/llvmpipe-cl-funcs hacks towards llvmpipe backend fn support, the nir/spirv bits might save somene 5 minutes
01:04 airlied: "vec4 32 ssa_131 = intrinsic load_ubo (ssa_126, ssa_130) (0, 1073741824, 160, 160, 16) /* range_base=160 */ /* range=16 */ /* access=0 */ /* align_mul=1073741824 */ /* align_offset=160 */
01:04 airlied: that align_mul look a bit large to anyone else? :-P
01:05 HdkR: I love a good 1 << 30 alignment
01:20 bnieuwenhuizen: airlied: don't forget to take into account the base alignment of the UBO!
01:47 airlied: ah that's NIR_ALIGN_MUL_MAX
02:07 jekstrand: airlied: I picked an arbitrary large alignment. :P
02:07 jekstrand: airlied: Assuming that back-ends would just &something to get it down to their required binding alignment.
03:34 anholt: airlied: should probably just make nir_print use the symbol
04:47 jekstrand: I really should make align_offset/mul 16-bit....
04:47 jekstrand: It's on my TODO list
04:47 jekstrand: Then they can take up one const_index instead of two.
05:39 airlied: MrCooper, anholt : advice on 3695 request
08:27 MrCooper: airlied: commented
08:28 MrCooper: danvet emersion karolherbst: weston has a headless backend, that should work wherever Xvfb does
08:30 danvet: so maybe we need Xvfb which fires that up + xwayland, as a script :-)
08:30 danvet: as part of the xwayland-only xserver release
08:30 emersion: lol
08:32 MrCooper: Xvfb isn't even needed for that
08:32 danvet: MrCooper, as a replacement for Xvfb
08:32 MrCooper: but so far I'm keeping it, because it's used by some tests
08:32 danvet: so that can be dropped as a ddx
08:33 MrCooper: ah, interesting idea :)
08:33 danvet: just pass all the arguments to Xwayland or something like that
08:33 danvet: to really hammer it in that the only legit way to run X going forward is as Xwayland on top of some wayland
08:33 danvet: :-)
08:34 danvet: then release the entire thing with an "X is dead, long live X" code name or so
08:35 MrCooper: not really looking for that kind of adventure I'm afraid, I just want to get the cool new Xwayland features into the hands of users
08:36 danvet: MrCooper, is the plan to regen this for every release plan?
08:36 danvet: or fork?
08:37 danvet: *release branch
08:39 MrCooper: yeah, moving the changes dropping stuff from one branch to another is pretty trivial
08:39 MrCooper: development will continue on master
08:40 MrCooper: in order to prevent forks of the DIX code
08:52 danvet: makes sense, and I guess matches what homebrew and cygwin are doing
08:54 pq: karolherbst, danvet, you can run Weston/headless with full GL accel and Xwayland in it... no need for VKMS even. Just... screenshooting through Xwayland is a bit of a... loss.
08:55 pq: but you could run Xwayland in rootful mode, then you should be able to screenshoot the whole X11 desktop
08:56 MrCooper: daniels: does piglit-cl run CL-GL interop tests? If not, mesa_core_file_list is kind of overkill
08:56 pq: karolherbst, weston's CI already runs weston/headless/GL with no GPU.
08:57 daniels: MrCooper: looks like only for EGL_KHR_cl_event2, which we don't support
08:58 MrCooper: pq: you mean like https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/516 ? :)
09:03 pq: MrCooper, oh, cool!
09:07 pq: MrCooper, makes we wonder if Weston should install the test-desktop-shell plugin... No launching helper clients, fixed window positioning, and no GUI logic.
09:07 MrCooper: that could be useful
09:08 pq: Though the kiosk shell exists too, now. It just negotiates everything to fullscreen, which may or may not be a problem for test apps.
09:08 MrCooper: should be fine for this, it just runs a single non-rootless Xwayland
09:09 pq: ah, rootful
09:10 pq: MrCooper, would you need help from weston to replce the 'sleep 1' with a proper wait or let weston launch the test script?
09:12 MrCooper: not really "need" per se, but could help
09:12 pq: someone somewhere might have already written a wayland client, that just pokes at the given wayland socket until it exists, connects, and does a roundtrip. That should ensure Weston is started without relying on systemd notifications.
09:14 pq: I suppose such tool would be nicer for test scripts than having Weston launch stuff?
09:14 MrCooper: the latter could be useful for testing rootless Xwayland
09:14 pq: emersion, do you know of such tool already that waits until the given wayland socket is ready?
09:15 emersion: pq: our compositors just have a CLI flag to execute a command when ready. you can use that with a readyness FD or something
09:16 emersion: pq: you don't know the socket name before the compositor is started, right?
09:16 pq: emersion, test scripts usually tell the compositor which socket it must listen on.
09:17 pq: otherwise the test might connect to a wrong compositor
09:17 pq: ..depending on where the test runs from
09:17 emersion: polling doesn't sounds great
09:17 emersion: sound*
09:18 pq: for test suites, I doubt it makes a difference
09:18 pq: having weston run a command would be easy though
09:18 emersion: i like the command approach because it's more generally useful
09:19 pq: emersion, does your compositor also exit when the command finishes?
09:20 pq: I guess that could be another flag.
09:20 emersion: cage does that, i believe
09:22 emersion: if you want something good enough for a test suite, could probably just have a script which polls with weston-info :P
09:23 pq: putting fork && exec in the poll loop goes a bit far
09:25 MrCooper: something like "while \! weston-info &>/dev/null; do sleep 1; done"?
09:25 pq: yeah
09:26 pq: just need to check that weston-info exit code is properly done
09:26 MrCooper: I'll try that
09:27 emersion: WAYLAND_DISPLAY=idontexist weston-info
09:27 emersion: -> 255
09:36 MrCooper: right, but could the socket exist, but Xwayland still fail because weston isn't ready yet?
09:38 pq: MrCooper, not if the roundtrip works.
09:39 pq: For roundtrip to work, weston must have entered its main loop, so everything is done by then.
09:39 pq: If xwayland support is enabled, weston launches rootless Xwayland when the X11 client attempts to connect, so Weston sets up the X11 socket too.
11:20 danvet: agd5f_, hwentlan for the drm_driver constification, can you pls look at the radeon/amdgpu patch?
11:21 danvet: the amdgpu is required, I guess the radeon one I can drop if I also drop the constification for radeon
11:33 stuom1: how could I enable DRM debug messages at compile time? I cannot access sysfs because I cannot boot
11:34 pq: stuom1, would enabling them on kernel command line help?
11:35 pq: drm.debug=... should still work I think
11:44 stuom1: pq Thanks, I tried to set bootargs in u-boot but it didn't have any effect. Was that what you meant? (setenv bootargs drm.debug=0x1ff)
11:46 pq: I don't know u-boot, but I guess.
11:48 pq: stuom1, if you can't access sysfs (which would be too late for boot issues anyway), how will you access the logs?
11:49 stuom1: I thought it would be printed during boot?
11:49 pq: they should be - so do you actually get boot messages on screen, or serial, or?
11:50 stuom1: My problem is with a MIPI-DSI panel DRM driver I'm writing, and it hangs the whole boot after one function in my driver, and there is no errors
11:50 stuom1: I get boot messages
11:51 stuom1: up until get_modes and then it just freezes
11:51 pendingchaos: anholt: ntt_should_vectorize_io() looks like it wasn't updated after rebasing at some point
11:51 pendingchaos: "align" was split into "align_mul" and "align_offset" and "high_offset" was removed
11:51 pq: stuom1, where do you get boot messages? On the same panel whose driver you are testing?
11:52 stuom1: from serial
11:52 pq: ah, good
11:52 pq: wonder if the serial console logging level plays a role there
11:53 pq: maybe it ignores debug level messages
11:53 pq: stuom1, another idea: would it be possible to build your driver as a module and load it manually after the system is up?
11:55 danvet: stuom1, yeah make sure debug output goes out
11:56 danvet: and also https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html#c.drm_fb_helper_initial_config -> HANG DEBUGGING section
12:05 stuom1: pq, possibly, I will look into it. danvet, thanks that looks relevant. I tried those bootargs but again they didn't have any effect. Now I need to debug if and how the bootargs should work...:)
12:31 danvet: airlied, so with all this, should we still accept -modesetting feature patches
12:31 danvet: for new uapi?
12:32 danvet: MrCooper, ^^
12:32 danvet: since I don't expect xserver master to release anytime, if ever
12:33 danvet: and new features in 1.20 -modesetting sounds a bit wild
12:33 danvet: mattst88, ^^
12:47 stuom1: danvet, thanks alot, this hang debugging got me forward. Happy to see error messages!
12:48 danvet: stuom1, it's a classic :-)
12:49 danvet: there's some plans to fix the locking and allow printk and at least serial console to proceed
12:49 danvet: while kms sets up the new fbcon
12:50 danvet: but it's going to take a while to address this
12:50 danvet: I think 5.10 just landed the new printk locking
12:51 stuom1: (y)
15:45 stuom1: I'm writing a DRM panel driver, any ideas could these be a driver, device tree, or hardware issue? [drm:nwl_dsi_host_transfer] *ERROR* [11] DSI transfer timed out
15:57 pcercuei: your panel driver cannot communicate with the panel
15:58 pcercuei: make sure your DSI pins are properly configured as such in the DTS, if it's needed
15:59 stuom1: Thanks, so if something would be wrong with the init sequence bytes, I would get different kind of error?
16:06 pcercuei: I would think so, yes
16:29 jenatali: jekstrand, karolherbst: Did I miss anything from the last two weeks? :)
16:30 ajax: what's the review rule for doc fixes?
16:30 jekstrand: jenatali: Besides me fixing memcpy and karolherbst landing image support, no.
16:31 ajax: slash anyone care to cast an eye over !7281
16:31 karolherbst: jekstrand: bunch of image stuff
16:31 karolherbst: ,,,
16:31 karolherbst: jenatali:
16:31 jenatali: Cool
16:31 karolherbst: and I found some bugs in code you might also use? dunno
16:31 jenatali: karolherbst: I saw the Phoronix headline about image support landing
16:31 karolherbst: jenatali: do you have your own image lowering?
16:31 jenatali: karolherbst: Yeah, so far we do - we might merge it after/during upstreaming
16:31 karolherbst: found a bug with array images not being correctly handled
16:31 karolherbst: ahh
16:31 karolherbst: okay
17:01 jekstrand: karolherbst, jenatali, airlied: What's the path look like for upstreaming generic pointers?
17:02 jenatali: jekstrand: What's missing? Just reviews?
17:03 karolherbst: yeah.. probably?
17:03 karolherbst: I didn't try it out yet
17:03 jekstrand: And an excuse to land it
17:03 karolherbst: jekstrand: I think we all are rather focusing on CL 1.2 bits for now, but yeah.. generic pointers might be an optional feature we want to support regarless
17:03 karolherbst: jekstrand: maybe we should merge the CL 3.0 stuff first?
17:04 karolherbst: and then we can have it properly supported once we are CL 3.0 conformant
17:04 jekstrand:is very focused on getting a specific set of kernels working and they require generic pointers. :P
17:04 karolherbst: LD
17:04 karolherbst: oh well
17:04 jenatali: That sounds like an excuse to land it to me...
17:05 karolherbst: I wanted to play around with mapped memory regions on my GPU though
17:05 karolherbst: and design it around being able to do if ladders, but also address translation
17:09 jekstrand: karolherbst: It should work for both
17:11 karolherbst: jekstrand: ahh, cool. I just need to write some nouveau code then I guess
17:12 jekstrand: karolherbst: Yeah, all you need to do to get it to not lower if ladders is use an address mode of global64
17:13 jekstrand: karolherbst: Or maybe define a new mode which is "global64 unless you know a prior that it's shared or function_temp"
17:13 karolherbst: yeah.. not sure
17:13 karolherbst: but that's why I wanted to try it out
17:14 karolherbst: anyway, the problem with CL 2.0 features are that we can't really only support some features
17:14 karolherbst: we really need CL 3.0 for that
17:15 jenatali: Well, you can't properly report that you support them, but you can still implement them
17:16 jenatali: jekstrand: The generic pointer MR is still marked WIP - I think I was waiting for that to go away before going for a thorough review
17:16 agd5f_: danvet, it's on my todo list
17:18 jekstrand: jenatali: Oh... I should probably drop that. :)
17:25 MrCooper: ajax: maybe you could trade reviews with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7060
17:32 ajax: naturally daniels gets there five minutes before me...
17:33 daniels: just wanted to give you more time for 1.21
17:34 ajax: every time i think i'm out...
18:11 airlied: danvet: good q, possibly, have we seen uapi via modesetting recently?
18:14 danvet: airlied, I don't think so, nor do I see any modesetting MR pending for new uapi
18:15 danvet: this problem might solve itself naturally
18:17 warpme_: guys: it looks like 5.9 has regression in drm for me. Context: after switching from 5.8.15 to 5.9.1 i started to have media player (mythtv) hanging at playback exit. I'm using mesa master with drm_prime EGL_LINUX_DMA_BUF_EXT on mali t820 and g31. On playback exit i see kernel trap with execute from non-executable memory: https://www.irccloud.com/pastebin/igxygUq0/
18:17 warpme_: reverting 26d3ac3cb04d + 7d2cd72a9aa3 and 526408357318 + manual fix for compile on 5.9.1 solves issue. So it looks like 26d3ac3cb04d is regression on 5.9.
18:19 vsyrjala: when i upgrade my ivb laptop to something more modern i'll probably have to port the less crappy gamma stuff from intel ddx to modesetting
18:20 airlied: danvet: vrr was only thing that sprang to mind
18:20 airlied: vsyrjala: that uapi is already in the kernel though
18:21 danvet: warpme_, videobuf2 dma-buf mmap support probably broken
18:21 danvet: before this patch we had our own mmap, which is kinda big layering violation
18:21 danvet: with this, we forward to videobuf2
18:21 danvet: which blows up
18:22 warpme_: danvet: probably :-) btw: 5.8.15 works nicely so it will be nice to no regress....
18:23 danvet: warpme_, oh sure, it's just I have no clue about vb2 code
18:23 danvet: plus I've never read an arm oops
18:24 danvet: warpme_, there's some debug stuff in there, can you pls recrash with full dmesg debug enabled?
18:25 danvet: oh needs a recompile with either dynamice debugging or a #define DEBUG 1
18:25 danvet: in videobuf2-memops.c
18:25 vsyrjala: airlied: yeah, but the current uapi is not actually very good. so we need yet another new uapi for it
18:26 warpme_: danvet: sure. give me sec....
18:28 danvet: hm guessing that we blow up on non-exectable memory h->put() goes boom
18:29 airlied: karolherbst: we can land feature abd nouveau can add support later :-p
18:29 danvet: but from a quick reading of that code I'm not seeing how we can set up vb2_common_vm_close and not set up that callback correctly
18:30 danvet: warpme_, the pr_debug already prints everything intersting, so if you can recompile with DEBUG and grab that line before it goes boom, we should know more
18:30 danvet: except if the ->vm_private_date is bonkers, then we'll instead blow up trying to print the stuff :-)
18:31 emersion: vsyrjala: agreed
18:31 emersion: ping me if you need user-space for better uapi
18:32 danvet: airlied, yeah but vrr landed through -amdgpu
18:36 airlied: danvet: I'd like to kill all DDX :-P
18:37 airlied: ajax: was that a sarcastic "every time.." or did something put you back in :-)
18:38 ajax: definitely not serious
18:38 ajax: starting to think i really should blog about that though
18:39 danvet: airlied, I think -amdgpu is better than -modesetting, since at least it's sees releases
18:39 danvet: and seems to still have people caring
18:39 danvet: no idea how/when amd plans to sunset that ... agd5f_ hwentlan?
18:42 airlied: maybe it's time to split modesetting back out of the server
18:42 airlied: and admit that merging it ended up being a bad idea
18:42 agd5f_: danvet, probably never? we'd need to port the legacy kms stuff to atomic or get rid of it
18:44 warpme_: danvet: well - I added #define DEBUG 1 in videobuf2-memops.c, recompiled, reinstall and got following in dmesg:
18:44 warpme_: https://www.irccloud.com/pastebin/IATNXeiy/
18:45 warpme_: not sure is this helpful?
18:45 jljusten: Hmm. Seems Marge Bot always rewrites the commit. Mesa 8d03cfae7c3 has the same commit message/author/time as the MR branch, yet the commit gpg sig was dropped.
18:51 danvet: warpme_, there should be something before the first line
18:51 danvet: warpme_, could also be output level set too limiting for dmesg
18:55 danvet: warpme_, https://paste.debian.net/1168854/ this should give a ton of debug output even before it dies
18:55 danvet: or I have no idea what I'm doing
18:55 danvet: hm actually not a ton :-/
18:58 airlied: daniels: if you have a minute for an ack, 7328 is reworked
19:15 daniels: airlied: done, ta
19:16 daniels: jljusten: yes, Marge rewrites the commit message and also rebases
19:17 jljusten: daniels: no rebase was required in this case. it was already up to date. no change was made to the commit message or committer or commit date.
19:18 daniels:shrugs
19:29 DPA: danvet: Should I make a v3 of "[PATCH] Implement .format_mod_supported in mxsfb" with allow_fb_modifiers explicitly set?
19:29 DPA: I mean, I know it's not really necessary to enable it in this case, but it'll give me an excuse to send the patch again, this time from a domain without dmarc.
19:29 danvet: DPA, I got it wrong, it's implicitly set already
19:30 danvet: it's more like the drivers which explictly set allow_fb_modifiers are kinda in the wrong
19:30 danvet: well not wrong, but maybe a bit much
19:30 danvet: DPA, so up to mxsfb maintainers
19:32 danvet: warpme_, https://paste.debian.net/1168858/ brute force to make sure the output we need shows up :-)
19:32 DPA: Ok, I guess I'll just wait a week or two then.
19:37 warpme_: danvet: hmm:
19:37 warpme_: https://www.irccloud.com/pastebin/BHjH7IPa/
19:37 warpme_: i'll add this manually
19:40 karolherbst: airlied: btw, what's up with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6908
19:40 karolherbst: close? rebase? :D
19:41 karolherbst: at least the first commit already landed so I was wondering
19:47 warpme_: danvet: better :-)
19:47 warpme_: https://www.irccloud.com/pastebin/C3Y38gGh/
19:51 danvet: warpme_, I have no idea
19:52 danvet: I think this needs a bug report to media people
19:52 danvet: since it seems to work all fine
19:52 danvet: until at like the 8th buffer or so we go boom
19:53 warpme_: danvet: so you advise kernel bug report?
19:54 danvet: https://paste.debian.net/1168861/ maybe printing out h->put callback helps
19:55 danvet: but yeah, I have no idea, and vb2 code is definitely not something I have expertise on
20:05 warpme_: danvet: here it go...
20:05 warpme_: https://www.irccloud.com/pastebin/22A0svL8/
20:08 airlied: karolherbst: oh I think I can kill that one, I've merged a bunch of fixes earlier this week that did that will check nothing left behind today
20:12 danvet: warpme_, I think you do something wrong with your kernel install sometimes
20:13 danvet: this is the old one that doesn't print put: %pS
20:13 danvet: maybe that also explains why DEBUG didn't work at first, since on 2nd attempt it worked and we have all the debug output
20:16 warpme_: ack. my bad. i'm editing code by hand. sorry. copy-paste error. corrected. rebuilding. will report soon
20:25 warpme_: danvet: hope now is what you expect:
20:25 warpme_: https://www.irccloud.com/pastebin/VD7Z2rQj/
20:44 airlied: robclark, anholt : flaky? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/5231911
20:44 anholt: airlied: this is the "stacked flake handling has bugs" issue in the ci flakiness tracker
20:45 danvet: warpme_, uh I have another idea
20:45 anholt: actively working on simplifying and fixing this.
20:45 anholt: (maybe having a giant pile of bash to work around our c++ is not the best?)
20:46 danvet: warpme_, https://paste.debian.net/1168869/
20:46 danvet: I missed that we're now indeed going boom in the printk
20:46 danvet: so looks like ->vm_private_data is busted
20:47 airlied: anholt: how many times do I let marge bounce it before I just disable tthe job?
20:47 airlied:crosses fingers on 3rd tryu
20:47 anholt: has it been that flaky ? I haven't been paying as close of attention to marge's complaints since there's been so much noise and I've been working on CI anyway.
20:49 airlied: I've hit it twice in one MR, just awaiting attempt 3
20:50 anholt: also, wtf, I don't see this one in the ci flakes channel?
20:51 airlied: now marge is going to rebase it again and we'll see if it fails again
20:57 warpme_: danvet: here it is:
20:57 warpme_: https://www.irccloud.com/pastebin/SL11RM4V/
20:57 danvet: uh wow
21:02 danvet: warpme_, ok I see it I think
21:03 warpme_: eh. goooooood
21:03 danvet: it's actually a drm bug lol
21:03 danvet: if I'm right
21:03 danvet: https://paste.debian.net/1168871/
21:14 danvet: warpme_, it's not complete, I think there's still a leak left
21:15 danvet: but if you can test this while I try to figure out what all else needs fixing, would be nice
21:15 danvet: also keep all the debug output, in case I'm wrong :-)
21:16 warpme_: and....fantastic-bombastic: it works!
21:17 danvet: nice
21:17 danvet: let me fix the leak and type up something
21:17 danvet: that resembles an actual patch
21:19 danvet: warpme_, this is with panfrost I guess?
21:22 warpme_: yes. this is panfrost on amlogic s912 (t820) and also sm1 (g31).
21:24 danvet: warpme_, mail address for reported-by credits?
21:24 danvet: https://paste.debian.net/1168873/ also now with the leak fix
21:24 warpme_: piotr.oniszczuk@gmail.com :-)
21:25 danvet: if I'm right and there's a leak, otherwise we'll have another boom and more head scratching for me
21:26 danvet: if this version passes testing I'll send it out right away
21:29 warpme_: sure. let me compile&test
21:31 warpme_: danvet: hmm - FYI applying on vanilla 5.9.1:
21:31 warpme_: https://www.irccloud.com/pastebin/JxVTC6L4/
21:31 warpme_: do i miss something?
21:32 warpme_: i can go manually of course
21:32 warpme_: probably this is for drm-next?
21:33 warpme_: is for->based on
21:35 danvet: yeah it's for drm-next
21:36 warpme_: ok. so i'll go manually
21:37 danvet: ah yes some cleanup patches in 5.10 that upset the context
21:38 danvet: we only have the obj->funcs->mmap callback nowadays, the old one died
21:40 danvet: I'll add a comment to the commit message for the stable release team when they pick up the backport
21:47 warpme_: danvet: ok. 10 recording playback exits tested. all ok. dmsg clean. gooood.
21:48 danvet: thx
21:51 warpme_: and last word....working with you it's pleasure!
22:37 jekstrand: karolherbst: What's the deal with nir_select?
22:37 jekstrand: karolherbst: What's up with the MSB language? Seems nuts to me.
22:39 karolherbst: jekstrand: what do you mean?
22:39 jekstrand: It has totally different behavior for vector vs. scalar
22:39 karolherbst: yeah
22:40 karolherbst: look into the cl spec :p
22:40 karolherbst: "For a scalar type, result = c ? b : a."
22:40 karolherbst: "For each component of a vector type, result[i] = if MSB of c[i] is set ? b[i] : a[i]."
22:41 jekstrand: This kernel has the following line:
22:41 jekstrand: scale = select((float4)(0.0f), scale, diag > eps);
22:41 karolherbst: we can rename it into nir_cl_select if you want to
22:41 jekstrand: I don't think select does what they want there.
22:41 karolherbst: mhhh
22:41 jekstrand: Unless CL requires diag > eps to return a 0/~0 boolean
22:41 karolherbst: mhhh
22:42 jekstrand: And the NIR I'm seeing doesn't make a lot of sense either. :-(
22:42 karolherbst: I assume CL doesn't know float bools anyway
22:42 karolherbst: so it's all int?
22:42 karolherbst: dunno
22:42 karolherbst: and int bools are 0/~0 afaik
22:42 karolherbst: but let's see
22:42 karolherbst: ahh.. no
22:43 karolherbst: "A conditional data type which is either true or false. The value true expands to the integer constant 1 and the value false expands to the integer constant 0."
22:43 jekstrand: so select(a, b, bool) is guaranteed to return a
22:43 jekstrand: great
22:43 karolherbst: for vectors
22:43 karolherbst: not for scalars
22:44 karolherbst: don't ask me how other implementations are implementing it
22:44 karolherbst: jekstrand: but.. different question, what is the MSB of a bool? :p
22:44 karolherbst: anyway, doesn't matter I think?
22:45 jekstrand: karolherbst: c has to be an integer
22:45 karolherbst: right and 1 casted to one is definetly 1
22:45 karolherbst: the spec is bonkers here anyway
22:45 jekstrand: Clearly
22:46 karolherbst: I wouldn't be surprised if every CL implementaiton implements it incorrectly
22:46 karolherbst: and has a if CTS check
22:46 karolherbst: let's see what pocl does
22:46 karolherbst: ahh no
22:46 karolherbst: they special case vectors as well
22:46 karolherbst: but mhhh
22:47 karolherbst: mhhhhhh
22:47 karolherbst: scalar: return c ? b : a;
22:47 karolherbst: vector: return *(IGTYPE*)&c < (IGTYPE)0 ? b : a;
22:47 karolherbst: although I guess that's correct
22:47 karolherbst: just.. why
22:48 karolherbst: anyway
22:48 karolherbst: jekstrand: I think your kernel is just busted :p
22:49 karolherbst: and tomorrow I have a day off :D
22:49 jekstrand: karolherbst: This wouldn't be the first bug I've found. :-(
22:49 jenatali: Huh, we didn't have any problems with select...
22:50 karolherbst: jenatali: btw, did you try running luxmark v3?
22:50 jekstrand: jenatali: I think what we have in vtn matches the spec. I just don't see how the spec matches any developer expectation ever.
22:50 karolherbst: uhm
22:50 karolherbst: v3.1 specifically
22:50 jenatali: karolherbst: I haven't tried since I'm back from vacation. Last I tried, it ran, it just produced black
22:50 jenatali: jekstrand: Fair enough :)
22:50 karolherbst: jenatali: heh
22:50 karolherbst: that's worse what I got
22:50 karolherbst: I at least get the background rendered
22:50 jenatali: Yeah, I recall
22:51 karolherbst: but good to know it is also bonkers for you
22:51 jenatali: Hopefully I'll get time to play around with it more...
22:51 karolherbst: yeah
22:51 karolherbst: really want to make it work
22:51 karolherbst: but I think it's just random stuff now
22:51 karolherbst: ohh right
22:51 jenatali: I'm hopeful that it's just one thing and then poof it works, but we'll see about that :P
22:51 karolherbst: jekstrand: what should I try out again?
22:53 karolherbst: jenatali: ehh.. I looked at the CL code and I am sure it's not :p
22:54 jenatali: :)
22:54 karolherbst: I have this struct align MR but I think there was another thing which could fix it..
22:55 karolherbst: something where we only look at component x
22:55 karolherbst: and not the others
22:55 karolherbst: jekstrand: do you remember what it was/
22:56 jekstrand: karolherbst: I'm not sure what you mean.
22:56 karolherbst: yeah.. and I don't remember
22:56 jekstrand: I thought about doing the alignment thing a different way but didn't like it after I'd started typing.
22:58 karolherbst: jekstrand: also, luxmark caches shaders
22:58 karolherbst: uhm kernels
22:58 karolherbst: jenatali:
22:58 karolherbst: you need to rm them
22:58 jenatali: Oh, good to know
22:58 karolherbst: I think we have to version binaries and reject them
22:58 jenatali: Though, that'd only impact me if I needed to change vtn
22:59 karolherbst: or nir
22:59 jenatali: Actually... no, only if I needed to change clang
22:59 karolherbst: or anything
22:59 jenatali: My binaries are spir-v
22:59 karolherbst: well
22:59 karolherbst: ahh
22:59 karolherbst: we cache the nir :)
22:59 karolherbst: uhm.. return them I mean
22:59 jenatali: Yeah. Maybe we'll get there, but spir-v was simpler and still saves a ton of compilation time, clang isn't cheap
23:00 karolherbst: right
23:02 jekstrand: karolherbst: Ok, I know why it works now. Because < works differently on vectors vs. scalars!
23:02 jekstrand: "For vector types, the relational operators shall return 0 if the specified relation is false and -1 (i.e. all bits set) if the specified relation is true."
23:02 karolherbst: jekstrand: duh...
23:02 jekstrand: Isn't OpenCL awesome?
23:02 karolherbst: the heck
23:02 karolherbst: are we doing this correctly though? :D
23:03 karolherbst: this is so insane
23:03 karolherbst: well... at least it matches hardware
23:03 karolherbst: our hw bool int are 0 and -1
23:03 jekstrand: karolherbst: Not sure. I suspect maybe LLVM is doing it for us?
23:04 karolherbst: hopefully?
23:04 karolherbst: let's ask the CTS
23:05 karolherbst: nope
23:05 karolherbst: "./build/test_conformance/relationals/test_relationals relational_select_signed" fails for vectors
23:05 karolherbst: *sigh*
23:05 karolherbst: llvmpipe seems fine though
23:06 karolherbst: maybe it's a nouveau bug
23:06 karolherbst: int8/16 is still broken ..
23:06 karolherbst: should really fix it
23:06 jenatali: Still broken in nouveau?
23:06 karolherbst: well. GL doesn't need them
23:07 jenatali: Right, I just mean not in the rest of Mesa? I thought we got the rest of the places where 4 was hardcoded
23:07 karolherbst: ohhhh
23:07 karolherbst: I meant char and short
23:07 jenatali: Oh
23:08 karolherbst: vecs don't matter as our ISA is scalar :p
23:08 karolherbst: the only vector ops we have operate on memory
23:08 airlied: okay llvm backend funcs only needs 7 implicit fn args for basic operation :-p
23:09 karolherbst: ....
23:09 karolherbst: the heck
23:09 karolherbst: 7?
23:09 karolherbst: what ...
23:09 airlied: yeah, exec_mask, shared_me_ptr, kernel_Args_ptr, block_id, thread_id, grid_size, block_size
23:09 airlied: it's likely I'll need some more :-P
23:09 karolherbst: that sounds like kernel args to me
23:09 karolherbst: not fn args
23:09 karolherbst: :p
23:10 karolherbst: but I guess they just pass it along
23:10 airlied: also I'm unsure how exec_mask handling should work, it's most likely bogus what I'm doing
23:10 karolherbst: how easy we have it as we can just load from uniform and not have to deal with this insanity
23:11 airlied: even loading from uniform I'd have to pass consts_ptr
23:11 airlied: I don't have any global variables
23:11 karolherbst: ahh
23:11 airlied: I might need to figure out how to get them
23:11 karolherbst: why though?
23:12 karolherbst: or is it just because of llvm doesn't allow you to have it
23:12 airlied: just never needed them
23:12 karolherbst: I see
23:12 airlied: and adding them is non-trivial
23:12 airlied: since you have to allocate memory for them
23:12 karolherbst: it's just a pointer, no
23:12 karolherbst: ?
23:12 airlied: and bind it to the global
23:12 karolherbst: but right.. need to store the pointer somewhere
23:12 airlied: might be easier to just pass a global_ptr into every func :P
23:13 karolherbst: yep
23:13 karolherbst: better than 7 args
23:13 jekstrand: karolherbst: Looks like LLVM uses an sext to turn a bool into 0/-1 for us
23:18 jekstrand: karolherbst: Looks like we might actually optimize it all away. That'd be neat.
23:58 airlied: pmoreau: what's stopp the IR stuff from landing?
23:59 airlied: IL stuff