00:38 tarceri: Anyone around that understand the old immediate mode drawing stuff? I'm trying to find where the code checks/sets which framebuffer to draw to but not having much luck. The game blockland set the drawbuffer to none but immediate mode continues to draw to I'm assuming what was set previously resulting in a rave party on screen at the code displays completely different images each frame. https://gitlab.freedes
00:38 tarceri: ktop.org/mesa/mesa/-/issues/13311
00:49 tarceri: The actual game crashes at the point the trace goes into rave mode
01:09 idr: tarceri: Immediate mode drawing... like glBegin / glEnd?
01:09 tarceri: yeah
01:09 idr: For the purpose of glDrawBuffer, that should work the same as the other drawing paths.
01:09 idr: At least from the perspective of the application.
01:10 tarceri: As far I can tell its meant to discard drawing to color attachments if set to none
01:10 idr: Correct.
01:11 tarceri: But it continue to draw to GL_BACK
01:11 idr: It should disable the usual color / depth / stencil writes.
01:12 idr: I think this only works in "later" GL versions when atomics and image load/store exist.
01:13 idr: I seem to recall the idea was that apps could use this to do a prepass the figures out what parts of textures were actually used.
01:13 tarceri: Setting to none is in the early specs
01:14 idr: Really?
01:14 idr:tries to think of how that could be useful...
01:14 tarceri: well its in 3.0 at least I haven't looked earlier
01:15 idr: Was transform feedback in 3.0? It could be useful with that.
01:15 tarceri: I'm not 100% sure if correct but apparently the depth/stencil stuff can still work
01:16 idr: Yeah, I think that's right.
01:16 idr: It has been a long time since I've written any GL code. *blush*
01:16 idr: The manual page says it only disables color writes.
01:17 idr: Yeah... you have to use that for doing stencil buffer shadows (like original Doom3).
01:18 idr: And that was OpenGL 1.x / 2.0.
01:22 tarceri: ok, cool. Well at least the games not just doing something completely useless I guess :P
01:39 idr: Well... let's not jump to conclusions. Lol
01:39 tarceri: right. haha
01:40 idr: Are any GL errors being generated? Like... is the game calling it between glBegin and glEnd?
01:40 idr: Seems unlikely.
01:40 tarceri: nope no errors
01:40 tarceri: runs fine on windows amd driver, not that that says too much
01:41 idr: Does it just fail on Mesa AMD or Intel too?
01:44 tarceri: Both.
01:46 tarceri: llvmpipe fails and turning off glthread doesn't help
01:50 tarceri: As far as I can test glDrawBuffer() sets none correctly so I assume somewhere in the Begin/end handling something is not being checked
01:50 tarceri: *as I can tell
01:52 Swung0x48: Hi everybody. I’m planning to port Mesa on Android to use Zink as a conformant OpenGL driver on there. Then I have found that the performance is not good. Is there any ideas or recommendations that for me that I could start profiling and working on Zink?
01:53 HdkR: :blobsweat:
02:10 Swung0x48: anyone there?
02:12 airlied: Swung0x48: probably want to talk to zmike but it's quite likely the android vulkan drivers aren't all that functional
02:13 zmike: yeah probably your issue is lack of feature support
02:14 Swung0x48: yeah I know that for the fact, and i want to hack on zink for my specific needs.
02:17 Swung0x48: I've coded an OpenGL-over-ES/VK translation layer but that would be too much work to make it conformant
02:18 Swung0x48: So i figured what if i just hack on Zink to make it work for more platforms
02:21 zmike: zink already works on android
02:21 zmike: if you find something that doesn't work how you want, feel free to try improving it
02:21 zmike: there's certain feature requirements that are set, however, and I'm not interested in rolling those back
02:22 Swung0x48: I don't mean i want to roll back your work or need you to work on it
02:22 zmike: no, I meant I'm not interested in loosening the feature requirements for zink
02:23 zmike: but otherwise feel free to make whatever MRs and I'll review
02:23 zmike: you might try finishing https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30766
02:23 Swung0x48: Is there some place that can make myself familiarize with Zink or Mesa as a whole so that I can start hacking on it?
02:24 zmike: there's https://gitlab.freedesktop.org/mesa/mesa/-/issues/5377
02:24 zmike: though I haven't added new items in a while
02:25 zmike: there's the zink issue tracker https://gitlab.freedesktop.org/mesa/mesa/-/issues/?label_name%5B%5D=zink
02:25 zmike: but I'm not sure how many of those are useful as a starting point
02:26 zmike: android is a bit of a niche case compared to normal zink usage, so I'm afraid I don't have much advice there
02:28 Swung0x48: that 5377 issue seems a good one, thx for the help!
02:30 zmike: I have another item or two for that I can add that might be useful, gimme a minute
02:32 zmike: there
02:32 zmike: good luck
05:30 dolphin: airlied: sent the drm-intel-fixes PR, I will be out so Rodrigo will cover rc6-rc8 as needed
08:14 mripard: sima: jani: can we merge https://gitlab.freedesktop.org/drm/maintainer-tools/-/merge_requests/40 ? I've been testing it for the last 4 drm-misc-next PR, and it's been ok so far. There's been a single patch issue on three of them, but all of them were legit.
08:31 jani: mripard: ack
08:32 jani: mripard: sima and I have been lamenting the fact that our attention to maintainer-tools maintenance has been lacking
08:43 mripard: jani: thanks :)
08:43 mripard: so, should I just merge it myself then?
08:58 pq: There are "special" SRGB fourccs?
09:00 emersion: i think it's for Vulkan _SRGB variants
09:00 emersion: s/think/guess/
09:00 emersion: but for an internal format list which uses FourCC as a base?
09:08 pq: so it's not drm_fourcc.h?
09:28 sima: mripard, I guess poke demarchi and rodrigovivi for an ack and push?
09:28 sima: and yeah, I'm not on top of this stuff anymore
10:35 machoskraito: hi all
11:22 jani: demarchi: rodrigovivi: mripard: looking at maintainer-tools shortlog, you're the ones up there after me and sima. any interest in stepping up a bit in terms of maintenance?
11:23 jani: (well, also seanpaul but iiuc not too active upstream lately)
11:24 sima: jani, yeah seanpaul kinda disappeared from upstream since a few years by now
11:51 machoskraito: hi all back ... .
11:52 karolherbst: dwfreed: ^^
12:27 mripard: jani: I guess, but my shell skills are very very lacking
12:28 jani: mripard: I think I have some drafts somewhere for gradually converting to python ;D
12:28 jani: subcommand by subcommand
12:49 jani: mripard: ugh, it's already been more than a year, just didn't have time for it: https://gitlab.freedesktop.org/jani/maintainer-tools/-/commits/dimpy?ref_type=heads
12:50 jani: the nice part was that you'd be able to distribute and install dim via pypi
12:51 jani: even when it's still mostly a shell script
12:58 mripard: I wasn't expecting "nice part" and "distributing" in the same sentence than Python :)
13:01 jani: mripard: :D
13:30 mripard: but yeah, I'm sure python would be much better already.
14:02 glehmann: alyssa: just to make sure, this comment doesn't mean you are against merging the MR? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35876#note_2987467
14:05 alyssa: glehmann: go ahead
14:53 alyssa: ..I just wrote a python script to generate a coccinelle rule
14:53 alyssa: i think i am doing too much computer
14:53 zmike: if only the code could write itself
14:56 mripard: alyssa: I hope it was a coccinelle rule in python?
14:57 alyssa: mripard: that would have been much smarter yes
14:58 alyssa: unfortunately i did the fastest/dumbest thing i could type :3
16:15 zmike: wow
16:15 zmike: I was today years old when I realized that modifying the bit from the u_foreach_bit* macros inside the loop breaks the macro
16:17 zmike: strongly recommend everyone evaluate their driver's usage to ensure you aren't as dumb as me
16:28 demarchi: jani: I've already been maintaining it for some time... I guess just without an official maintainer role in gitlab.
16:52 robclark: karolherbst: is rusticl creating nir variants, and possibly forgetting to propagate work_group_size_hint? I'm seeing a case were I get a non-variable local size in ir3, but then the shader that actually gets run has variable size (leasing to CL_INVALID_WORKGROUP_SIZE
16:53 karolherbst: robclark: mhhhhhh...... sooo.. I do generate a Default and an Optimized variant and the Optmized one gets the hint baked in, yes
16:53 robclark: I need it for both ;-)
16:53 robclark: because it impacts RA
16:54 karolherbst: yeah...
16:54 karolherbst: I don't think the CL API delivers that and I _think_ I use the default variant for the limts?
16:54 robclark: (also is there a competent vscode plugin for rust, which can do indexing properly?)
16:55 karolherbst: ohh I have logic to merge that stuff together
16:55 karolherbst: "info.max_threads = cmp::min(info.max_threads, build.info.max_threads);"
16:55 karolherbst: yeah
16:55 karolherbst: rust-analyzer
16:55 robclark: right.. the issue is that the shader that gets used doesn't respect the wrok_group_size_hint()
16:56 karolherbst: you need to change stuff in your settings.json
16:56 robclark: (in this case, it is a kernel that can really only work at a certain size, so we need the hint in the compiler back end)
16:56 karolherbst: "rust-analyzer.linkedProjects": [ path_to_rust-project.json_inside_builddir ],
16:57 karolherbst: and...
16:57 karolherbst: "rust-analyzer.server.path": "/home/kherbst/.cargo/bin/rust-analyzer",
16:57 karolherbst: well fix the path for your system
16:58 karolherbst: the latter just makes the plugin use the rust-analyzer binary from your rust installation, because mix and matching versions doesn't work out too well
16:58 karolherbst: robclark: mhh? What do you mean. Like the hint is just a hint, you need to accept any workgroup size regardless
16:59 karolherbst: so I pick the optimized one only if it matches
17:00 robclark: I mean, the hint tells me what size the app needs.. so ir3 spills where needed to achieve that size
17:01 karolherbst: yeah, but rusticl compiles it twice
17:01 robclark: but then rusticl seems to use the other one.. or at least the limits from the other one
17:01 karolherbst: rusticl creates the limits that work for all variants
17:01 robclark: (it at least doesn't hang the gpu, so maybe rusticl is running the optimized one, but using the limits from the default one
17:02 robclark: right, but the worst case limit is too low
17:02 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/frontends/rusticl/core/kernel.rs#L436
17:02 karolherbst: robclark: right... but I don't think the CL API really allows you to be as flexible as you'd need it to be here
17:03 robclark: if you don't propagate the hint to all variants then it is kinda useless ;-)
17:03 karolherbst: like if the hint is 512x1x1, then if you report 512 threads, it also has to run with 511x1x1
17:04 karolherbst: robclark: the kernel has to be runable with any other size
17:04 robclark: well, maybe a tensorflow problem, but it queries the non-kernel specific limit, and then generates the code for the kernel based on that limit. So it won't actually work otherwise
17:04 karolherbst: there is "reqd_work_group_size" if it's a strict requirement
17:05 robclark: hmm, ok, maybe that is what I should be using
17:05 karolherbst: yeah.. reqd_work_group_size will propagate to all variants
17:06 robclark: 👍
17:08 karolherbst: though I suspect there is a weird corner case with the hint where you specify a size that the default one isn't able to meet so you can't enqueue with the hint.... I'd have to read more carefully if I'd be able to technically allow this behavior
17:09 karolherbst: mhh "CL_INVALID_WORK_GROUP_SIZE if local_work_size is specified and the total number of work-items in the work-group computed as local_work_size[0] × …​ local_work_size[work_dim - 1] is greater than the value specified by CL_KERNEL_WORK_GROUP_SIZE in the Kernel Object Device Queries table." that's pretty clear
17:09 karolherbst: maybe I could file a spec issue for this
19:03 daniels: tarceri: hey, were you testing GBM at all with your series?
19:40 daniels: tarceri: can you please test my tarceri-does-this-break-everything branch? I'm curious to see if making things consistent with yours & jfalempe's changes makes things better or worse
23:04 tarceri: daniels: I can try it. mostly I was asking a couple of community members to test with their r600 setups. I don't 100% understand how it all fits together to be honest but gbm changes where impacting them.
23:08 tarceri: my r300 I didn't manage to get working propery yet
23:19 demarchi: airlied: drm-fixes seems to be stuck in v6.16-rc3 so dim pull-request doesn't do the right thing
23:19 airlied: demarchi: gimme a sec and I'll push it out, must have forgot to earlier
23:20 airlied: demarchi: should be updated now
23:20 demarchi: airlied: thanks
23:55 tarceri: daniels: yeah that breaks things even on my r300, I'll bisect