00:05 dcbaker: If it's a lot of patches yeah. If it's just one or two send me the shas
00:08 dcbaker: You can open an mr too, that's always fine
00:15 imirkin: dcbaker: probably in the 2-5 range
01:04 dcbaker: imirkin: either way. It'll be tomorrow before I get to them at this point
07:00 danvet: robclark, Reboot crash at msm_atomic_commit_tail <- looks like msm regression
09:05 tzimmermann: danvet, airlied, mlankhorst, FYI i have pushed the pdev fix to -misc-next
09:18 tpalli: I'd like to bump piglit commit, for other ci builds this works when I update MESA_IMAGE_TAG .. however I cannot figure out how to make it work for d3d12 ci build, I tried updating WINDOWS_TAG but that did not work
09:19 tpalli: so this is for the mesa gitlab-ci
09:21 mlankhorst: tzimmermann: is the drm_device->pdev fallout fixed now?
09:21 tzimmermann: mlankhorst, yes
09:21 mlankhorst: Ok, thanks!
09:24 MrCooper: tpalli: ah, you need to bump the piglit commit in .gitlab-ci/windows/mesa_deps.ps1 as well
09:25 tpalli: MrCooper ok, do I need to touch WINDOWS_TAG at all?
09:26 MrCooper: sure, otherwise the image doesn't get rebuilt
09:26 tpalli: ok thanks MrCooper
09:27 MrCooper: np, though per my comment on your MR, it's kind of a bad time to update to newer piglit... I've been trying to get https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7988 for weeks
09:27 MrCooper: merged
09:28 tpalli: ok I see, I can wait with this
09:30 mlankhorst: drivers/gpu/drm/amd/amdgpu/amdgpu_display.c: In function ‘amdgpu_display_user_framebuffer_create’:
09:30 mlankhorst: drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:929:24: warning: unused variable ‘adev’ [-Wunused-variable]
09:30 mlankhorst: oh well
09:31 mlankhorst: tzimmermann: seems to have been added in 8f66090b7bb7f2a2183f46e72e367922d836e0dd, r-b if I remove it before making the merge request?
09:34 mlankhorst: https://paste.debian.net/1181712/
09:35 tzimmermann: mlankhorst, i thought there was a recent patch to clean-up the errors. but ok, r-b if you want to fix it
09:35 mlankhorst: ok let me check...
09:35 mlankhorst: I will apply that then
09:42 mlankhorst: oh doesn't seem to have that, if you mean the W=1 series
09:46 tzimmermann: mlankhorst, i did. but it didn't seem to fix the issue
09:46 tzimmermann: maybe the issue is too recent
09:46 tzimmermann: so r-b
10:19 mlankhorst: dim really likes to complain if a link tag is missing
10:43 danvet: Lyude, since you're looking at nouveau modeset, what about enabling atomic by default?
10:44 danvet: not doing that is kinda awkward, and I don't think there's realistically any more testing to be done
10:44 danvet: emersion, ^^ maybe you can supply some t-b: for this with wlroots?
10:45 emersion: sure thing
10:45 imirkin: make sure to flip it on though :)
10:45 imirkin: by default atomic ioctl's aren't exposed for nouveau
10:45 imirkin: nouveau.atomic=1 or something along those lines
10:45 emersion: yeah, i've noticed. drm_info allows to easily check that everything's in order
10:46 imirkin: i dunno if gnome/kde things make use of atomic, but if they do, they'd be required testing targets too
10:46 imirkin: since i suspect that's what the majority of users will land on
10:46 emersion: i don't think GNOME does, yet
10:46 emersion: jadahl: ^ ?
10:47 emersion: i'll ask KDE
10:47 imirkin: (by virtue of e.g. ubuntu shipping it)
10:52 jadahl: i've tested nouveu + atomic on gnome and it worked
10:52 jadahl: both as a dGPU and single GPU system
10:52 jadahl: where should I add t-b?
10:53 imirkin: the future patch which sets atomic to enabled by default.
10:53 imirkin: jadahl: to confirm, you ran this with nouveau.atomic=1 ?
10:53 jadahl: yes
10:54 jadahl: I ran nouveau.atomic=1 on a hybrid GPU system, and on the same system with the intel GPU turned off, and didn't run into any issues during my (rather short lived) test run
10:58 emersion: jadahl: so GNOME now uses atomic?
10:58 jadahl: there is a finished merge request that has some minor issues left
10:58 emersion: ah, ok, not yet merged but pretty close?
10:59 jadahl: yea
10:59 emersion: cool
10:59 jadahl: it'll be used in GNOME 40 which will come in a couple of months or what it now is
11:00 emersion: do you still have modifiers disabled?
11:00 jadahl: yes
11:00 emersion: ok
11:00 jadahl: need to implement the "brute force" code first
11:00 jadahl: to handle multi head
11:00 jadahl: before I can enable it
11:00 emersion: yeah
11:00 jadahl: hopefully GNOME 41
11:00 emersion: single-head fallbacks aren't enough
11:00 jadahl: yea. it can be force-enabled for testing purposes
11:01 jadahl: and it's enabled on some tegra system
11:01 jadahl: because it can't run without
11:01 jadahl: we have a udev rule/tag for that
11:01 emersion: i think it could be enabled on anything but i915, if you wanted to
11:02 jadahl: does amdgpu have modifier support yet?
11:03 emersion: amdgpu has it with latest kernel/mesa, for GFX9+ (so only pretty recent cards)
11:51 Fr0stBit: Hi guys
11:51 Fr0stBit: How can I trace this?
11:51 Fr0stBit: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?)
11:58 MrCooper: Fr0stBit: run in a debugger and set a breakpoint at _mesa_error
12:02 Fr0stBit: I tried doing that it does not hit.. I built mesa with debug symbols (by passing buildtype=debug in maison)
12:05 pq: maybe it comes from glvnd instead?
12:06 Fr0stBit: I for sure have mesa
12:06 Fr0stBit: I only have a single radeon card
12:07 pq: sure, Mesa can be used through glvnd
12:07 Fr0stBit: The code is using EGL if it helps
12:18 Fr0stBit: Just checked out and I have libglvnd in my system (Arch Linux)
12:18 Fr0stBit: So I suppose I have to build a debug version of it too
12:18 Fr0stBit: Is there something similar for break _mesa_error in libglvnd?
12:19 pq: sorry, I don't know
12:20 pq: Fr0stBit, did you check MESA_DEBUG yet? https://docs.mesa3d.org/envvars.html
12:20 HdkR: Fr0stBit: Write up support for KHR_debug, enable sync message mode, and breakpoint in your local helper
12:21 Fr0stBit: pq: Yes, prints out the same stuff
12:23 karolherbst: break on printf :p
12:24 Fr0stBit: HdkR: I'm trying to debug something deep after layers of translations and stuff between them so this is not easy
12:24 Fr0stBit: karolherbst: lol this could somehow work, I'm gonna try it
12:24 karolherbst: bonus points for breaking on printf with a strcmp check
12:25 karolherbst: or maybe fprintf?
12:25 karolherbst: dunno what function is used :)
12:26 pq: strace might tell you which syscall writes the message out, then break on the syscall with a string match? :-o
12:27 karolherbst: ahhh, good idea
12:27 karolherbst: well
12:27 karolherbst: or ltrace
12:33 nroberts:discovers $_streq . neat!
12:43 Fr0stBit: Is it possible for glCopyBufferSubData to produce this on an EGL 4.3 context?
12:49 HdkR: https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glCopyBufferSubData.xhtml
12:49 HdkR: Claims it can throw invalid operation yes
13:25 danvet: zackr, ack that you pull in all the vmwgfx patches from lee jones?
13:36 danvet: tzimmermann, I have another patch for -fixes that I plan to push tomorrow
13:36 danvet: just fyi
13:49 Lyude: danvet: we're getting there
13:49 Lyude: that's the eventual plan once we have more testing in place
14:32 zmike: mareko: out of curiosity, how much improvement did you see from moving to c++ templates for draw?
14:34 pepp: zmike: see https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7807 ("... decrease overhead by 13%")
14:34 zmike: pepp: perfect, thanks 👍
14:49 Fr0stBit: Ok guys so I rebuild (correctly) this time mesa with debug symbols and I got it break on _mesa_error!!
14:50 Fr0stBit: Seems that this:
14:50 Fr0stBit: Mesa: User error: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?)
14:50 Fr0stBit: Is generated by a call to glShaderStorageBlockBinding
14:50 Fr0stBit: The question is why?
14:53 tpalli: maybe unsupported? you need at least ES 3.1 context (if using GLES)
14:54 imirkin: i don't think it's in ES 3.1 at all
14:55 tpalli: oh .. then it's 3.2
14:55 imirkin: ssbo is there, but i don't think that the configurable binding is
14:56 imirkin: i.e. i don't see it in ES at all
14:57 tpalli: yeah, the function's not in 3.2 spec either
14:57 imirkin: maybe with some ext, duno
15:00 Fr0stBit: Can I somehow force Mesa to use functions that do not exist on GLES?
15:03 imirkin: sure - you can change mesa to think they're available in ES
15:03 imirkin: should work fine
15:03 pq: Fr0stBit, but are you using GL ES? If you are using GL instead, then ignore comments about GL ES. :-)
15:04 imirkin: if you *are* using gles, just change this: https://cgit.freedesktop.org/mesa/mesa/tree/src/mapi/glapi/gen/ARB_shader_storage_buffer_object.xml
15:04 imirkin: would need to gain a es2="3.1" on the function iirc
15:04 Fr0stBit: pq: Yes I use a GLES 3.2 context
15:04 imirkin: but this would be for your local purposes only -- not upstreamable
15:05 pq: Fr0stBit, oh, you talked something about 4.3 earlier which is not a GL ES version (nor EGL) but GL
15:05 imirkin: pq: EGL, GL, GLES ... is there really a difference? :)
15:06 Fr0stBit: Underneath I suppose not :)
15:06 pq: imirkin, if you care about anything working :-p
15:06 imirkin: hehe
15:07 imirkin: Fr0stBit: if this is for something more serious, you could propose an ext to make this functionality available in ES contexts
15:08 pq: It looks like glShaderStorageBlockBinding would be available in GL starting from 4.3. Other people were talking about GL ES, which follows different version numbers and feature sets. And EGL is just irrelevant for this issue.
15:08 Fr0stBit: Nah I was just tracing a bug in gfx/gfx-rs
15:08 tpalli: maybe better rewrite to not use that func rather than driver hack, setup binding indexes in shader
15:09 imirkin: pq: i was just trolling, hopefully obv
15:09 imirkin: pq: also that function would be available with ARB_ssbo, not necessarily GL 4.3
15:09 imirkin: although ARB_ssbo was made core in GL 4.3
15:09 pq: imirkin, I'm still not sure which GL context Fr0stBit actually has :-)
15:10 Fr0stBit: pq: GLES 3.2
15:10 pq: imirkin, if ARB_ssbo, then it would not be called glShaderStorageBlockBinding but glShaderStorageBlockBindingARB or something? And fetched via eglGetProcAddress()?
15:10 Fr0stBit: I thought at some point that I was running on GL mode not on GLES
15:10 imirkin: pq: not all of those exts had suffixed functions
15:10 pq: Fr0stBit, alright :-)
15:10 imirkin: according to the mesa xml file, looks like ARB_ssbo did not: https://cgit.freedesktop.org/mesa/mesa/tree/src/mapi/glapi/gen/ARB_shader_storage_buffer_object.xml
15:11 pq: This just shows that all assumptions are likely to fail, better go by the book and double-check what you got - and use eglGetProcAddress() when it comes from an extension.
15:12 imirkin: for the exts where they knew it was going to be made core, they didn't add the ARB suffixes i think
15:12 imirkin: to avoid the annoyance between using ext vs "core" functions
18:18 anholt: hikiko: I'm seeing tests/spec/ext_external_objects/vk_bands.vert.spv and friends getting changed in my source tree after a piglit build. seems like something's broken.
18:56 zackr: danvet: yes, i'm in process of getting Lee's patches in
18:57 danvet: zackr, thx
18:57 zackr: danvet: does dim have any code to append the 'Link' tags automatically? it's not terribly fun to go over 40 patches to insert the links
19:08 zackr: nm, missed the apply-branch
19:20 vsyrjala: there's also add-link for the times when you need to sort out a conflict manually
19:29 danvet: zackr, generally recommended to pick up all patches with apply-branch
19:29 danvet: even your own
19:30 danvet: it's the joys of the kernel process :-)
19:42 zackr: danvet: got it. thanks! also, thanks for the dim cite and dim fixes notes. do i need to resend to the list with the log fixed?
19:42 danvet: you can fix up when applying imo
19:42 danvet: it's just changelog stuff
20:33 anholt: Plagman: any chance we could get Valve to offer up some traces of Valve games to https://gitlab.freedesktop.org/gfx-ci/tracie/traces-db/ ?
20:50 jenatali: dcbaker: Am I remembering right that if I want a fix to be backported to a release, all I need is a Fixes tag? Or do I also need a Cc tag or something else?
20:58 bnieuwenhuizen: jenatali: Fixes tag should work assuming the patch referred to was in the release
20:59 jenatali: Thanks, I thought I'd seen that discussed here, just wanted to double-check
21:17 dcbaker: jenatali: fixes is preferred because we've got scripts to automate that
21:17 dcbaker: CC is useful when something doesn't fix a particular commit and just needs to go into a release
21:18 jenatali: Ah, cool
21:44 zackr: anholt: do you use tracie for validation? it doesn't allow fuzzy comparisons with image diffs over a set of reference images for traces, does it?
21:45 anholt: zackr: yes, we use it. it's pixel exact, because we've never seen a fuzzy comparison that's useful for graphics rendering. when you change the rendering, the test fails and a human looks at the images and says "yep, still looks good, time to expect this sha1 from rendering now"
21:51 Plagman: anholt: yeah, but i don't know how they would fare for the 500mb limit
21:52 zackr: anholt: ah, thought so. we do it internally because have to expect that our rendering on top of intel will be different from running on top of nvidia or amd. it's basically thresholds on top of RMS (both full image and block based). it requires initial adjustment of thresholds for new hardware/tests and putting those in some file for CI to check against but once you have it works surprisingly well
21:52 Plagman: you'd also need gfxreconstruct for the vulkan ones
21:52 Plagman: but feel free to throw them on there
21:52 anholt: Plagman: is this "go for it with whatever valve-authored games you have?"
21:53 anholt: I suspect we might be willing to stretch the limit a bit for some notable titles in Linux games :)
21:53 Plagman: yeah - i think we've said ours were fine for this purpose
21:53 Plagman: we have talked to other publishers about the same thing and they're not as supportive, to say the least
21:53 anholt: ok, just making sure. I think I had an ack from someone else years ago that I never ran with.
21:54 Plagman: if you had something to replace most images with generated noise, you could cut down on trace size and liability there
21:55 Plagman: you'd have to know which ones matter and which ones don't, but could be doable
21:55 anholt: I suspect that model data is also high on people's list of stuff they care about, and that feels much harder to automatically replace with teapots or whatever.
21:55 Plagman: yeah
21:56 Plagman: would be fun though
21:56 ccr: teapot fortress 2?
21:57 anholt: doteapot 2
21:57 anholt: have to make a new model of half-teapot 2. (or is that just a whole teapot?)
22:00 ccr: the right teapot in the wrong place can make ALL the difference in the world.
22:01 imirkin:remembers thinking the glutTeapot thing was quite cool
22:01 imirkin: (or was it in glu?)
22:01 Plagman: vkTeapot when
23:08 imirkin: are there some good external image tests somewhere? the piglit ones seem a bit lacking
23:16 ccr:ponders.
23:33 anholt: Plagman: with a bit of a trim on the traces we've got, looks like we aren't going to stretch the limits much.
23:41 anholt: also, wow, brotli repack is sloooow.