02:30mareko: alyssa: sorry no idea, it looks like you've found some nastiness there
04:15jekstrand: bnieuwenhuizen, airlied: Yeah, I think with the kernel patch, we can solve the problem for fences.
04:16jekstrand: bnieuwenhuizen, airlied: The kernel patch referenced in the MR refereced in #3039 takes a snapshot of the fences on the BO and turns them into a sync_file. Any fences added after that point due to rendering (even if they're the extra fences added by AMDGPU) won't be considered.
04:17jekstrand: bnieuwenhuizen: For us, we can avoid EXEC_OBJECT_WRITE. The problem is that bo_wait and bo_busy don't take it into account so you end up waiting on all the read fences as well. As far as those to ioctls are concerned, we're in exactly the same boat as amdgpu. :-(
04:17jekstrand: I think it's new kernel API time!
06:59udovdh: anybody here knows how to fix the sudden mesa compilation errors?
06:59udovdh: src/amd/vulkan/gfx10_format_table.h:71:25: error: variable ‘gfx10_info_VK_FORMAT_A2B10G10R10_USCALED_PACK32’ has initializer but incomplete type
06:59udovdh: src/amd/vulkan/gfx10_format_table.h:63:25: error: variable ‘gfx10_info_VK_FORMAT_A2R10G10B10_UNORM_PACK32’ has initializer but incomplete type
06:59airlied: udovdh: rm all the gfx10_format_Table.h in your build tree
07:00udovdh: airlied, thanks; a ninja clean did not yet help...
07:00udovdh: but this does!
07:00udovdh: thanks again!
07:03airlied: udovdh: I just worked it out myself 5 mins ago :)
07:04udovdh: maybe change the code so that these header files are deleted/auto generated more often?
07:31MrCooper: udovdh: gfx10_format_table.h is now in the source tree, you had a leftover instance in your build tree from when it was auto-generated
07:31MrCooper: udovdh: clean your build-tree before updating from Git to avoid issues like this
07:33udovdh: git clean -fdx ?
07:33udovdh: thanks for the explanation
07:34airlied: yeah that does nuke your meson config though
07:34MrCooper: ninja clean should suffice
07:34airlied: it doesnt
07:35airlied: since that header is no longer in the fileclist
07:35MrCooper: right, but it does if one always does it before updating from Git
07:43MrCooper: (and assuming no bugs in Mesa's meson.build / Meson / ninja :)
07:44airlied: yeah not sure too many ppl have a clean in their workflow there
07:44MrCooper: I never used to, but I started due to issues like this
07:45airlied: seems a bit overkill even if you have ccache
07:45airlied: i think we used to hack autogen.sh or something before
07:45MrCooper: I'm not looking back
07:46airlied: im more in the hit the same problems as everyone else
07:46airlied: so you hit them first
07:47MrCooper: there's still plenty of other opportunities for that :)
08:01daniels: we could also just rename headers when we move them from gen->src
12:50pcercuei: sravn, do you have any SPI/DBI panels laying around?
13:14ramaling_: danvet: sent https://patchwork.freedesktop.org/series/78038/ for some minor cleanup. Please have a look.
13:38sravn: pcercuei: I have brough some that I never have had time to get connected and working
13:39sravn: I have even some DBI panels that only have 6800 or 8080 interface options
13:42pcercuei: I have a 8080/DBI panel working with my SoC's 8080/DBI controller, using the MIPI DSI code
13:43pcercuei: it doesn't use anything from <drm/drm_mipi_dbi.h>
13:44sravn: Sounds very interesting. Will this give us a proper framewwork for DBI panels?
13:45sravn: On my TODO list is to get my DBI 8080 baed panel workign on a target with only gpios to control the display
13:46pcercuei: Right now I'm working on splitting tiny/ili9341.c into a proper drm_panel driver that uses the DSI framework, plus a DSI host driver using SPI, plus a TinyDRM driver for DBI/DSI panels
13:47pcercuei: But I lack the hardware to test
13:48sravn: It will take me a couple of weeks before I have Linux time again (day time stuff plus family stuff)
13:49sravn: But when I resurface I can try to get my raspberri pi working with the ili9341 that I should have with kernel proper
13:49sravn: And then I could test your patches
13:50sravn: But try to ask Noralf for help, he already have all this stuff running. That may be a quiker route for feedback
13:51alyssa: mareko: Bleh, ok. Can you confirm that glmark2-es2 -bshading:shading=cel reproduces on AMD?
13:55MrCooper: any particular reason IGT doesn't use MRs yet?
16:23austriancoder: what about a drm based solution to export workload stats of gpu components to userspace - would be something like this be wanted/accepted?
16:27ElBarto: probably a stupid question but I can't find the answer
16:28ElBarto: what is the "surfaceless" platform ?
16:28ElBarto: meh, I guess docs/specs/EGL_MESA_platform_surfaceless.txt have the answer
16:30ElBarto: well not really :)
16:30ElBarto: what is the use case exactly ?
16:35emersion: when you want a headless context
16:35emersion: not tied to x11/wayland/gbm
16:35emersion: (because you don't have these things for instance)
16:36emersion: one use-case is testing
16:36daniels: Weston uses it for its 'headless' backend, where we still want to do rendering, so people can take screenshots, and we can do automated testing on it as well
16:36emersion: another use-case would be a headless compositor accessed from RDP/VNC
16:36daniels: Chromium also uses it with semi-GBM: it uses GBM to allocate buffers then imports those into an EGL surfaceless context as EGLImages, using them as either texture sources or FBO render targets
16:42ElBarto: daniels: so chromium will always uses it or just if supported ?
16:42ElBarto: I've just switch FreeBSD mesa ports to meson and it opened a big can of worms, such worms are default options that we set
16:47austriancoder:stares at intel_gpu_top source code to see how its done there
16:50Kayden: austriancoder: we use perf for this
16:51Kayden: https://github.com/rib/gputop for example
16:53daniels: ElBarto: sorry, that's ChromeOS, not Chromium
16:54jenatali: Hm, is there a reason nir_remove_dead_variables doesn't support nir_var_mem_ubo?
16:56ElBarto: daniels: ah ok, thanks
16:57ElBarto: daniels: so based on what you and emersion said I think that we don't care about that in FreeBSD, unless I'm missing something
16:57ElBarto: at least not by default
16:59daniels: I don't see how surfaceless would be a problem for FreeBSD though, given that it requires exactly zero platform integration or support
16:59emersion: your users might care
17:00ElBarto: it's not a problem, it's just that we want "sane" default (where sane also mean for people who builds everything spent the less time building)
17:00ElBarto: emersion: could be, I'm pretty sure that none of our users care about that tbh
17:00daniels: surfaceless is never a sane default, no
17:01emersion: i've seen quite a few users caring about a remote headless VNC server
17:02ElBarto: this is a build time configuration for libegl or libgbm right ?
17:23linkmauve: The Pathfinder project (https://github.com/servo/pathfinder) apparently enables the GL_GOOGLE_include_directive extension without checking for support; is it planned to support it in Mesa?
17:24linkmauve: If not I’ll try to fix their shaders.
17:24imirkin_: is that like ARB_shader_include_something?
17:24linkmauve: It’s apparently a simple C-like #include, but I have no idea how a driver is expected to load the file as files instead of strings.
17:24imirkin_: yeah, sounds like the ARB thing. no plans to implement that in mesa.
17:25linkmauve: #extension GL_GOOGLE_include_directive : enable
17:25linkmauve: #include "fill.inc.glsl"
17:25linkmauve: It works like that.
17:25imirkin_: that sounds a lot like the ARB thing
17:25linkmauve: How can this ever work?
17:26imirkin_: it was talked about a bunch since some game checked incorrectly for its presence
17:26imirkin_: and thus didn't work on mesa
17:27imirkin_: the solution there was a LD_PRELOAD shim to make glXGetProcAddress return NULL for those functions, which fixed its detection of the ext.
17:29linkmauve: https://github.com/servo/pathfinder/blob/master/shaders/fill.fs.glsl looks like the opposite, it’s used but not checked for.
17:31pepp: ARB_shading_language_include is implemented in Mesa, not sure what's missing to support GL_GOOGLE_include_directive
17:31imirkin_: that's new
17:31imirkin_: i thought we weren't going to accept an impl of it
17:31imirkin_: probably slipped in under the gitlab radar
17:31pepp: tarceri did it a few months back (if I remember correctly)
17:33pepp: s/did/implemented/ - see af432be538e92b8b2a06e422544e5dddef55ebd9
17:37Kayden: well, we didn't really want to
17:37Kayden: but it kind of went in under the "get all the fglrx features so it can just go away already" plan
17:38imirkin_: out of curiousity - did that plan work? is amd no longer producing a non-mesa-based GL driver?
17:42kisak: amdgpu-pro has a proprietary option https://aur.archlinux.org/packages/amdgpu-pro-libgl/
17:46agd5f: imirkin_, not quite, but pretty close. still working on perf optimizations for workstation apps and a few other things, plus all the other higher priority things
17:48imirkin_: agd5f: nice
19:12jenatali: jekstrand (or anyone else who might know): I'm seeing some stupid int64 behavior around phis, where a 32bit value and a 64bit constant (value=1) are selected by a phi, then immediately cast to 32bit. That means the 32bit value gets cast to 64bit just for the phi only to get cast back down to 32bit. Any idea if there's a pre-existing pass that'll split that into 2 32bit phis?
19:13jekstrand: I don't think there is.
19:13jekstrand: And, yes, it's a bit stupid
19:14jenatali: Cool, guess I have fun pass to try and write
19:14jekstrand: I've wanted for a while to have a pass which tries to propagate alu-of-phi to phi-of-alu or vice versa.
19:14jekstrand: That's kind-of what's going on here
19:14jekstrand: Or maybe just a pass which lowers away 64-bit phis
19:14jenatali: Yeah that's what I was going to go for
19:15jekstrand: Depends on how heuristic you want it to be
19:15jenatali: Just split before the phi and recombine after, then let algebraic optimizations figure out if any of that can be dead
19:15jekstrand: That seems pretty reasonable to me
19:15jenatali: I'll give it a try
19:16jekstrand: It'd be useful in our driver as well. Currently we ensure that the back-end compiler has enough 64-bit support, even on platforms that don't natively support 64-bit, to handle phis.
19:16jenatali: Hitting a weird problem where a 64bit phi works if that's the only kernel I run on our software driver, but running it in a larger test pass it doesn't work and ends up with all threads reading the same value
19:17jenatali: I'm largely guessing it's a 64bit phi problem, but I know we'll want to be able to produce shaders without any 64bit values anyway so *shrug*
19:18linkmauve: Hi, I was playing a Dolphin game, and suddenly anv said: INTEL-MESA: error: ../src/intel/vulkan/anv_batch_chain.c:1691: execbuf2 failed: No space left on device (VK_ERROR_DEVICE_LOST)
19:18linkmauve: How can it be ENOSPC? oO
19:19linkmauve: The image is frozen, but the sound continues to work, and I can continue to use any other application just fine.
19:22daniels: alyssa: ^ seeing bitsize through phis RTYI
19:22Kayden: linkmauve: a couple of folks on the team ran into that this week as well
19:24Kayden: fjdegroo and mslusarz were tracking down exactly what was making the kernel grumpy, if I recall
19:25Kayden: ah, https://gitlab.freedesktop.org/drm/intel/-/issues/2003
19:29linkmauve: Thanks. :)
19:56alyssa: daniels: Wee.
19:58alyssa: Slightly different issue but yes.
20:20jekstrand: jenatali: Yeah. Phis are the biggest thing currently missing for complete int64 lowering in NIR.
20:21jekstrand: linkmauve: Yeah.... I have no idea how that's even possible. But we've hit it this week.
20:21jekstrand: linkmauve: Is this a regression in mesa? Regression in the kernel? Unknown?
20:40linkmauve: I can fairly easily reproduce it, in under ten minutes I’d say, I could compare with older Mesa.
20:40linkmauve: Older kernel would be somewhat harder, but I just upgraded to 5.7.0 so it might be relevant.
21:00jenatali: Hooray, dropping phis to 32bits solved my problem
21:02jenatali: And the optimizations kicked in nicely and gave me a nice simple shader
21:14jekstrand: jenatali: \o/
21:15jekstrand: jenatali: I think we'd likely get some benefit from such a pass in our driver, so feel free to make an MR against master once you think it's ready.
21:15jekstrand: Andy by "I think we'd get some benefit", I mean, "I was looking at a shader today that would benefit". :-)
21:15jenatali: Cool, will do. I'm wondering if it makes sense to give it a callback like lower_bit_size so alyssa could use it for mediump too
21:16jenatali: Right now it's just all phis from 64 -> 32
21:16jekstrand: We could also do a uint8_t bitfield of which sizes you want lowered.
21:17jekstrand: But for mediump, maybe a callback is better?
21:17jenatali: Yeah that's what I was thinking, you'd want to inspect the sources a bit more, not just lower all 32bit phis
21:20jenatali: Btw jekstrand if you were curious, I was able to hook up the CL event / async stuff... it's not super pretty :( https://gitlab.freedesktop.org/kusma/mesa/-/merge_requests/112
21:31imirkin_: jekstrand: fwiw we try to avoid 64+ bit phi's in nouveau as well
21:31imirkin_: i wonder if an explicit pass to split it up would solve some corner case issues...
21:45alyssa: jenatali: AFAICT the mediump issue I brought up isn't really about phis as much as some fundamental issues in the glsl lowering pass... I'm worried using a pass like this would just be a bandaid fix for this one shader
21:45jenatali: alyssa: Got it, I'll just stick with 64 -> 32 for now and we can always extend it later
22:18mareko: alyssa: not sure what you mean, but it works ok here
22:18alyssa: mareko: 32-bit bcsel in an otherwise 16-bit frag shader
22:23mareko: alyssa: yes I see that too
22:54jenatali: jekstrand: I'll probably get around to posting an upstream MR for this on Monday, but if you want it before then, feel free to grab it: https://gitlab.freedesktop.org/jenatali/mesa/-/commit/04783373b98b0ddb0dabefc36c0336ca795d2c3d