02:19 Lynne: every time I try to get opencl involved in anything, I remember how bad it is and return to porting everything to vulkan
02:19 Lynne: this time, it's rusticl refusing to acknowledge even lavapipe as a device
02:22 airlied: Lynne: RUSTICL_ENABLE=llvmpipe ?
02:22 airlied: (not lavapipe, since that's vulkan)
02:25 Lynne: I meant llvmpipe, too used to typing lavapipe
02:25 Lynne: but nope, tried all, iris,radeonsi,llvmpipe, devices: 0
02:26 Lynne: this happens on both my machines
02:31 airlied: Lynne: did you put the icd file in /etc/OpenCL/vendors ?
02:55 Lynne: yup, the icd file is picked up fine
02:59 airlied: and you have -Dopencl-spirv=enabled?
03:06 Lynne: ...no
03:06 Lynne: but now it works
03:14 Lynne: about 2.5x slower than what I should be getting, but at least I can test stuff
04:05 mareko: I have a working prototype of passing glXSwapBuffers into glthread and doing it asynchronously, so that we never have to synchronize glthread at the end of every frame, hopefully it's legal
05:06 mupuf: DavidHeidelberg[m]: not the same one, more of a how-to on how to setup a CI system at home
05:07 mupuf: If you want to discuss about Mesa CI, I suggest you propose another workshop
05:08 mupuf: I don't see much use for it honestly, as we are yet to finish implementing everything we talked about
05:28 mupuf: DavidHeidelberg[m]: the point of the workshop I want to organise is to show interested devs how plug-and-play vland easy maintenance valve infra is
05:29 mupuf: Hopefully, we'll have changed the name by then
05:32 mupuf: And implemented our own gitlab runner so that execution in the farm would be transparent to gitlab projects
10:46 penguin42: karolherbst: Oops, sorry about that rustfmt ism
11:37 DavidHeidelberg[m]: mupuf: haha, you stealing my job :D (I submitted LabGrid integration & building a farm with it)
11:38 DavidHeidelberg[m]: XDC 2023, everyone: "bring your Farm to work" :D
11:40 rosefromthedead: looking forward to seeing calebccff rocking up with 30 hotwired phones in a box
11:41 psykose: heh
12:01 alyssa: lumag: gentle ping on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24118
12:50 mupuf: DavidHeidelberg[m]: ha ha!
12:53 mupuf: Why go with labgrid though? It's pretty much the same design as lava... which means yet another indirect job submission system
12:53 zmike: mareko: madmlan
12:57 zmike: the ghost of ajax will surely haunt you for this
13:25 shoragan: mupuf, labgrid intentionally has a very different design compared to LAVA. no dispatcher on the system connected to the DUT, only a relatively simple 'exporter'. most of the logic runs on the client. full support for interactive use via a CLI from a remote client.
13:25 shoragan:one of the initial labgrid authors
13:26 shoragan: DavidHeidelberg[m], do you have a link for the labgrid integration?
13:28 DavidHeidelberg[m]: shoragan: not yet, for now I just tested it talks to each other (switch sockets & stuff)
13:29 DavidHeidelberg[m]: I wired only the gitlab to labgrid not the sending job itself yet
13:35 mriesch: sravn: time for yet another st7789v series :-) should i base on -rc1 or on the v3 of sre 's series?
13:43 shoragan: DavidHeidelberg[m], ah, if you have any questions, we're happy to help in #labgrid
13:43 shoragan: (on libera.chat)
13:45 zmike: MrCooper: do you have an example of how to trigger https://gitlab.freedesktop.org/mesa/mesa/-/issues/9375 ?
13:45 zmike: is this just "run a drm compositor with some egl app" ?
13:54 emersion: sima, if i have a patch which adds a new uAPI which is reviewed + has IGT + has userspace, can i just push it to drm-misc-next?
13:56 MrCooper: zmike: per https://gitlab.freedesktop.org/mesa/mesa/-/issues/9375#note_2003741 , either kwin Git master or wlroots forced to use llvmpipe; don't think clients matter, I understand this is about the compositor's own output
14:19 tyalie: hi. I'm rather new here and I might need some help ^^ I asked yesterday already, but I think that got overlooked as it was in the midst of a conversation. I would like to introduce a new video format to the linux kernel / 4CCs, but I'm not fully sure how the governing rules are around it, who to CC and how likely my endeavors would be if I might do
14:19 tyalie: a post to the ml?
14:21 zamundaaa[m]: zmike: just run the compositor with llvmpipe, it should be immediately visible
14:31 pq: tyalie, I think it should be fine, the requirement for adding DRM pixel formats are much more lax than adding anything else that touches UAPI. Maybe look at the history of include/uapi/drm/drm_fourcc.h?
14:32 pq: tyalie, definitely cc dri-devel@ mailing list, otherwise I don't know. I guess the usual check_maintainers.pl applies, or what was that script that tells you who to cc?
14:32 emersion: tyalie: git-send-email to the ML yeah, CC maintainers and people who touched the file recently
14:35 emersion: also see https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#drm-format-handling
14:36 pq: oh that's where it was written
14:37 pq: silly me was looking at https://www.kernel.org/doc/html/latest/gpu/drm-uapi.html#open-source-userspace-requirements
14:37 emersion: yeah the docs are all over the place :(
14:38 emersion: tyalie: out of curiosity, which format and for which purpose?
14:40 pq: IIRC they wanted a DRM_FORMAT_R32F
14:43 arnd: javierm: it took me a while longer than I had hoped, but I have a new version of the screen_info cleanup at https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=screen-info-v2
14:45 javierm: arnd: great
14:47 javierm: arnd: if you can review my v5 of the FB_CORE split when you have some time, that would be awesome too
14:55 zmike: zamundaaa: is there an easy way to get it to run with llvmpipe? LIBGL_ALWAYS_SOFTWARE doesn't work in this case
14:56 zamundaaa[m]: Yeah, run the whole system with simpledrm
14:57 zmike: ah
14:57 zmike: hm
14:58 zmike: not entirely sure that's feasible for me atm
14:58 tyalie: emersion What pq says. I'm currently working on introducing thermal cameras to libcamera and would need a frame format that can represent temperatures. float 32 would be good enough for most cameras out there
14:58 zamundaaa[m]: zmike: a VM would work too
14:59 tyalie: my hope is, that in the future everyone can just attach one of the supported thermal cameras and do the processing / colorization / ... with e.g. OpenCV or the like
14:59 zmike: maybe something I can aspire to between other things
14:59 zmike: eric_engestrom: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/45709224
14:59 gfxstrand: dj-death: How did registers shake out this morning?
14:59 zmike: not sure what to do about this
15:01 mareko: I find RADV harder to read after clang-format reformatting, it uses a code style that looks like a machine wrote it, not a human
15:02 dj-death: gfxstrand: I started it just before the meeting :)
15:02 pq: tyalie, makes perfect sense to me, FWIW.
15:02 dj-death: gfxstrand: ongoing :)
15:02 gfxstrand: dj-death: Cool
15:02 mareko: Venemo: ^^
15:02 zmike: zamundaaa: hm isn't simpledrm used by default in newer fedora releases?
15:03 emersion: zmike, zamundaaa[m]: wlroots doesn't support llvmpipe, because it requires EGLImage
15:03 emersion: need a new GL ext to make it work
15:03 emersion: (llvmpipe requires EGLSurface')
15:03 zamundaaa[m]: emersion: kwin also requires eglimage
15:04 mareko: Venemo: I would revert the reformatting just to get back to the original Mesa style
15:04 emersion: hm, maybe it works with DMA-BUF + a display-only device
15:04 zamundaaa[m]: zmike: yes it is. It's used if you use the nomodeset kernel boot argment
15:04 emersion: maybe try vkms?
15:06 zmike: I suppose it's too much to ask that this codepath be hit in nested compositors for testing :/
15:11 eric_engestrom: zmike: yeah sorry, I meant to post a comment about cancelling this job but I got distracted
15:12 eric_engestrom: you ran all the jobs in the pipeline for a vulkan-only change, which I assumed was a mistake so I cancelled the test-gl job
15:12 daniels: zmike: did you cancel the job?
15:12 eric_engestrom: sorry about not posting a comment about that
15:12 daniels: ah
15:13 daniels: mid-air collision
15:13 eric_engestrom: :)
15:13 eric_engestrom: zmike: feel free to re-start the job if you really do want these to run
15:13 zmike: it's a zink-only change
15:13 zmike: you canceled literally the only job that was important lmao
15:14 eric_engestrom: haha sorry
15:14 eric_engestrom: but perhaps ci_run_n_monitor could be good to run the jobs that are useful and not the rest :]
15:14 zmike: yeah maybe
15:14 zmike: I'm trying to multitask
15:14 zmike: unsuccessfully
15:15 zmike: in the future though please don't randomly cancel other peoples jobs
15:16 mupuf: shoragan: Thanks for sharing :) I may have misunderstood, but since you need console drivers, doesn't it mean you still send commands and parse the output, like lava does?
15:17 mupuf: And you still rely on rootfs too... Which makes integrating with CI pipelines annoying at best :s
15:18 eric_engestrom: zmike: yeah sorry, I shouldn't have done that indeed
15:19 Venemo: mareko: I'm sorry about your frustrations with the style
15:19 Venemo: is there anything specific we can improve in it?
15:19 arnd: javierm: I've rebased my randconfig tree on top of linux-next now and applied your patches on top to give them some more testing. It all looks good to me already, will reply once the build system confirms that, or it finds a bug
15:20 mupuf: It's a neat project, and it seems perfect for development purposes. Just not sure about using it in a CI environment since there doesn't seem to be much in the way of verification that the DUT is the one you wanted to run on, same for the serial console
15:20 javierm: arnd: perfect, thanks a lot!
15:22 emersion: hm, so i'm running wlroots with vkms and llvmpipe but it required a fair amount of env vars
15:22 emersion: let's try to see if i can simplify the process
15:24 mareko: Venemo: there 2 issues: 1) the placement of line breaks, which can be disabled by setting the column limit to 0, which doesn't touch line breaks determined by the user, but the current line break changes made by clang-format would have to reverted, 2) every line of multi-line expressions is not indented equally, which doesn't have a known solution AFAIK
15:26 mareko: we reformatted radeonsi by clang-format long before this was a thing to get rid of tabs, and we have been manually reverting some of the changes clang-format made
15:27 shoragan: mupuf, yes, we use the console for remote control, but the code to do that runs on the "client", the CI runner in your case, so is easy to update. alternatively, you can use SSH to the DUT.
15:28 mupuf: shoragan: wait, where is lava's code running then, if not "the client"?
15:29 shoragan: in contrast to lava, we usually provision the full software to the DUT (including the bootloader) via USB or network, so we are always sure we know exactly which SW we're testing.
15:29 mupuf: That is indeed the way to go!
15:29 cambrian_invader: anarsoul|2: from what I can tell the BO is allocated as a dumb buffer, which means the kernel is aware of the width/height/bpp
15:30 shoragan: mupuf, LAVA has the concept of a dispatcher. the scheduler assigns a job definition (basically a custom yaml-based DSL) to the dispatcher. the dispatcher the runs local python code to process the steps in the job definition one by one. when it's done, it pushes the results back to the scheduler
15:30 cambrian_invader: is xf86-video-armsoc supposed to do the alignment?
15:30 mupuf: shoragan: in the infra I develop, the code runs on the DUT itself. The console is for feedback only (or interactive sessions)
15:31 shoragan: so there is no direct communication beween the client (i.e. CI runner) and the dispatcher during the job execution
15:31 cambrian_invader: I don't see other utgard drivers in that repo doing any alignment
15:31 mupuf: shoragan: great, same in the infra I work on :)
15:32 mupuf: You can restart the service, and the jobs keep running
15:32 mupuf: Practical for live-updates
15:32 cambrian_invader: that said, I also tried with a different window size (naturally 16x16 aligned) and I saw some errors
15:32 cambrian_invader: so there is more to debug besides this...
15:32 shoragan: mupuf, LAVA's architecture precludes interactive use, though, as everything has to go through job definitions
15:33 shoragan: even with lava you often have a process on the CI runner waiting for the results though, so runner updates aren't much easier in practice
15:34 cambrian_invader: e.g. https://gitlab.freedesktop.org/xorg/driver/xf86-video-armsoc/-/blob/master/src/drmmode_exynos/drmmode_exynos.c#L121 aligns the stride but not the height
15:34 cambrian_invader: I assume that is for utgard
15:34 shoragan: we have test-cases where SW on the DUT itself is not enough (like audio/video input/output_)
15:35 mupuf: shoragan: that's interesting, care to share?
15:36 mupuf: In IGT, we controlled the screen emulator directly from the DUT
15:36 shoragan: the labgrid Drivers are here: https://github.com/labgrid-project/labgrid/blob/master/labgrid/driver/usbaudiodriver.py https://github.com/labgrid-project/labgrid/blob/master/labgrid/driver/usbvideodriver.py
15:37 shoragan: but I don't have a public test suite for that, sorry
15:38 shoragan: mupuf, ah. as we're more product-focused, we try keep the SW as close to the release version as possible, so avoid test instrumentation on the DUT
15:38 dj-death: gfxstrand: fossils look good on 5 platforms (skl, icl, tgl, dg2, mtl)
15:39 dj-death: gfxstrand: it's either a draw or a slightly spill/fill improvement on a couple of apps
15:39 emersion: hrm, MESA_LOADER_DRIVER_OVERRIDE=swrast dies with "libEGL fatal: did not find extension DRI_IMAGE_DRIVER version 1"
15:39 shoragan: that one's for video cameras. for display output we're hoping to integrates marex' https://www.youtube.com/watch?v=ncnM8K6A1l4
15:39 zmike: LIBGL_ALWAYS_SOFTWARE=1
15:39 zmike: swrast isn't a real driver
15:40 emersion: LIBGL_ALWAYS_SOFTWARE=1 doesn't work with EGLDevice
15:41 zmike: 🤔
15:41 emersion: libEGL warning: Not allowed to force software rendering when API explicitly selects a hardware device.
15:41 emersion: i should probably add a way for wlroots to select the software rendering device
15:42 emersion: but then… not sure how DMA-BUF stuff would work…
15:44 emersion: it doesn't seem like mesa uses llvmpipe with vgem :/
15:44 zmike: llvmpipe doesn't support dmabuf
15:46 emersion: well, it does
15:46 emersion: llvmpipe + vkms gives me DMA-BUF support
15:46 emersion: llvmpipe + vgem doesn't
15:52 mupuf: shoragan: right, there can be some cases where you indeed want to test from the outside
15:53 mupuf: I'll keep that in mind when I'll be ready to remove this possibility in the infra I work on. Can be useful as an opt-in
15:53 mupuf: Thanks for spending the time to answer my questions! Much appreciated
15:54 shoragan: mupuf, we also use these options often for interactive development, as we use the same boards in the farm for development and CI (over night)
15:54 shoragan: (which was the main reason for starting labgrid instead of using lava)
15:56 gfxstrand: dj-death: \o/
15:57 mupuf: shoragan: yeah, easy interactive access to boards is a MUST HAVE!
15:57 shoragan: :)
15:59 dj-death: gfxstrand: let me just look at the write_mask thing
15:59 gfxstrand: There was a write_mask thing?
16:03 sravn: mriesch: I saw you posted the patches - good. Will try to take a look at them
16:04 austriancoder: zmike: does your MR affect # of draw_vbo() calls?
16:04 zmike: no
16:04 austriancoder: zmike: without our MR I get 6 calls to draw_vbo() with our MR I only see 1 - the state emitting per se looks fine
16:05 zmike: 🤔
16:05 austriancoder: lets see what happens
16:06 mriesch: sravn: yeah i figured that one part of the patches applies on both sre 's series as well as on rc1, so i split that off. sorry for the noise here
16:07 mriesch: and thanks, feedback will be appreciated
16:11 MrCooper: emersion: how about MESA_LOADER_DRIVER_OVERRIDE=kms_swrast ?
16:12 emersion: MrCooper: it tries to allocate dumb buffers
16:12 emersion: this fails on vgem
16:12 emersion: ... maybe that's what's used on vkms
16:13 emersion: hm, I don't even know, is vgem able to allocate memory?
16:18 gfxstrand: [wu
16:44 karolherbst: how can I get `MESA_LOADER_DRIVER_OVERRIDE=nouveau` to work in a meson devenv?
16:44 karolherbst: ehh wait.. seems to be my mistake, but uhhh.. the runtime behaves weirdly
17:12 alyssa: gfxstrand: uw]
17:17 DodoGTA: uwu
17:18 gfxstrand: dj-death: Does your "looks good" count as an RB?
17:23 dj-death: gfxstrand: still reading a bit through the vec4 changes which I'm not super familiar with
17:39 arnd: javierm: I get a merge conflict against d2aff54834766 ("fbdev/hecubafb: Select FB_SYS_HELPERS_DEFERRED"), if you rebase it's probably easier to leave CONFIG_FB_HECUBA in drivers/video/fbdev/Kconfig
17:40 dj-death: gfxstrand: rb
17:40 arnd: javierm: it's actually a driver symbol, not a core one
17:41 arnd: FB_MACMODES should also remain there I guess
17:47 javierm: arnd: you got a merge conflict with v4 or v5? I thought that rebased on top of Thomas' series
17:48 javierm: arnd: I see. Since wasn't inside the "Frame buffer hardware drivers" sub-menu, I assumed that was a core symbol
17:49 javierm: arnd: probably need in v6 a preparatory patch to move those inside that menu ?
17:51 lumag: alyssa, in ~7hrs the test will finish. Looks good up to now.
17:53 alyssa: lumag: jeez, running a full cts-runner run?!
17:53 lumag: yep
17:53 lumag: simple/limited tests worked so far
17:58 alyssa: cool, nice
17:59 alyssa: not so bad for a patch written with my eyes closed and hands behind my back, metaphorically
18:01 zmike: smh not doing it literally
18:07 zmike: cmarcelo: it seems like the recent nir print reworks lost some xfb info that used to be printed?
18:09 cmarcelo: zmike: oh, let's fix that. is there a particular test that I can see / not see it?
18:10 zmike: uhh something like 'dEQP-GLES3.functional.transform_feedback.array.separate.lines.highp_uvec2' has some simple shaders?
18:10 zmike: don't have a vk one handy
18:14 cmarcelo: zmike: I'll check that
18:49 cmarcelo: zmike: going back before my patches I'm always seeing store_output with xfb() and xfb2()... is that information you are talking about?
18:50 zmike: yeah I think so
18:50 zmike: would be great to get as much xfb info printed as possible
18:51 cmarcelo: from a glance seems unrelated to my patches. I'll see if I can find some example that actually shows something.
19:09 enunes: alyssa: ok... I think I got ppir to kinda work, but it's not pretty, unfortunately it seems that as-is ppir relies on instruction emit to initialize a register so I need to create some dummy node for load_reg otherwise it gets lost
19:10 enunes: it also relies on func->reg_alloc to know which indices are registers and does some crazy per-component tracking on those indices, this is probably still wrong in my implementation and is likely working by luck
19:13 enunes: I'm not sure if I can get rid of that now since everything comes as ssa as in func->ssa_alloc and that per-component tracking is not needed anymore?
19:17 alyssa: cmarcelo: store_output xfb isn't set by the frontend
19:17 alyssa: drivers may call nir_io_add_intrinsic_xfb_info if they want that populated
19:18 alyssa: radeonsi, panfrost, and asahi do that
19:18 alyssa: but it's but it's not core to how nir xfb works, it's just a driver convenience
19:18 alyssa: nothing to do with nir_print
19:19 alyssa: (should nir_print be printing the nir_xfb_info data structure that frontends set and that nir_io_add_intrinsic_xfb_info reads in? possibly!)
19:20 alyssa: enunes: why does ppir rely on instruction emit initializer a register?
19:20 alyssa: load_reg is supposed to get lost by the backend, if you're using nir_legacy or chasing helpers
19:20 alyssa: like, in your emit_intrinsic, if you see a load_reg/store_reg/decl_reg you should just return early and pretend it's not there
19:20 alyssa: and since ppir actually has an IR and isn't, say, doing RA in NIR .. that should work ok?
19:21 alyssa: the reg_alloc tracking does indeed sound like it'd be wrong. let me see what it's doing
19:21 alyssa: could you point me to where that tracking is?
19:22 alyssa: is that comp->var_nodes?
19:23 alyssa: oh.. ok
19:23 enunes: alyssa: because well... it does, it uses the dest of that instruction to initialize this var_nodes structure which contains a reference for who wrote it (last?)
19:23 alyssa: yeah, I see this now
19:24 alyssa: ignoring whether var_nodes is a good idea, the easiest way to port this to nir_legacy is to allocate (num_ssa << 2) * sizeof(ppir_node *)
19:24 alyssa: instead of ((num_reg << 2) + num_ssa) * sizeof(..)
19:24 alyssa: and removing comp->reg_base (since now it's all mingled, but that's ok)
19:24 alyssa: and then I think that should work
19:25 enunes: this <<2 hack is kinda what I have now for it to get it to work :)
19:25 alyssa: and the funny dance in ppir_node_add_src is just based on the nir_legacy_src instead
19:25 alyssa: yeah, ok
19:25 alyssa: it's not ideal but, var_nodes was probably hack #1 ;)
19:25 enunes: I'm ok with something not pretty to get lima out of your way and then we followup with the needed rework on this
19:25 alyssa: sure
19:26 alyssa: there's nothing /wrong/ with bloating up var_nodes, just memory usage of the compiler
19:26 alyssa: otoh, given lima is gles2 hw and its vertex shaders have a 512 instruction limit.. I am not worried about that personally ;-p
19:27 alyssa: tbh I don't understand this var_nodes stuff, I guess ppir is some sort of dag-based IR? pretty progressive :'o
19:27 enunes: I suppose nobody understands this var_nodes stuff, we really need to get rid of it
19:28 alyssa: heh
19:28 alyssa: blame goes all the way back to "gallium: add lima driver"
19:28 alyssa: :~)
19:31 alyssa: hopefully gpir will be easier, since it's just a direct translate!
19:32 enunes: I still get some crash on ralloc_free sometimes so I guess I will need better hack for var_nodes
19:33 alyssa: i can eyeball the patch if you push
19:33 austriancoder: DavidHeidelberg[m]: how does the new flow looks like when I want to change something in gfx-ci/linux (and create an MR.) and wanto tu use the kernel artifacts in mesa ci?
19:37 enunes: alyssa: https://gitlab.freedesktop.org/enunes/mesa/-/commit/019b79bf5b16dee5e4e623c9d88dc35830f2445b
19:39 alyssa: enunes: comp->reg_base is still used there, it should be removed
19:40 enunes: indeed, that might be the reason
19:41 alyssa: if (!instr->dest.is_ssa)
19:41 alyssa: this will never happen, was this intended?
19:41 alyssa: node = block->comp->var_nodes[instr->src->ssa->index];
19:42 alyssa: this index needs to be "<< 2"'d, since the indexing is changed now
19:42 alyssa: (Probably you want a safe helper to access var_nodes given an ssa def or a register+channel)
19:43 alyssa: (*that* seems more likely to be the crash causer)
19:45 alyssa: enunes: also, I see you have backend NIR passes that run after legacy_trivialize
19:45 alyssa: that may or may not be safe
19:45 alyssa: if that wasn't intentional, I would place the trivialize call after all the duplicate* passes, right at the end before nir_sweep
19:46 alyssa: (I would need to audit the lima_nir_duplicate_load_* passes to figure out if it's safe to trivialize first... but certainly trivialize was designed to run at the very end)
19:48 enunes: I put it before our last dce as I saw in the a2xx implementation, now I'm not sure we can run dce after those duplicate passes
19:49 enunes: I guess I can just put it after everything?
19:55 alyssa: yeah
19:55 alyssa: "dce, then duplicate, then trivialize" should be safe
19:56 alyssa: "dce, then trivialize, then duplicate", I don't know if that's safe, I'd have to check the duplicate impl
19:57 enunes: I'll put trivialize after everything for now, if shader-db is too bad later I can go back and check if it is worth moving it around
20:11 alyssa: :+1:
20:11 alyssa: probably no changes
21:35 DavidHeidelberg[m]: austriancoder: you do changes in gfx-ci/linux push patches & stuff, tag it, it generates artifacts with the tag and you use the tag in .gitlab-ci/tags.yml in Mesa
21:35 karolherbst: airlied: f281290005119ddd2dc82e0b7a4cc22551d7fc71 broke some CL atomic stuff :'(
21:36 karolherbst: LLVM IR validation fails
21:39 karolherbst: https://gist.github.com/karolherbst/4272e7e1fd94181798067c18f3fb8a6e
21:39 DavidHeidelberg[m]: austriancoder: there is also open MR which I plan to adapt zo leverage this workflow without rebuilding the Mesa containers (so you could just inject your kernel)
21:41 airlied: woah did someone write win virlg support, finally
21:42 karolherbst: airlied: the test breaking is `piglit/bin/cl-program-tester piglit/tests/cl/program/execute/builtin/atomic/atomic_xchg-global.cl`
21:42 karolherbst: it's weird though as I didn't see anything with the CTS coming up on my other machine...
21:42 karolherbst: maybe it works with llvm-16?
21:43 karolherbst: indeed...
21:43 karolherbst: yeah, so with llvm-16 it works, with llvm-15 it crashes
21:44 airlied: ah yes opaque ptrs probably saves llvm16
21:44 karolherbst: yeah
21:44 karolherbst: I don't know why that change was made though
21:44 karolherbst: but in any case, seems some float vs int problem
21:45 karolherbst: eric_engestrom pinged me on this, because that commit was to be picked for the next 23.1 release
21:45 airlied: I'll take a look today, though I don't have any llvm15 installs left :-P
21:46 karolherbst: heh
21:46 eric_engestrom: airlied: if it helps it also fails on 13 :P
21:46 karolherbst: I think Dave wanted to say, that all machines got upgraded to fedora 38 already :P
21:46 eric_engestrom: I know :P
21:47 karolherbst: I was lazy, so on my laptop there is still fedora 37 running :D
22:13 cmarcelo: alyssa: I wonder what could be the regression zmike is referring to then. anyway I'll check if calling the function just to fill up stuff here shows me something.
22:24 alyssa: cmarcelo: ?
22:26 cmarcelo: alyssa: nir_print vs xfb. I was assuming there was a regression that caused info to not be there, but maybe that's not the case.
22:58 alyssa: oh