02:53 airlied: jekstrand, zmike, bnieuwenhuizen : anyone understand how vulkan instance api version and extensions are supposed to interact where the loader is 1.2 but the ICD is only 1.0
02:54 airlied: I think zink needs to always create instances as 1.0
02:55 airlied: and just list all the exts it needs
02:56 airlied: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4371 is where I'm working it out :-P
03:00 imirkin: linkmauve: sure. some drivers use sw tnl + hw frag. you could do the opposite. but sync between cpu and gpu to make it all happen would destroy any potential benefits -- vs is not where the heavy work is done.
03:15 jekstrand: airlied: Uh....
03:15 jekstrand: airlied: There was a bunch of discussion about this around the 1.1 release and again around the 1.2 release and I know there are rules but I don't remember what they are
03:15 jekstrand: airlied: I do know that the physical device reports a version that's different from the instance version.
03:16 jekstrand: But I don't remember how they're supposed to interact
03:16 jekstrand: airlied: Or you could just implement 1.2. :P
03:20 airlied: jekstrand: yeah I've reread it all and I think the result is if your app supports creating a 1.0 vulkan instance, it should just create a 1.0 vulkan instance
03:20 airlied: you can get convoluted and create an instane, get phys dev props to get the phys dev version, then tear it down and start a new instance with the version
03:22 airlied: jekstrand: for ages lvp has been exposing a 1.2 instance version, when I ported to the C code I fixed that and zink fell apart :-P
03:22 airlied: I'll eventually get to 1.2, still have a lot of 1.1 to go
04:21 jekstrand: airlied: Yeah... Multiview...
04:43 airlied: jekstrand: and subgroups
08:42 haasn: In file ../src/compiler/spirv/spirv_to_nir.c:1073
08:42 haasn: Decoration not allowed on struct members: SpvDecorationRestrict
08:47 haasn: trying to figure out if this is a bug in mesa or in glslang
08:49 haasn: hmm
08:49 haasn: "Khronos SPIR-V Issue #408: (Re)allow the decorations Volatile, Coherent, NonWritable, and NonReadable on members of blocks. (Temporarily dropping this functionality was accidental/clerical; intent is that it has always been present.)"
08:50 haasn: maybe they forgot to include Restrict in this list?
08:58 haasn: https://github.com/KhronosGroup/SPIRV-Registry/issues/97 seems like a mismatch between what's allowed in GLSL and what's allowed in SPIRV
09:00 danvet: tzimmermann, [PATCH] drm/gem: add checks of drm_gem_object->funcs <- I thought everyone got converted over?
09:13 danvet: mlankhorst_, I have a patch for -fixes
09:14 danvet: pls pong when I can push
09:31 linkmauve: imirkin, it’s more like fixed pipeline for fragments, than pure software.
09:32 linkmauve: And I’m not doing pattern matching on shaders to see how to configure the pipeline. ^^'
09:35 mlankhorst_: danvet: can I push rc1 there?
09:36 mlankhorst_: I don't see it in drm/drm-fixes yet
09:36 danvet: yeah if you don't need a backmerge it's fine
09:37 danvet: also pushing -rc1 to -fixes right now
09:40 mlankhorst_: done
09:49 tzimmermann: danvet, which patch? do you have a link?
09:51 danvet: tzimmermann, it's on dri-devel
09:51 danvet: https://lore.kernel.org/dri-devel/20210228211956.2363-1-tobias.klausmann@freenet.de/T/#u
09:53 tzimmermann: danvet, everything should be converted now
09:53 tzimmermann: that's a radeon bug AFAICT
09:55 danvet: uh that was actually wrong archive link
09:56 tzimmermann: i already replied
10:04 danvet: looked a bit, I think it's actually gerd hoffmann
10:04 danvet: your patch simply made stuff oops instead of leak
10:41 emersion: xexaxo1, daniels: added more details https://gitlab.freedesktop.org/mesa/mesa/-/issues/4178#note_822058
11:42 karolherbst: curro: any preference on how to fix llvm-12 support? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8543 I've posted a patch below making use of compat.hpp, but as the author doesn't repsond anymore I am wondering what your preference is :/
14:30 emersion: who should i cc for loader and internal egl logic?
15:16 jekstrand: jenatali: read/write_mem_fence is now fixed in upstream SPIRV-LLVM-Translator
15:22 Sumera[m]: danvet, melissawen: Tried this patch(https://paste.ubuntu.com/p/gNKzXWh6qB/) for duplicating the vkms_crtc functions; tests seem to work
15:23 Sumera[m]: however rn, virtual_atomic_disable/enable/begin are sort of entirely empty because we don;t have any vblanking going on
15:29 danvet: Sumera[m], I think you can outright leave out entirely empty functions for the _funcs structure
15:30 danvet: so saves a bunch more noise and makes it clearer
15:30 danvet: and yeah I think this gives us much neater code flow by pulling all the decisions out into a single place
15:32 Sumera[m]: danvet: fair, will do that
15:33 melissawen: +1
15:34 melissawen: Sumera[m], danvet also, we still need send_vblank_event in virtual_hw _flush for consistency, right?
15:34 danvet: yeah
15:34 danvet: but that was also an issue I think with the rfc patch
15:34 daniels: emersion: thanks for the details, but I'm not working atm and not sure when I'll be back and certainly don't have a fixed time before I'd be able to contribute. please just move forward with whatever looks best & I'll do what I can when I can
15:35 danvet: melissawen, otoh I though per discussion with sumera this happens automatically
15:35 danvet: but really not sure, I forgot those details again :-)
15:35 emersion: daniels: ah, ok, no problem. do you know who i could cc on this issue?
15:36 daniels: emersion: I'd probably try lynxeye + MrCooper I guess?
15:36 danvet: yeah anyone who uses kmsro
15:36 danvet: mripard for vc4 maybe too
15:36 emersion: makes sense, thanks!
15:37 danvet: maybe anholt has a good idea on this too
15:37 Sumera[m]: melissawen: oh yes, I totally forgot that. will add
15:37 jwalts: I have a simple fragment shader that fails NIR validation after glsl_to_nir, is there someone in particular I should ping? I reduced it to just "outFrag = ( mat2(v) - mat2(1.) )[0]"
15:38 danvet: Sumera[m], melissawen looked again, and the fake vblank stuff respectively drm_crtc_state->no_vblank does this all already for us
15:38 danvet: so really not needed, sumera's rfc code is correct
15:38 daniels: emersion: np, thanks for picking it up
15:38 danvet: 7beb691f1e6f3 <- very recent patch from tzimmermann that made this happen
15:38 danvet: oh actually 1 year old
15:39 danvet:stuck in 2020 still
15:39 melissawen: danvet, afaiu, fake_vblank in commit_tail is cleaning up any remaining send_vblank for no_vblank mode; I would know if we also need to send on flush for consistency
15:39 melissawen: or it is redundant
15:41 danvet: melissawen, would be redundant
16:10 jenatali: jekstrand: \o/ thanks!
16:16 jekstrand: yw
16:17 jekstrand: Fixing it wasn't too bad. The unit test mechanism they have is actually pretty slick.
16:17 jekstrand: We should think about cooking up something like that for NIR.
16:18 jekstrand: It's sort-of similar to what we have today with count_intrinsics etc. in the vars unit tests
16:18 jekstrand: But it's just a text file which is helpful
16:19 jwalts: jekstrand: are you the right person to ask about glsl to nir translation issues?
16:19 jekstrand: Sure
16:20 jenatali: jekstrand: Yeah I like their test suite style
16:20 jwalts: jekstrand: this is failing to validate after translation (simple frag shader) outFrag = ( mat2(v) - mat2(1.) )[0], I believe it's due to mistranslations from mat type
16:21 jekstrand: jwalts: Can you show me a dump of the NIR?
16:21 jwalts: it's a reduced test, not a real one
16:21 jekstrand: It should dump on validation failure
17:35 MrCooper: ugh, did alyssa push a fn-verify-982374324 branch to the main Mesa repo, or someone else?
17:35 imirkin: i don't see it at https://cgit.freedesktop.org/mesa/mesa/refs/heads
17:36 daniels: MrCooper: it was nroberts, and it's gone https://gitlab.freedesktop.org/mesa/mesa/
17:36 daniels: (hmm, link not right, but go to the activity page -> push events)
17:36 nroberts: oh no sorry, did that break something?
17:37 nroberts: it was temporary to prove that I am a mesa developer in order to register #videocore
17:38 nroberts: I should have asked first, sorry
17:38 imirkin: it's fine if there's good reason -- some people push by accident and it's annoying since it pollutes the overall list
17:38 imirkin: (perhaps it also has some CI implications, dunno)
17:45 MrCooper: yes, it creates a pipeline: https://gitlab.freedesktop.org/mesa/mesa/-/pipelines/277688
18:01 anholt: pepp: looking at piglit timeouts
18:07 pepp: anholt: ok, thanks
18:12 alyssa: dschuermann: OOI what balance of time do you spend in NIR vs ACO?
18:14 pendingchaos: I tested a while ago and I think around 11% of compilation was spent in ACO
18:14 pendingchaos: that was including spilling, which is uncommon and very expensive
18:15 alyssa: That explains the focus on NIR optimizations then, I guess :)
18:18 dschuermann: well, just the number of passes done in NIR vs ACO is bz a different factor
18:18 dschuermann: ACO has very few but more expensive passes
18:19 tzimmermann: danvet, melissawen, Sumera[m], drivers will get a fake vblank event by default. no need to do anything. but registering a vblank will make the driver responsible for the vlbank event
18:20 tzimmermann: anything else would be a bug
18:21 alyssa: dschuermann: Fair.
18:23 alyssa: dschuermann: As the name suggests, my branch `dump2` has high quality code =P
18:26 Sumera[m]: tzimmermann: ah, okay, that sounds fair, thanks for explaining.
19:10 Kayden: mareko: you were planning on making create_stream_output_target() happen in the TC thread rather than sync'ing and happening in the driver thread, right?
20:01 anholt: pepp: I've got to say, two minute piglit runs on softpipe are pretty nice.
20:01 anholt: and no piglit-summary-html
20:10 jenatali: On Linux is there a good way to redirect stdout for an app that you can't launch straight from the command line (e.g. Steam)? I'm trying to find a way on Windows and failing so far
20:11 jenatali: I'm wondering how useful it'd be to add an alternative output for things like nir validation - I'd love to see it in Windows's OutputDebugString for instance
20:11 imirkin: jenatali: why can't you launch it from cmdline?
20:11 jenatali: Well specifically I'm looking at Runescape, which has a launcher that has to launch it
20:12 imirkin: the launcher has full control over what it does with the secondary binary
20:12 imirkin: including redirecting stdout to /dev/null
20:12 imirkin: if it so chooses
20:12 imirkin: and there's not much you can (easily) do about it
20:12 imirkin: however usually that stuff will just get passed through...
20:13 jenatali: Yeah I guess I could try redirecting the launcher's stdout and see if I get the game's too... seems fragile though
20:13 imirkin: stdout is just a file descriptor. when you execve, you can point it whereever you want
20:14 imirkin: one can add a LD_PRELOAD thing which hooks into execve and sets things up differently
20:14 jenatali: Not that simple on Windows ;)
20:14 imirkin: it'd be very unusual to not just pass stdout/stderr through though
20:14 imirkin: yeah, on windows, iirc stdout causes a little cmd window to appear
20:14 imirkin: so people try to suppress it
20:15 jenatali: Nah that's based on the exe's subsystem. You can write to stdout from a "window" application, you just won't see it unless it's redirected
20:15 imirkin: ah
20:15 jenatali: The CreateProcess API has a spot for specifying what the new process should use for its stdout/stderr handles, so it's a bit more in-your-face that you should decide rather than passing things through
20:16 imirkin: my knowledge of windows dates to ... ancient times.
20:16 imirkin: and it wasn't that good even in those ancient times
20:16 jenatali: Yeah I don't expect people here to know the details, I was just curious what practice on Linux for you guys
20:16 imirkin: on average, pass it through. if you're not passing it through, you're doing something special
20:18 imirkin: since the average way to launch is to fork + exec, which means that the child process inherits whatever stdout/etc you had before
20:18 jenatali: Yeah makes sense
20:18 imirkin: you'd have to perform additional actions to lock fd's down
20:20 jenatali: Makes sense. I might see about hacking in an option to either output straight to file (I recall someone did that for nir_print) or OutputDebugString
20:46 FLHerne: jenatali: Steam has a field where you can edit the application-launch command, including setting env vars or adding redirects, at least on Linux
20:47 jenatali: FLHerne: Oh you're right, I forgot about that, that's handy. RuneScape doesn't though :P
20:53 FLHerne: jenatali: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2043 includes some dumping of nir to not-stdout, but KHR_debug probably doesn't help with your problem
20:56 jenatali: FLHerne: That's also Intel-specific apparently
20:57 imirkin: zmike: re 6a8c51dc5a4 -- couldn't minx be > maxx after the clamping? in nouveau i did >= for the bail condition
20:59 Kayden: would someone be able to give a quick review to https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9346 ? trying to fix a bunch of i915 breakage from mareko's recent optimizations
20:59 Kayden: it's a pretty simple fix
21:00 Kayden: (call this before using the value everywhere it's used....except oops, we missed 2 cases in tnl)
21:01 imirkin: Kayden: does that analyse function cache its result?
21:02 Kayden: yeah, the function is badly named, it updates the inverse matrix
21:02 Kayden: https://gitlab.freedesktop.org/kwg/mesa/-/commit/10371c520c1841006795f0a113ae14194dfbf31e was the change that broke things
21:03 imirkin: right. i was just too lazy to look up whether it recomputed each time :)
21:03 imirkin: if it does the conversion each time, it would get expensive
21:05 Kayden: I don't think it does, there are dirty bits for which pieces need to get updated.
21:05 Kayden: thanks!
21:05 anholt: padovan: throwing together an MR for more deqp on your new CI farm
21:06 zmike: imirkin: I guess technically I'd need to clamp the mins to fb size too so that all the values would match...
21:06 imirkin: zmike: or just change it to >=
21:07 zmike: well it's still incorrect now if somehow there's a region where the mins are outside the fb
21:07 imirkin: zmike: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nv50/nv50_surface.c#n541
21:07 zmike: yes, I understand the concept :)
21:07 imirkin: ;)
21:09 Kayden: anholt: looking at a i915 regression where arb_point_parameters-point-attenuation crashes, and tracked it down to your recent swrast changes - if I revert 9c38cbbb968b8a856de1862b0bc321d42d709ac1, 23bb92c4f683f5e286af8f5c1bfc50204bd5ea1e, f1403d66d40c39bb0aab3732e6f641282cf7eb14 it passes
21:10 anholt: got anything about what format is involved?
21:10 anholt: f1403d66d40c39bb0aab3732e6f641282cf7eb14 does seem real suspicious, though
21:10 Kayden: anholt: the issue is that _swrast_write_rgba_span -> put_values -> util_format_write_4ub is busting because we have a destination stride of -512 and util_format_write_4ub is treating dst_stride as unsigned
21:11 Kayden: so our dest pointer goes insanely out of bounds
21:11 Kayden: ultimate function is util_format_b8g8r8a8_unorm_pack_rgba_8unorm
21:13 imirkin: that reminds me, i should see if things still semi-work on vieux
21:14 imirkin: good thing i have the super-advanced top-of-the-line Riva TNT2 plugged in
21:14 Kayden: hehe :)
21:14 imirkin: it goes faster because it has swtnl
21:15 imirkin: unlike those foolish older boards which tried to do tnl in hw - can't keep up with a modern CPU
21:15 imirkin: er, *newer* boards
21:15 anholt: Kayden: thanks for the debug, I can take it from there.
21:17 Kayden: anholt: maybe we just go back to using GLubyte *dst = _swrast_pixel_address(rb, x[i], y[i]) and then pass 0, 0, 1, 1
21:24 Kayden: thanks! I filed #4377 just so we don't lose that info
22:36 jenatali: Is there a process for getting someone added to the Mesa GitLab project with "reporter" permissions?
22:39 Kayden: not really
22:39 Kayden: for developer permissions, yeaoh
22:39 Kayden: but for reporter...we can just add them
22:40 imirkin: what does reporter get?
22:40 jenatali: Can create issues. I think that's about it?
22:40 Kayden: primarily, the ability to tab complete their name in various places, and some permissions to do things with issues
22:40 jenatali: Yeah, tab completion is what I was mainly looking for
22:42 Kayden: maybe not even that, it might actually just be tab completion - i.e. they show up in lists of people associated with the project
22:42 Kayden: jenatali: what's the @name?
22:43 jenatali: It's @billkris.ms
22:43 Kayden: added
22:43 jenatali: Thanks!
22:44 Kayden: I think you -can- lock down more things such that reporter has meaningful permissions over e.g. anybody, but we don't do that and keep things open. developer gets you actual commit and MR access and so on. maintainer lets you approve things like this. owner means you are the one and only Brian Paul :)
22:45 jenatali: Yeah. It still makes me sad that apparently GitLab doesn't let you grant labeling permissions to reporters. Seems like that'd be useful
22:47 imirkin: Kayden: hm, i'm marked 'owner', and pretty sure i'm not brianp...
22:48 Kayden: ah, nevermind then
22:48 Kayden: yeah, I'm an owner too, heh
22:51 ccr: everyone's a Brian Paul substitute now
22:53 ccr: now, to the one unanswered question that has been burning in the collective mind of mankind: what IS a John Carmack?
23:01 anholt: padovan: ci-iris branch has my WIP. I think maybe I've backed up the queue of lava jobs, though.
23:02 anholt: I see what you were saying about these boards being unstable so far.
23:53 mareko: Kayden: yes for create_stream_output_target