00:14 gfxstrand: Kayden: Care to give https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33855 a read at some point?
00:14 gfxstrand: All the Zink users will thank you. (And it fixes iris, too.)
00:16 Kayden: arg
00:16 Kayden: thanks!
00:16 gfxstrand: yw
00:16 Kayden: I wonder
00:16 gfxstrand: Firefox works on Zink now. :D
00:16 gfxstrand: After fixing 3 bugs, including 2 deep inside of kopper. :upside_down:
00:17 Kayden: I've been getting a lot of flickering and flashing on Firefox on my meteorlake with xe.ko (not officially supported) and I had bisected it down to a kernel patch
00:17 Kayden: but this is also firefox flickering, so...
00:17 Kayden: will give it a try at least
00:18 Ermine: it's flickering on radv without that patch as well
00:18 Kayden: I'd also seen some occasional small corruption in chrome/electron apps on my Battlemage card now that I'm using that as my daily machine and sounds like this could fix that too
00:19 Ermine: (radv + zink, that is)
00:19 gfxstrand: Yeah
00:19 gfxstrand: The damage thing is causing all sorts of issues.
00:19 gfxstrand: We're also seeing issues with some Electron apps (discord, in particular) that I'm hoping it'll fix.
00:20 Kayden:nods, discord is the electron app in his case too
00:20 gfxstrand: If you really want to run Zink, I recommend my zink/all-the-fixes branch
00:20 gfxstrand: It's got 3 MRs in it
00:21 gfxstrand: I'm really hoping once all this lands we can flip Zink on by default for Nouveau users.
00:21 Kayden: gfxstrand: I've also been crashing on sim-drm lately because iris_set_damage_region is getting NULL for pres
00:21 Kayden: I had assumed that that was a sim-drm thing being stubbed out somewhere
00:21 gfxstrand: My QA team (i.e. all the folks on Discord) are going to be trying it the next couple days.
00:21 Kayden: but was wondering if we ought to just if (!pres) return too
00:21 gfxstrand: Oh, I'm not sure about that.
00:24 Kayden: oh, heh, we were also setting use_damage even if it covered the entire rect
00:27 Kayden: gfxstrand: MR LGTM, so R-b, will try and test tonight :)
00:39 gfxstrand: \o/
00:39 gfxstrand: Thanks!
04:31 languagebarrier99: You can't say that I am an outsider, since i made this theory a real deal! It came from my labs to wider audience, but i was only able to process something that solvers can do too though I am used with manual thinking. So yeah certainly not the first who came up with this idea however just me who rang the bell the strongest. Do me a fauvor don't harass me everywhere in the world
04:31 languagebarrier99: with the tastless terror/tyranny wank spam, you start to carry that out again, and you suffer under excessive manhandling. I do not care what your connecting quasimodos do in their beds either, those estonians that carried out this terror were never a capable set in terms of any scoring on this planet not only in our country. Classical example what tyrans to get rid of under any
04:31 languagebarrier99: nation. Sorry for being brutal for those never on such lines, the militarizing of authorities actually imo should not be for nationwide conflict sake, since every nation has such scamming and abnoxious devils in their lineups. To me annexing territory has made less sense, but appareantly russia needed some access to black sea too. Otherwise that france or germany or spain turkey,
04:31 languagebarrier99: italy or uk would do newmaps isn't something expected. USA has also not so big motivation for such, more motivation they have is to continue saving the capable lives inside their nations, cause soldier or fighter pilot is a capable man and access to all canals and seas, America has, scientists they also have, rich people and land they also have etc. One way or another you find,
04:31 languagebarrier99: science is at the tops, and getting into nationswide war such as bloodiest combat, no longer matches as well to the picture of our advanced or modern science type of society. And yes Linux works as system quite well for years already, little bit opening your chakra's was expected to be enough to make you behave better. I mostly hope it did the trick.
05:34 belasimova: technically i am not aware if they want any of this code to be uploaded , so i myself am leaving and let you to decide over it. What i say I ain't gonna offer any of the full solutions. Otherwise i have the momentum and have succeeded on the tests, and very likely am this year done with all the related, but i code for my own sake only. Prolly all the explanations i gave, whatever you want,
05:34 belasimova: do not come to harass me again, the bitch and her terror monkeys who they screw i even do not care about, what i cared was i was dumped on the other island by them all, suffered as homeless while they celebrated. I said very clearly, one more time any of those faces are seen around me, it's the end of their run overall. Who they fuck or whether they satisfy themselves is none of my thing
05:34 belasimova: from there already, until they do that in their own premises, so around me those people no longer are allowed to scam nor walk nor fuck nor show up etc. i faced severe assaults and tyranny by those You got it?
09:10 karolherbst: what's up with the vmware jobs? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/72210514
09:19 ukleinek: ..ooOO(Nobody wants a job at vmware)
09:36 thellstrom: airlied: Two TTM patches from the xe shrinker series that are reviewed by mbrost, but still lack a TTM ack:
09:36 thellstrom: https://patchwork.freedesktop.org/patch/629418/?series=131814&rev=14
09:36 thellstrom: https://patchwork.freedesktop.org/patch/629419/?series=131814&rev=14
12:55 glehmann: looks like clover build is broken on msvc? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/72228461
12:55 glehmann: how did this get merged without failing CI?
13:01 glehmann: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33805 is probably at fault
13:03 glehmann: karolherbst: ^ since you review it
13:42 karolherbst: now we have two fixes, almost identical, should we flip a coin?
13:44 sima: randomly interleave both, see what happens?
14:04 zmike: I like that approach
14:04 zmike: I also again vote we delete clover
14:09 karolherbst: maybe we should really do it... sad for those r600 users, but...
14:11 zmike: imo if it's really a priority for people on r600 then someone will tackle rusticl+r600
14:12 karolherbst: that's gonna allow us to nuke so much code
14:12 zmike: maybe we can also punt out frontends/xa and vdpau while we're at it
14:13 jannau: would changing "depends on DRM_KMS_HELPER" to "select DRM_KMS_HELPER" for DRM_DEBUG_DP_MST_TOPOLOGY_REFS valid for working around following circular Kconfig dependency on x86 https://paste.debian.net/1361246/ ?
14:13 karolherbst: removing `set_compute_resources` will be fun
14:13 karolherbst: somehow drivers ended up implementing it even though it's only used by clover...
14:13 karolherbst: I don't even think it's actually doing anything
14:14 jannau: depends on is the correct thing but in conflict with the select for DRM drivers
14:15 jannau: the real issue seems to be "depends on !CALL_PADDING || RUSTC_VERSION >= 108100" for RUST itself
14:16 javierm: jannau: mixing depends and selects for the same symbol usually doens't end well
14:19 javierm: jannau: I think that DRM_DEBUG_DP_MST_TOPOLOGY_REFS should select DRM_KMS_HELPER regardless, since all other kconfig symbols depend on it instead
14:19 javierm: tzimmermann: WDYT? ^
14:21 tzimmermann: DRM_KMS_HELPER should be selected by drivers that need it
14:21 tzimmermann: it's not for users to select
14:21 javierm: tzimmermann: oh I see, DRM_DEBUG_DP_MST_TOPOLOGY_REFS is a user selectable option
14:21 tzimmermann: no idea what this thing is about
14:21 jannau: the issue is DRM_DEBUG_DP_MST_TOPOLOGY_REFS (not a driver) depending on DRM_KMS_HELPER
14:22 tzimmermann: that's not necessarily a problem, is it?
14:22 tzimmermann: module dependencies within drm is pure magic anyway
14:22 javierm: tzimmermann: IME the mixing of select and depends for symbols usually is a mine field
14:23 javierm: leading to these sorts of circular dependencies
14:23 jannau: and I would be surprised if it makes sense to enable it when DRM_KMS_HELPER is not enabled
14:23 tzimmermann: javierm, you don't have to convince me :D
14:23 jannau: so I can understand why depends on was used
14:23 javierm: tzimmermann: haha Ok
14:24 jannau: but it is in conflict with the drivers correctly selecting helpers
14:24 tzimmermann: oh, i see.
14:24 tzimmermann: that depends is wrong
14:24 jannau: I'll send the patch later today
14:24 javierm: jannau: great, thanks!
14:24 tzimmermann: it should rather select KSM helper
14:25 javierm: tzimmermann: that's what I said :)
14:28 daniels: alyssa: yeah, anything that doesn't understand the modifier of course can't attempt to interpret anything other than copying the full buffer size
14:42 alyssa: daniels: right, ok
14:43 alyssa: well, faith gave me the "how WSI works on Linux" talk this morning so at least that good came out of this XD
14:43 alyssa: ...deeply concerning I made it this far into my career without that, but here we are
15:08 jani: just started getting this mid-push: git@gitlab.freedesktop.org: Permission denied (publickey).
15:09 jani: hmm, temporary glitch, works again. odd.
15:09 austriancoder: why is there no possibility to build libOpenGL.so with out glx and without glvnd?
15:11 demarchi: sima: alyssa sorry, just saw the message
15:12 demarchi: it was definitely working for me... but sometimes we don't workaround all the different behaviors wrt git versions
15:13 demarchi: alyssa: is it working now for you?
15:26 alyssa: demarchi: idk, I manually setup tracking and moved on
15:31 demarchi: alyssa: is this a new setup that I could try to reproduce or is it an old one that stopped working?
15:40 alyssa: demarchi: new setup
15:40 alyssa: circa a few weeks ago at least
15:50 demarchi: ok, let me try
15:52 demarchi: dim: Adding remote for drm-tip repo from URLs: ssh://git@gitlab.freedesktop.org/drm/tip.git https://gitlab.freedesktop.org/drm/tip.git
15:52 demarchi: git@gitlab.freedesktop.org: Permission denied (publickey).
15:52 demarchi: humn...
15:55 demarchi: but that was failing for me regardless of the setup. So... maybe it failed for you, you tried to redo it and the "continue previous partial setup" didn't work?
16:00 alyssa: hmm, maybe?
16:01 alyssa: this seems plausible for something I might've done
16:05 MrCooper: austriancoder: libOpenGL.so.0 is a GLVND thing, Mesa never built that on its own
16:16 austriancoder: MrCooper: the same could be said about libGLESv2.so, but that can be build within mesa without glvnd
16:16 MrCooper: pretty sure Mesa built that before GLVND was a thing
16:17 MrCooper: i.e. the same thing cannot be said about it :)
16:18 austriancoder: MrCooper: fair enough
16:19 austriancoder: MrCooper: from reading the mesa sources I need a glx provider and glvnd support enabled to have everything to use libOpenGL.so.0
16:21 MrCooper: the latter yes, the former sounds wrong, libOpenGL is WSI-agnostic
16:21 MrCooper: i.e. it can be used with EGL or GLX
16:23 austriancoder: MrCooper: my use case is EGL .. okay. do you know some details about the inner working of glvnd? I build it for my target, but I am not sure how it should "find" the correct entry points into mesa.
16:25 MrCooper: Mesa ships <prefix>/share/glvnd/egl_vendor.d/50_mesa.json for that
16:26 austriancoder: MrCooper: my target is not linux or windows .. something more embedded
16:26 austriancoder: MrCooper: for that case it was user nice that mesa builds its own libglesv2.so
16:27 karolherbst: austriancoder: glvnd added a new ABI for GLX and EGL, if you don't need that, you can always disable glvnd support in mesa
16:27 karolherbst: glvnd also provides compat for hte old ABI, which is libGLX and libEGL
16:28 austriancoder: karolherbst: no libglx here. for my target I am using zink+kopper
16:29 MrCooper: the old ABI is libGL
16:29 MrCooper: (which includes GLX API)
16:30 MrCooper: it can still be used with EGL though
16:30 karolherbst: ohh was it libGL?
16:31 karolherbst: this was always confusing and got even more confusing now
16:31 MrCooper: yep, libGL.so.1 to be precise
16:32 mmind00: does freedesktop have some hickup? ... I did a dim push-branch just now and got https://paste.debian.net/1361337/
16:32 austriancoder: MrCooper: okay .. so disable glvnd support in mesa, build glvnd, use the build libOpenGL.so.0 . But how does the dispatch lib of glvnd knows about mesa?
16:32 pinchartl: karolherbst: GL is confusing. after 20 years I finally understood the difference between GL, GLES and EGL last night :-)
16:32 jani: mmind00: got the same a while back, temporary glitch
16:33 jani: try agian
16:33 jani: *again
16:33 MrCooper: austriancoder: GLVND can't work with Mesa without enabling support for it in the latter
16:33 karolherbst: pinchartl: it was such a pain in the early days with EGL, where projects assumed that EGL == GLES, though not sure if EGL could always create GL context or not, but it was sure fun
16:33 MrCooper: pinchartl: welcome to the club! :)
16:34 pinchartl: :-)
16:34 pinchartl: I'm so happy running wayland and not having to care about GLX
16:35 mmind00: jani: ok, now on the 3rd try it worked :-)
16:35 MrCooper: I'm also happy running Wayland, still have to care about GLX though
16:35 austriancoder: MrCooper: okay .. lets say I have enabled it in mesa. How does glvnd know about mesa's libs? I have that situation on my target and used gdb to step into it .. and ended in noop_func
16:35 pinchartl: but... by default Qt creates a GL context, not GLES, so I'm missing GLES extensions, even though the driver mesa driver implements them. the fact that GL and GLES have different sets of extensions is crazy
16:36 MrCooper: austriancoder: the egl_vendor.d file I mentioned, or some environment variables I can't remember by heart
16:36 pinchartl: with Qt6 at least I can request a GLES context (if supported by the platform). if I recall correctly Qt5 hardcoded the selection
16:37 austriancoder: MrCooper: I think that helps me to navigate in the source of glvnd - thanks
16:37 MrCooper: no worries, good luck
16:39 austriancoder:would still love it to drop the use glvnd for my use case and let mesa build the opengl lib for me :)
16:45 MrCooper: is there a particular reason you want libOpenGL instead of libGL? E.g. you don't want any X libraries on the system?
16:52 MrCooper: austriancoder: ^
16:53 demarchi: alyssa: I think it might be.... it tried it again and the tracking is there. Weird thing is that it's causing random auth issues
16:53 demarchi: s/it tried/I tried/
16:56 demarchi: I got another failure with drm-misc. Using DIM_PREFERRED_PROTOCOL=https seems more reliable
19:17 austriancoder: MrCooper: the main reason is I do not want/need any X lib. WSI is done through Vulkan WSI/kopper (which works quite nice).
20:21 alyssa: konstantin: did nir-test-runner.py regress? t's producing wonky diffs for tests that need expectation changes
20:21 alyssa: deleting the final } of the pass and replacing with adding a 2nd copy of the nir
20:24 hunfromthegenes: https://sarielhp.org/teach/08/a/lec/26_entropy.pdf free material.
20:26 hunfromthegenes: if wikipedia was not enough it's prequisite or requirement to the former article, never bother me again with trolling around my locations, i want not to deal with such behaviours.
20:40 ondracka: mareko: since nir_opt_varying enablement, gl_PointCoord will always take VARYING_SLOT_PNTC, iregardless of whether pipe_caps.tgsi_texcoord is set or not which seems to contradict the pipe_caps.tgsi_texcoord docs. Previously VARYING_SLOT_VAR8 was used if tgsi_texcoord was false. Is this a bug or feature?
21:00 konstantin: alyssa: Weird, do you have a branch that reproduces the issue?
21:03 alyssa: konstantin: alyssa/mesa:nir/reassociate2
21:03 alyssa: https://rosenzweig.io/bah.txt
21:05 konstantin: interesting commit history :D
21:07 alyssa: konstantin: all of my code is like this =D
21:08 alyssa: i just spam `gd` which aliases to `git commit -sam.`
21:08 alyssa: and then `up` (or `ag`) which `git rebase -i upstream/main (or asahi/main)` later
21:08 alyssa: of all the ways to use git, this is one of them
21:09 konstantin: For me, the runner just rewrites the constant to 5 like expected
21:11 alyssa: ;;
21:11 alyssa: do I have weird spicy git
21:12 konstantin: can you dump updated_test_file?
21:13 HdkR: How do people cross-compile mesa for i386 on Debian systems when the LLVM dev package has been broken for like three releases now?
21:13 alyssa: konstantin: https://rosenzweig.io/q.txt botched
21:13 konstantin: weird
21:14 konstantin: and you don't have any local changes?
21:14 alyssa: no
21:15 alyssa: konstantin: for ref, the tests run with dump shaders https://rosenzweig.io/k.txt
21:15 alyssa: indentation looks suss but idk
21:16 alyssa: this is python3.13.2 btw, from fedora 41
21:17 konstantin: The line numbers are messed up, it should be 36
21:17 konstantin: D:
21:17 alyssa: uhoh
21:18 konstantin: clang or gcc?
21:18 alyssa: clang
21:18 konstantin: gcc here
21:18 alyssa: oof
21:18 alyssa: oh jeez. right ok. ;;
21:18 alyssa: does __LINE__ work different in clang then? ugh
21:19 alyssa: https://stackoverflow.com/questions/56465101/are-there-any-guarantees-about-consistency-of-line-directives
21:19 alyssa: ;;
21:22 konstantin: maybe C++ is the answer
21:23 alyssa: ;-;
21:23 konstantin: Does std::source_location have the same problem?
21:25 alyssa: seems to
21:32 konstantin: I guess hacks inside the runner it is
21:33 konstantin: it will just have to search the source file for the reference shader
21:33 alyssa: yeee
21:33 alyssa: konstantin: or just search backwards from the line given
21:33 alyssa: ?
21:33 alyssa: you know it points to the end of the ref
21:35 konstantin: A search is probably the safest approach
21:36 konstantin: If the source file contains the same shader twice, the runner can print a warning "redundant test at line ..."
21:38 alyssa: fair
22:16 hunfromthegenes: 3 7 11 15 19 23 27 31 35 39 43 47 51 55 59 63 67 71 75 79 83 87 91 95 99 103 107 111 115 119 123 127 131 135 should be the sequence it gives, and yeah it never collides in the adder, but could there be collision in the summing up? as you see, not any of the power presentations could here ever cause collisions, or disambiguation.
22:25 austriancoder: MrCooper: glvnd is working - needed to patch libglvnd a little bit as filesystem access is not that easy.
23:02 mareko: ondracka: that's probably a bug