00:55 tarceri: Kayden: Any comment on this one? As you tackled a similar issue with copy image https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4647/
01:05 imirkin: chadv: looks like you have some appveyor hooks that just got enabled accidentally?
01:05 imirkin: (and are emailing mesa-dev about ancient commits)
01:18 robclark: eric_engestrom: if I tag a MR for 20.1.0 milestone, and it is merged into master (but after the branchpoint), do I need to also push an MR for 20.1 branch? Or it will just automagically get picked up for 20.1.0-rc2?
01:25 kisak: robclark: why would it be any different from the normal backport process? Fixes: <git_commit> or CC: 20.1 <mesa-stable...> in the commit message to get it in the stable branch
01:26 robclark: I'm assuming it won't.. but new process and want to make sure a fix doesn't fall thru the cracks (esp. because freedreno is somewhat broken without in distro setting)
01:27 robclark: just want to make sure I'm not neglecting to do something that release managers assume I am doing ;-)
01:29 kisak: ah right, the little crack of time where things are in the process of landing and the branch happens beside it
01:30 robclark: yeah, it landed just after the branchpoint.. I added Fixes tag, and also milestone on the MR.. but the MR was against master.. so just wanted to double check whether I needed to submit a 2nd MR against release branch
01:32 Kayden: tarceri: I don't know, that seems pretty unfortunate to me
01:33 Kayden: tarceri: the thing is, CopyImage shouldn't care about mipmap filters...or linear filters. It does a bit-for-bit memcopy. I discussed it with khronos and we ended up changing the spec
01:34 Kayden: it was just causing the textures to be incomplete, even though it didn't matter for copyimage
01:34 Kayden: but sampling in normal drawing does involve the filters
01:34 imirkin: Kayden: well the copyimage thing was worse
01:34 Kayden: and texture integer is much older than copyimage, and that's been unambigous the whole time
01:34 imirkin: because as you're building up an image, it wouldn't let you do certain stuff with it
01:35 imirkin: it wasn't just integers iirc
01:35 Kayden: mipfilters too
01:35 imirkin: exactly
07:46 MrCooper: anholt robclark: the rules match against the files changed by the push which triggered the pipeline for personal branches, against the files modified vs the target branch for MRs
08:01 pq: emersion, imirkin, if the driver converts ARGB8888 to ARGB1111, A1L3 or such, that could result in hilarity on compositors that use the cursor plane like any other. I suppose the conversion is good with legacy UAPI, but with universal planes I'd probably not advertise ARGB8888 support on that plane.
08:30 eric_engestrom: robclark, kisak: the nomination process is documented in https://mesa3d.org/submittingpatches.html#nominations
08:31 eric_engestrom: as a bonus, that document is still up to date :)
08:31 eric_engestrom: I'm trying something extra though, that's not documented yet: milestones
08:31 eric_engestrom: I'm not sure dcbaker is doing the same thing but I think he is
08:33 eric_engestrom: that's not automated yet, but if you add an MR or issue to the next release's milestone I'll block that release until that MR is merged or issue closed, and before doing the release I'll check that everything listed in the milestone has been backported
08:34 eric_engestrom: I want to bake that in our tools by this time next week so that it gets automated, but I'm not 100% sure yet that the gitlab api provides enough information to fully automate it
09:11 jcdutton: Hi. I have a problem with Xorg not starting. http://paste.debian.net/1143897/
09:12 jcdutton: Any clues ?
09:13 jcdutton: Probably a use after free bug, but not sure.
09:20 dj-death: jcdutton: sounds like it
09:20 dj-death: jcdutton: install the debug symbols for the xserver package and open an issue on gitlab
09:21 dj-death: jcdutton: https://gitlab.freedesktop.org/xorg/xserver/-/issues
09:22 MrCooper: nope
09:23 MrCooper: jcdutton: looks like you have LIBGL_DRIVERS_PATH=/usr/local/lib/x86_64-linux-gnu/dri set in the environment, but no *_dri.so drivers there
09:24 MrCooper: if anything, it would be an xf86-video-amdgpu issue
09:45 jcdutton: I don't have a debug symbols package. So building xorg from source, to see if I get a better backtrace.
09:49 MrCooper: jcdutton: -dbgsym packages are in a separate <suite>-debug repository
09:50 MrCooper: but I'd sort out the DRI driver (path) issue first
10:16 jcdutton: Thank you for the help. I have to go now. I will look into it further later.
10:34 dschuermann: jekstrand: may I ask you run https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4830/ through CI for regression testing?
11:43 saloni: Hi!I am saloni from Punjab, India.Currently I am pursuing B.Tech (Computer Science and Engineering) and new to open source and I want to contribute in Mesa adriconf enhancements.This year I want to participate in xorg.Is the applications still open and can I contribute?Can you guide me about this?Thank you.
11:44 emersion: are you referring to google summer of code?
13:32 jekstrand: dschuermann: running
13:54 udovdh: hello,
13:55 udovdh: latest linux-firmware git still gives me:
13:55 udovdh: amdgpu 0000:0a:00.0: RAS: ras ta ucode is not available
13:55 udovdh: when booting kernel 5.6.8....
13:57 udovdh: on AMD Ryzen 5 3400G with Radeon Vega Graphics
14:37 jekstrand: dschuermann: Functionally looks correct. I've not checked shader-db
14:38 dschuermann: jekstrand: thx, but shader-db might matter, it has quite an impact for us
14:38 jekstrand: Yeah, I'll run that now
15:06 austriancoder: anholt: I am waiting for some hw but I will spend some hours during the weekend on this topic
15:49 Venemo: jekstrand: if you're not too busy could you please review th NIR parts of MR 4202 for us?
15:58 cmarcelo: pendingchaos: could you look at this particular patch -> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4743/diffs?commit_id=3b54cf70eefc10b6ab69bf9fbde50e84d0a56e8b
15:59 jekstrand: dcbaker: https://gitlab.freedesktop.org/mesa/shader-db/-/issues/1
16:00 jekstrand: Or anyone else, really, but dcbaker is the one with all the python foo
16:23 ElBarto: am I supposed to collected the reviewed-by tags and push again on the mr branch or can gitlab do that automatically ? (or is it irrelevant now that the projects are on gitlab ?)
16:27 pendingchaos: push again with the tabs
16:27 pendingchaos: *tags
16:30 pendingchaos: (at least for mesa, I don't know about other projects)
16:30 pendingchaos: gitlab doesn't add them automatically for any project afaik
16:40 ElBarto: ok
16:40 ElBarto: thanks
16:52 dcbaker: jekstrand: should "revert: anv/gen12: Temporarily disable VK_KHR_buffer_device_address (and EXT)" be backported to 20.0?
16:53 jekstrand: dcbaker: No
16:53 alyssa: Does anyone know if it's possible to force a particular argument order in an algebraic optimization of commutative ops?
16:53 dcbaker: jekstrand: that's what i thought, but wanted to be sure
16:54 jekstrand: alyssa: No, automagic commutivity is kind-of designed to make that not a thing.
16:54 jekstrand: alyssa: Why would you want to?
16:54 alyssa: I'd like to express (('feq', '#a', b), ('feq', b, a)) since we can pack constants more efficiently in the second source
16:54 alyssa: Currently handled manually, but I'm trying to move as much code out of custom passes into NIR stuff
16:54 jekstrand: alyssa: We have similar problems on our HW
16:54 jekstrand: I think we have a back-end pass that does the flipping
16:55 alyssa: Oh gosh I hoped it was just midgard.
16:55 HdkR: Nouveau probably has to deal with that as well
16:56 jekstrand: I don't know if you really want a nir_algebraic thing or if you just want a pass which looks at every 2-src ALU op that's flagged commutative in NIR and applies the policy
16:56 jekstrand: That's probably not all that many lines.
16:58 alyssa: Fair enough :)
17:10 Venemo: alyssa: can you implement that as part of the optimizations in your backend? in ACO, the optimizer has a part that is responsible for this kind of constant propagation. it ensures that the constants go into the correct operand
17:10 alyssa: Venemo: yeah, it is, and has been for a while. I'm just doing some refactoring :)
17:11 Venemo: alyssa: I see. I don't think you can get rid of it completely, especially if your instruction selection also emits constants
17:12 alyssa: Mm, right.
17:12 alyssa: I inherited a legacy codebase from myself, so.. :)
17:13 Venemo: don't worry about that. happens to all of us
17:14 jekstrand: alyssa: Died and left yourself a codebase?
17:14 alyssa: jekstrand: I am a phoenix!
17:14 imirkin: ooh fire!
17:14 imirkin: fwiw, nvidia has all sorts of crazy restrictions on what kind of argument can be loaded where
17:14 imirkin: fermi+ is slightly regular in that it's usually the const/immediate can only be in src2
17:15 imirkin: however on nv50, it's the wild wild west
17:15 jekstrand: Ours looks pretty regular until a NIR op doesn't match a back-end op exactly
17:15 imirkin: all handled in codegen of course.
17:15 jekstrand: Or some instructions can do fp16 immediates but not fp32 and stuff like that.
17:16 dschuermann: radeon also has a bunch of restrictions, but this kind of optimization was by far the easiest and among the first we did °°
17:16 jekstrand: It's not quite wild wild west, but it's not exactly regular.
17:17 imirkin: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp#n269 -- r = reg, a = address, c = const, g = global mem for compute, i = imm
17:17 Venemo: on some older hw, we can't use constants (or even SGPRs) just anywhere
17:17 dschuermann: I mean, it's not really an optimization to have something like that in instruction selection: void emit_vop2_instruction(isel_context *ctx, nir_alu_instr *instr, aco_opcode op, Temp dst, bool commutative, bool swap_srcs=false, bool flush_denorms = false)
17:19 Venemo: dschuermann: we also have constant propagation in the optimizer
17:19 Venemo: but yeah some of our instruction selection is also aware of this
17:19 mattst88: anyone know what's up with all the new chadv/cros-mesa-17.1.1-r3-vanilla tags?
17:20 mattst88: chadv: did you accidentally push with --tags?
17:21 mattst88: http://dpaste.com/3DFW0DF
17:36 Vanfanel: Hi there
17:37 Vanfanel: If I create a GBM surface with gbm_surface_create(), how many buffers will that surface have? Is there a way to specify a number of buffers for the surface?
17:42 daniels: no, sorry
17:42 daniels: if you want to do explicitly control the buffer depth, you have to use gbm_bo allocation and import them as FBOs
17:43 daniels: cf. https://gitlab.freedesktop.org/daniels/kms-quads/-/blob/master/egl-gles.c#L551 and also the README describes the approach
17:43 daniels: (in the EGL & GBM section)
17:47 Vanfanel: daniels: that is a very valuable repository for me, as it seems to describe things I had been using without understanding them too well. Thanks a lot.
17:51 daniels: Vanfanel: i'm glad! let me know if there's any gaps that could be filled, or if you have any suggestions or patches then please file a MR on the repo :)
17:51 daniels: that's literally what it's there for
17:52 alyssa: jekstrand: [200~ 10 files changed, 110 insertions(+), 466 deletions(-)
17:52 alyssa: ^ Source mod helper to the rescue! No shader-db changes.
17:53 alyssa: (Replacing a bunch of mostly O(n^2) passes to chew through inot with a trivial "has inot?" modifier check and some packing logic)
17:55 daniels: nicely!
18:09 jekstrand: alyssa: Nice!
18:09 jekstrand: alyssa: With all that O(n^2) gone, is it also faster?
18:10 alyssa: jekstrand: Probably not noticeably but I don't have any good compile-time benchmarks.
18:41 alyssa: jekstrand: ...and I just piped in clamp(x, -1.0, 1.0) output modifier support, clocking in at..
18:41 alyssa: 3 files changed, 14 insertions(+), 2 deletions(-)
18:41 alyssa: :)
18:41 jekstrand: \o/
18:41 alyssa: (Added a NIR ALU op, some algebraic rules to fuse it in, and then parse it out)
18:41 jekstrand: alyssa: Sounds like the helpers are doing their job. :D
18:41 alyssa: :D
18:41 alyssa: Only big weirdness left is the perspective division stuff
18:42 alyssa: (varying.xyz / varying.w) can be optimized to varying[perspw] and likewise for z
18:42 alyssa: which is like 200 lines of backend pass
18:43 alyssa: The problem is I can't write an algebraic pass predicated on `used as a varying?` ... or can I? :p
18:43 alyssa: (It's actually a more generic load/store thing, but IIRC there's no win for !varying because of scheduling)
18:51 daniels: jekstrand: speaking of helpers doing their job, one thing I've needed lately is to lower a chain of nir_derefs + {load,store}_deref(var->data.mode==function_temp) into {load,store}(var,offset), for which we have helpers for 'I/O' access, but not function/shader_temp
18:52 daniels: have I just been missing a useful helper and doing the wrong thing by open-coding, or should I submit something to add a helper to chase the deref path and return var+offset?
18:52 jekstrand: daniels: Feel free to add some. :-P
18:52 jekstrand: Likely, we're just missing the helper.
18:52 jekstrand: I added the ones for explicit I/O because I needed then in ANV
18:53 daniels: cool cool
18:53 daniels: will do then!
18:53 daniels: it's I think the first time I've reached for the obvious useful NIR helper and not found it :P
18:55 jekstrand: Welcome to the bleeding edge!
18:55 airlied: cant you just lower load store function temps to ssa in most cases
18:56 airlied: its not like we have a stack :-p
18:56 jekstrand: Oh, wait... You're trying to lower function_temp?
18:56 jekstrand: Is nir_lower_scratch what you want?
18:59 airlied: daniels: ^
19:01 daniels: maybe not quite. we have actual alloca() we can use, and it's also for shader_temp which I use for compile-time-constant data which I can inline with the shader program
19:02 jekstrand: We have a concept of that too! nir_opt_large_constants.
19:02 daniels: (useful for CL programs which have giant constant tables - it means I can emit and compile a program which has those inlined and pay that cost once, rather than either CPU-side loading them into UBOs for every API invocation, or GPU-side loading them into mem for every EU execution)
19:03 jekstrand: It may not do quite what you want but it's basically for giving you a .data section
19:03 daniels: being dragged away for dinner but I'll have another look at that when I can. last I saw it didn't entirely do what I want. but nir_build_deref_offset I think can at least get rid of some nasty open-coding.
19:03 jekstrand: I totally believe that it doesn't do exactly what you want. However, I'm guessing load/store_scratch and load_constant are what you want even if those passes need some help.
19:48 daniels: cool, I'll look closer at them next week then. thanks!
20:53 anholt: austriancoder: oh, and if you end up rebuilding baremetal container, we should throw netcat in the list of packages so we can do flakes reporting.
22:19 alyssa: anyone seeing Mesa: User error: GL_INVALID_VALUE in glEnableVertexAttribArray(index)
22:19 alyssa: (etc)? on glmark2-es2 -bjellyfish, for example. maybe a recent regression?
22:19 alyssa: (could be a glmark bug of course)
22:41 robclark: alyssa: nope.. I even tried glmark2-es (usually just use glmark2)
22:46 alyssa: robclark: hmm, ok
22:47 robclark: might have been *slightly* behind master, but not more than a day..
22:48 alyssa: :w