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