03:41 airlied: mareko: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23291 I think I'd want you to take a look
06:25 tjaalton: how to include the packaging revision in GL_VERSION, so that chrome/chromium don't break once mesa is patched without bumping the upstream version
06:26 tjaalton: this seems to be a cross-distro issue after folks have enabled gpu acceleration in chrome/chromium
06:33 tjaalton: err, make that GL_RENDERER
06:50 tjaalton: ok, seems to be PACKAGE_VERSION
07:37 ondracka: I need some help with explaining galium docs, I'm trying to implement PIPE_CAP_TGSI_TEXCOORD for r300 driver (so I can enable finalize_nir later which will break otherwise), but I'm a bit confused about what should have sprite coordiates and what should not. Without PIPE_CAP_TGSI_TEXCOORD sprite_coord_enable applies to the generic attributes. However, TGSI_SEMANTIC_TEXCOORD docs claim that with PIPE_CAP_TGSI_TEXCOORD sprite_coord_enable applies to
07:37 ondracka: tecoords instead, so that would imply than generics no longer can have sprite coordinates. However empirical testing shows this to not be true (and lot of stuff breaks if I ignore sprite_coord_enable for TGSI_SEMANTIC_GENERIC). In fact using sprite_coord_enable only for TGSI_SEMANTIC_GENERIC mostly works except for piglit arb_point_sprite-checkerboard where I need to apply it also for TGSI_SEMANTIC_TEXCOORD. How is this supposed to work?
09:01 kode54: dj-death: I'm running the game again to test it now
09:01 kode54: gotta compile the shaders again
09:01 kode54: it's fun, because I'm running with a shader database from my boyfriend, who beat the game a couple of weeks ago
09:02 kode54: we played it co-op over the past week after that, and beat it again
09:08 dj-death: kode54: thanks
09:09 kode54: yeah, no, it doesn't fix it
09:09 kode54: should I renderdoc capture the game?
09:09 dj-death: if you can
09:09 dj-death: hopefully that replays fine on my a750
09:10 dj-death: I guess I can fake the pci-id if need be
09:15 kode54: https://f.losno.co/Ryujinx_2023.05.29_02.10_frame398.rdc.zst
09:15 kode54: appears to render, but I can't see the picture in the emulator
09:17 kode54: I don't know if it matters that I'm also applying !23045
09:17 kode54: (and obviously !20418 for Xe)
09:17 dj-death: not sure how much that interacts
09:17 dj-death: I wouldn't test with 23045
09:18 kode54: oh, oops
09:18 kode54: let's remove that one then
09:19 dj-death: hmm
09:19 dj-death: interesting assert on replay
09:19 dj-death: qrenderdoc: ../src/vulkan/runtime/vk_image.c:509: vk_image_view_init: Assertion `driver_internal || !(image_view->usage & ~image_usage)' failed.
09:20 dj-death: oh I guess that might be sparse
09:20 kode54: let's try without 23045 then
09:20 kode54: I'm building mesa now
09:21 kode54: and then another 5 minutes of shader compilation
09:22 kode54: rip roarin' shaders
09:24 kode54: I don't know how GNU people manage to use notmuch with large mail folders
09:24 kode54: half of its operations don't even print status info
09:25 kode54: I've resorted to running strace on it
09:25 kode54: apparently, even when it's not bothering to emit any info, it's still got SIGALRM running every second
09:33 kode54: dj-death: https://f.losno.co/Ryujinx_2023.05.29_02.22_frame465.rdc
09:33 kode54: oops
09:33 kode54: oops I uploaded the rdc instead of the compressed copy I meant to upload
09:33 kode54: oh well
09:34 kode54: add a .zst now
09:40 dj-death: I assume you're building with release mode
09:41 dj-death: still getting that assert on replay
09:42 kode54: yes, I'm building in release mode, hmm
09:43 kode54: maybe I need to reboot to i915 to produce a usable rdc for you
09:43 kode54: xe would also be doing the vm_bind thing like crazy
09:43 dj-death: normally that shouldn't be visible to the app
09:44 kode54: oh, hmm
09:44 kode54: would I need to log out of my DE and reset its compositor for the change to fully take effect?
09:44 dj-death: looks like a storage thing
09:45 dj-death: Just commenting the assert for now
09:46 dj-death: another assert
09:46 dj-death: qrenderdoc: ../src/intel/vulkan/anv_private.h:3681: anv_aspect_to_plane: Assertion `!(aspect & ~all_aspects)' failed.
09:46 kode54: this is whack
09:47 dj-death: this time it's trying to use stencil on a depth only image
09:47 kode54: the title screen renders the entire town the way it is in your current save, and then blurs it a bit based on depth
09:48 kode54: depth of field effects
09:49 kode54: see color pass #3, where it draws the whole thing, somehow upside-down
09:49 dj-death: yeah that's probably an opengl thing
09:50 kode54: not sure I should discuss how I got these games anyway
09:50 kode54: I'm too poor for a Switch, yet wealthy enough for a decent gaming PC
09:51 dj-death: not going to ask
10:00 dj-death: kode54: okay, trace replays with a small stencil workaround
10:01 dj-death: kode54: I can see the load screen I suppose
10:01 kode54: I'll generate a trace without direct descriptors, and see if that plays differently
10:02 dj-death: no idea what could cause this
10:02 dj-death: you can run with direct descriptors disabled
10:02 dj-death: kode54: export force_indirect_descriptors=true
10:15 kode54: nope, that export didn't fix it
10:15 dj-death: hmmm okay
10:15 dj-death: then that's really odd
10:16 kode54: and toggling the export makes it recompile the shaders
10:16 dj-death: yeah
10:16 dj-death: that's expected
10:16 dj-death: hmm
10:17 dj-death: at that point you would have to bisect to get an idea of what change is causing that
10:17 dj-death: doesn't look like it's compiler related
10:17 kode54: I'd have to bisect the commit log of direct descriptors, since it's somewhere in there
10:17 kode54: I can do that
10:18 dj-death: yeah
10:18 dj-death: that would be really helpful
10:18 dj-death: sounds window system related
10:18 dj-death: because the trace replays at least here
10:26 kode54: well
10:26 kode54: renderdoc already isn't built with wayland support here
10:27 kode54: I have to run it with QT_QPA_PLATFORM=xcb
10:27 kode54: I'm also just using the vulkan layer environment variable to run it with Ryujinx
10:28 kode54: this bisect will give me something to do while I wait for notmuch to finish twiddling its thumbs
10:41 kode54: this can't be right
10:41 kode54: IO/R stat for notmuch is 23.6 TiB
10:41 kode54: bisect first step, vote: bad
10:53 kode54: I'm so glad it's a policy that every commit has to stand on its own
10:55 kode54: second step, good
11:00 kode54: holy crap
11:00 kode54: notmuch finally finished
11:01 kode54: after reading only 25.5 TiB worth of data
11:01 kode54: Added 46 new messages to the database. Detected 971024 file renames.
11:07 kode54: another good
11:56 kode54: dj-death: bisected it to 91cb0dba7ae80e5b282de57b4b49a42f22a452a8
11:57 dj-death: kode54: huh
12:02 dj-death: kode54: thanks
12:02 kode54: what's up with that patch anyway?
12:02 dj-death: kode54: that makes no sense though :(
12:02 dj-death: it's fixing an existing bug
12:02 kode54: hmm
12:11 kode54: just checked the Ryujinx source
12:11 kode54: they only request RobustBufferAccess if the vendor is Nvidia
12:14 kode54: hmm
12:14 kode54: they do use Robustness2 if it's supported
12:14 kode54: they don't flag Robustness (1) except if it's Nvidia
12:17 kode54: dj-death: is that important? should Robustness2 imply the original ext too?
12:18 dj-death: I think the problem is more likely nullDescriptors
12:19 kode54: it enables that too, if it's reported as supported
12:24 dj-death: yeah we do support it
12:30 kode54: there are a shitload of places in anv_pipeline.c that check robustBufferAccess but not nullDescriptors
12:30 kode54: and not robustBufferAccess2
12:30 kode54: I guess you patched those
12:32 kode54: anv_device.c line 4350
12:32 kode54: checks robustBufferAccess but not your new variable
12:33 kode54: genX_cmd_buffer.c also checks robustBufferAccess but not your variable
12:36 kode54: I've replaced those two references with device->robust_buffer_access and will try that
12:36 kode54: may also wish to check for robustBufferAccess2 in your initial assignment
12:36 kode54: I'll put these comments on the MR at the right code lines
12:39 kode54: or at least, add a comment
12:40 dj-death: VUID-VkPhysicalDeviceRobustness2FeaturesEXT-robustBufferAccess2-04000
12:40 dj-death: If robustBufferAccess2 is enabled then robustBufferAccess must also be enabled
12:47 kode54: I fixed it
12:47 kode54: you need to fix those two remaining places that check robustBufferAccess so they check device->robust_buffer_access
12:47 kode54: and fixup that one commit
12:50 dj-death: kode54: thanks a lot, I get it now
12:53 dj-death: we indeed need to have the pushing done right
12:54 dj-death: otherwise the push bits of UBOs will be randomly masked
14:38 alyssa: IHV poll, would any hardware other than AMD benefit from a "bit test" ALU opcode in NIR?
14:39 alyssa: `(x & (1 << y)) == 0` and `(x & (1 << y)) != 0` tests in one instruction
14:39 alyssa: gfxstrand: maybe, you know all the ISAs :p
14:50 karolherbst_: sooo.. I was thinking about CIing rusticl builds on arm64, but debians llvm packaging is so broken, I can't install libclang as native and target binaries at the same time :'(
15:38 tomeu:is amazed at how vivante/verisilicon dared to comment (and outright delete) stuff out from the openvx std headers and also add stuff as if it was KHR when it isn't in any published spec
15:39 Lynne: ping on !23227, video decoding is pretty crashy without this
15:42 alyssa: Lynne: Who even maintains that code?
15:42 alyssa: airlied I assume?
15:42 alyssa: Lynne: I think maybe you should review that code and then someone can assign to Marge after you've r-b'd
15:51 Lynne: I can do that, though afaik my r-b doesn't count
15:52 alyssa: Lynne: sure it does
15:52 alyssa: (If it's a real review anyway and not a rubberstamp, at least)
17:53 eric_engestrom: tjaalton: the version comes from the file VERSION at the root; you could edit it in your packaging script, but I'm not sure what the consequences would be (eg. some app expecting the version string to have a specific shape)
17:58 kisak: hmm? *checks backscroll* Why would chromium every be keying off of distro-specific subrevisions?
17:59 kisak: and yes, oibaf and kisak-mesa both adjust the VERSION file so that there is no confusion of where the non-mainline mesa builds came from.
17:59 kisak: s/every/ever/
18:25 tjaalton: eric_engestrom: yes, that's what I'm testing now
18:30 Sallly: Come Visit us @ irc.twistednet.org channel #twisted
18:42 Sylvia: Come Visit us08 09i13r03c07.06t11w02i10s04t08e12d09n13e03t07.06o11r02g 10c04h08a12n09n13e03l07 06#t11w02i10s04t08e12d09
19:08 koike: Hello o/ , I was working on these Mesa CI stats https://ci-stats-grafana.freedesktop.org/d/Ae_TLIwVk/mesa-ci-quality-false-positives please let me know your thoughts about it, there is an `About` section with more info. I intent to deprecate the Mesa CI daily report, since I think it is much better to visualize with this board. The board tracks
19:08 koike: Marge's rejections/pipelines that shouldn't have failed, its jobs and its unit tests. It considers only pipelines from closed MR to reduce noise. Please share your feedback, thanks
20:02 daniels: koike: so I think this is absolutely the best thing ever, but for everyone else who hasn't had the same benefit of watching you do the dance from dashboard -> sort by flake count -> pipeline dashboard -> filter by test name, do you think it could be explained in text or would best be done in a screencast in a blog?
20:04 koike: daniels: screencast looks interesting, easier to understand imo
20:06 daniels: koike: that would be amazing if you could please, unless you want to do explainer video calls with every Mesa developer :P
20:14 zmike: koike: is it possible to bookmark e.g., all the zink jobs so I can monitor the flake rate for my driver?
20:15 koike: zmike: you can filter by job name on the tables
20:16 zmike: and then I guess I star it somehow?
20:18 koike: zmike: hmm, I'm not sure that this is possible atm, maybe I need to add a variable to the board. I'll check and I'll get back to you
20:18 zmike: awesome, thanks
22:40 kisak: nevermind on my question, found the fine print in the relevant bug report.
22:57 lumag: rodrigovivi, jani: I have a question regarding the i915's patchwork tests. Do you have a description of the setup somewhere? We'd like to utilize something like that for drm/msm, so I'm looking for the possible clues / details.
23:57 alyssa:stares suspiciously at dEQP-GLES31.functional.compute.basic.image_atomic_op_local_size_1