00:07 Company: DemiMarie: fun fact: height * stride < buffer_size is technically possible. The last row doesn't need to have the full stride
00:08 Company: the right formula is (height - 1) * stride + width < buffer_size
02:02 pinchartl:is confused
02:02 pinchartl: I'm trying to import dmabufs to be used as textures in opengl
02:02 pinchartl: I create an EGL image with the linux dmabuf fd
02:02 pinchartl: and then use EGLImageTargetTexture2DOES
02:03 pinchartl: that function is defined in both the OES_EGL_image and OES_EGL_image_external extensions
02:03 pinchartl: using TEXTURE_2D and TEXTURE_EXTERNAL_OES respectively
02:03 pinchartl: I don't really understand the difference between the two
02:04 pinchartl: if anyone could enlighten me, I'd really appreciate it
02:22 pinchartl: I think I got it... TEXTURE_EXTERNAL_OES support multi-planar textures, with a sampler that can directly sample NV12 or YUV420. with TEXTURE_2D, I would need to create a texture for each plane, and write a fragment shader to sample all textures and convert to RGB
02:27 pinchartl: is there a way to list the formats supported by TEXTURE_EXTERNAL_OES ?
02:50 zamundaaa[m]: pinchartl: yes, the same way you list the supported dmabuf formats in general
02:51 pinchartl: zamundaaa[m]: how is that done ? :-)
02:51 zamundaaa[m]: eglQueryDmaBufModifiersEXT
02:53 pinchartl: thank you
04:20 Company: pinchartl: one thing you should know because it's rarely explained: The stride of the individual planes must be a multiple of 256, or creating the external texture will fail on various GPUs
08:55 eric_engestrom: alyssa: re- adding a dep for checking rnc xml, you could gate it behind `if with_tests`, like I did for validating the drirc xml: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/util/meson.build#L181
08:56 eric_engestrom: and you can also make it optional so that if it's not there you just ignore that check (or print a warning if you want)
10:11 pinchartl: is the 256 stride alignment a safe superset of all GPU requirements ?
10:20 nicehabithero: I personally do not remember what i planned for mesa amber branch r300 isa for control flow emulation, but i remember GCN cards had a comment that soft-clause can replay things, inspecting the clause of memory loads yet deeper might really lead back to command buffer memory done or thread done interrupts, which naturally not occuring on r300 as hoped. But it all was so long time ago
10:20 nicehabithero: when i delt with ISAs alike.
10:22 nicehabithero: So as 945 to 950GMA had pretty much same restrictions as r300 such as now flow control and also sw vertex shader, it is complex to get to perform without very modern featuresets.
10:23 nicehabithero: but atom processor is something that is manufactured on very nicest convertible tablets in stacks which are also quite affordable.
10:29 jani: airlied: sima: heads up wrt drm header test https://lore.kernel.org/r/87r03e1lft.fsf@intel.com
10:37 sima: airlied, I guess we just do a big note first about the nack in the main pr and offer to revert them
10:37 sima: kinda can't add the nack since the patches landed already
10:38 sima: imo for drm, where we have a lot of object model stuff going on, contained headers really help a bit with decent design
10:38 sima: for core headers I kinda get that there's some where it just doesn't make that much sense
10:38 sima: so blanket enabling like what was tried 5 years ago seems not the best fit
10:43 jani: making headers standalone was also part of mingo's strategy in https://lwn.net/Articles/880175/
10:44 jani: but I claim it's not enough to *make* headers standalone, you have to *keep* them standalone
11:17 linkmauve: dcbaker, hi, Mesa doesn’t currently build on Rust nightly, probably some meson issue? Here is the error:
11:17 linkmauve: error: invalid value '1.87.0-nightly' for '--rust-target <RUST_TARGET>': "1.87.0-nightly" is not a valid Rust target, the patch version number must be an unsigned 64-bit integer
11:17 linkmauve: This is an option being passed to bindgen.
11:18 linkmauve: bindgen 0.71.1
11:40 sally: It seems there is an issue with mesa 25 on Raspberry Pi 5, some app doesn't work like 'zed editor',
11:41 sally: When I run this command "vkcube", I got this result "Selected WSI platform: xcb Selected GPU 0: V3D 7.1.7.0, type: IntegratedGpu vkcube: ./cube/cube.c:1486: demo_prepare_buffers: Assertion `!err' failed. Aborted"
12:36 mareko: karolherbst: note that you can enable ACO for radeonsi+rusticl by setting shader_info::use_aco_amd = true
12:39 karolherbst: cool
12:40 karolherbst: but atm I'm testing both. I think the only major regression with aco is int24 performance
12:48 mareko: you can report an issue with attached asm from LLVM and ACO (AMD_DEBUG=cs,asm)
13:10 karolherbst: mareko: the issue isn't the asm, it's that aco doesn't support imul24 and co. Just needs somebody to wire it all up and test it
13:18 ransomware7: You are basing your systems on silence where is not understood whether you extort something, while it is readable that something you want from me. But the systems you do not grasp potentially or have not got time to implement, are not very sophisticated, cause the outrun of number systems had been done for it with centuries in a row of decent work. And the girl some talked about she knew
13:18 ransomware7: i was the best to her, and how much i loved her to still treat me as freak. So it isn't at all looking anything understandable to me as to what you want until you claim or speak about your demands or requirements at all tbh. Dad had been involved with lawless activity but has not been charged and too big order from my behalf to give him in or out, cause his my dad, same thing with a
13:18 ransomware7: sister, she is still my sister etc. same with another sister, and same with mom, i want to branch on my own yes, but i do not want to punish them unless there is an unvoidable mass murder reason for it due to narcissism from their behalf or among similar lines. So i am entirely clear my own, your positions i do not know.
13:19 ransomware7: unavoidable, so case closed
13:39 mairacanal: sally, could you create an issue in the Mesa repo with some instructions to reproduce the error (https://gitlab.freedesktop.org/mesa/mesa/-/issues)? thanks!
13:46 peiderbundychief: in that thread or pdf only thing that i ever improvised was fixed point rounding, but the text gives it away, i am reading with high pace, it is such a compact paper too, there is no cardinality or world on arrays lilke at floating point, and i got to the very similar presentation as to for them, it can be considered a stable technique, however yes united states's and china's
13:46 peiderbundychief: companies are selling the whole mack vechicle burden of socketed 486 chips for thousond dollars, that is true, a lot can be done with such even in ukranian Russian war. But who wants to be in a war with china or united states, i do not know, europe has prepared with war less, and that is human kind thinking but they can push further and prepare cause europe has all the capability and
13:46 peiderbundychief: know how to do that. But war is still not considered humanity wise necessary at all, it gives no benefits.
14:29 nastywastesmell: and about boundings limits it actually mentions that on the write column of binary entropy paragraph, that it is allowed. so bounding limit is same term as rounding imo. and it even mentiones that both fixed 2 3 4 or 0.xx 0.yy inputs can be given , which also makes sense entirely.
14:29 nastywastesmell: so it is not entirely complex paper either to start harassing me everywhere.
15:12 alyssa: eric_engestrom: I saw that, but I want the validation to gate the python script running (so the python can assume that it's getting valid XML in). gating on tests doesn't do that - if you have invalid xml you just get inscrutable build fails that validation would've caught with a much more useful error mesage
15:32 dianders: meltq: Hmm, you're right that "panel-novatek-nt36523.c" is a bit wonky. I guess maybe you could make the macro like this:
15:32 dianders: https://www.irccloud.com/pastebin/LJamLLtK/
15:34 dianders: It's not the most amazing solution, but it seems like the most efficient to preserve the original functionality of the code.
15:51 trancemaniac: essentialy the bounds of term n in the array/sequence/distribution requirements are rather loose in the original paper, which makes also sense, the pdf shows that (i.e there are many ways to get uniform output distribution cause the limit bounds for nth terms/elements are pretty high for both base2 or base10 logarithm calculated results in the binary distribution), and possibly there was
15:51 trancemaniac: no human behind that calculated those things, cause for many many years in a row there are solvers that do that. However all the results seem expected to me. I arrived to same conclusions.
16:10 Hazematman: was `ci_run_n_monitor` changes so the target regex has to match the job name entirely? I remember being able to just do `anv` for the job but now it seems have to do stuff like `anv.*`
16:13 zmike: I'm reasonably sure you always had to use a regex
16:15 lucaceresoli: Hello, I wonder whether the R-by jani is enough for applying my small DRM bridge debugfs improvement series:
16:15 lucaceresoli: https://lore.kernel.org/all/20250226-drm-debugfs-show-all-bridges-v8-0-bb511cc49d83@bootlin.com/
16:15 lucaceresoli: lumag: maybe you want to review it as well, as you suggested some of that work?
16:16 lucaceresoli: Sorry for being pushy, I'd love to have this applied soon-ish because it has (trivial) conflicts with my bridge refcounting series, of which I'm probably sending v7 later this week
16:35 eric_engestrom: alyssa: ack, makes sense to make it mandatory then 👍
16:35 alyssa: eric_engestrom: I have a compromise solution for now
16:36 eric_engestrom: Hazematman: yeah, the first version was a prefix match and we replaced with a full match
16:36 alyssa: eric_engestrom: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33814/diffs?commit_id=05945f35041f47370c795b883c0ae5b4f746660f#f7ea6b455d80520d4e6f8e62c9b23ecbf7c8f3c0
16:37 eric_engestrom: Hazematman: aka `anv` would match `anv-foo` but not `zink-anv-foo`, which was not the most obvious thing, so making it an explicit ful match forces you to think about what you want to match or not
16:38 eric_engestrom: alyssa: ok; where is that msg printed?
16:38 eric_engestrom: I have a feeling it might end up in the meson log and not somewhere visible by default
16:38 alyssa: eric_engestrom: exactly
16:38 Hazematman: Thanks for confirming eric!
16:39 alyssa: it ends up in the log and silent.. unless the script ValueErrors or whatever and then it shows up in stderr
16:39 eric_engestrom: alyssa: ah wait, /me missed the grayed out comment, reading it now ^^
16:40 eric_engestrom: ok yeah I see, so if it works you don't need the dep, but if you have a problem you need it to know what's wrong
16:40 alyssa: in theory
16:40 eric_engestrom: sounds like a really good compromise actuall
16:40 alyssa: i'd love for everyone to have the dep but
16:40 eric_engestrom: *actually
16:41 alyssa: I don't exactly have the political capital to spare right now for "add more deps to mesa"
16:41 alyssa: :p
16:42 eric_engestrom: yeah I get that
16:43 eric_engestrom: you _could_ suggest the dep and if anyone pushes back, not resist and directly suggest this compromise
16:43 eric_engestrom: but that still uses some spoons
17:02 dcbaker: linkmauve: https://github.com/mesonbuild/meson/pull/14300
17:02 dcbaker: I'm hoping to get some of that pulled back to 1.7.1
17:03 alyssa: trying to push my first DRM patch, can someone sanity check my steps of:
17:03 alyssa: 1. dim checkout drm-misc-next
17:03 alyssa: 2. dim b4-shazam -s <message-id>
17:04 alyssa: 3. ... I guess dim push-branch now?
17:05 alyssa: I guess I should probably build test the applied thing first just in case?
17:43 alyssa: i'm glad i did build test becuase there's a conflict, yay!
17:49 alyssa: eric_engestrom: btw, I'm thinking some drivers will want u16's to save space
17:50 alyssa: dunno whether that should be a different type="" or just add a new attrib for min/max and infer the correct integer type
17:52 eric_engestrom: infering sounds risky to me, better to make it an explicit `size=16` or something like that
17:53 linkmauve: “12:30:58 jadahl> can't be off screen IIRC was the apple hw limitation, or something along those lines. that just makes it impossible to use as a cursor plane”, in Weston we switch to GL cursor everytime the cursor is even partially off-screen, including in-between two outputs. I don’t know which hardware originally caused that.
17:54 alyssa: eric_engestrom: hmm. at that point might as well just have types `uint16` or something
17:55 eric_engestrom: alyssa: sure, but your type_map will grow a lot
17:56 alyssa: it has to anyway to map to uint16_t concrete types?
17:56 alyssa: so.. meh?
17:56 eric_engestrom: yeah, maybe that's the simplest solution
17:57 eric_engestrom: so instead of uint|int|float|bool you'd have uint16|uint32|uint64|int16|int32|int64|float16|float32|float64|bool
17:58 alyssa: well float is just float32
17:58 alyssa: well just float
17:58 alyssa: i think only panfrost uses float stats and fp32 is fine
17:58 eric_engestrom: but if you can want u16 you might also want f16
17:59 eric_engestrom: anyway, if it's all in the `type` field, if doesn't matter which ones we add at first, we can always add others later
18:00 alyssa: dim is screaming at me uhhh
18:00 alyssa: "Branch setup for the integration repo is borked'
18:00 eric_engestrom: so long as we don't have to add another field on both sides later
18:00 alyssa: sima: ^?
18:00 eric_engestrom:has to go, good luck with dim :]
18:06 alyssa: indeed .src/drm-tip is not on a branch, what? dim bug? user error?
18:11 movies_and_games: best joke is that everything is now in the cloud but is fuzzed for me to read only. Man how strong man I am, it impresses even me. It's unbelievable how accurately i managed to do calculations, i am shocked i did this.
18:11 movies_and_games: I do not actually know what went wrong in my life at some point things turned over, i became very good.
18:15 movies_and_games: even purposely i am not arrogant either, even though my self-determinism kind of forcing me to take me seriously might suggest, just i know i am correct on those things, and i am using such style, i know that cause i am sufficiently old, and logically known each last step or history of your doings, leaves only the correct ones on the table for very long history of taking mental notes.
18:17 sally: mairacanal: Thank you. I have found another oppened report https://gitlab.freedesktop.org/mesa/mesa/-/issues/12641 which I have added my comment there
18:17 movies_and_games: if i know the adjective arrogant , well let's say i do, then actually that is mis interpretatable, i have more like determined feed of info, rather than being arrogant i am more like so good in my heart that i want you to have that intelligence.
18:17 movies_and_games: and that intel i give.
18:30 Ermine: I'm trying to run piglit and getting this: FileNotFoundError: [Errno 2] No such file or directory: '/home/peter/code/piglit/tests/spec/amd_shader_trinary_minmax/execution/built-in-functions/cs-max3-uvec4-uvec4-uvec4.shader_test' --- did i forget to download something?
18:56 sima: alyssa, might be very old dim setup and need to start over fresh perhaps?
18:56 sima: we've moved branches around a lot and I think the transition period wasn't entirely perfect
18:56 sima: so just setup again probably easiest
18:56 alyssa: sima: I thought I setup like 2 weeks ago..
18:56 sima: hm ...
18:57 sima: this should work I think?
18:57 sima: demarchi, ^^ dim seems to be unhappy with alyssa
18:57 alyssa: ~~feeling's mutual~~ delet
18:57 alyssa: :P
18:59 alyssa: (i'm joking, bug aside this was surprisingly painless as far as email-driven workflows go. thank you demarchi and sima ^^ )
18:59 sima: alyssa, so how do you hit that error?
19:00 alyssa: sima: origially, "dim push-branch drm-misc-next"
19:00 alyssa: but "dim rebuild-tip -d" is enough to hit it
19:00 sima: yeah
19:01 alyssa: looking at the git log manually in ~/.src/drm-tip,
19:01 alyssa: 413ae464b802 (HEAD, drm-tip/drm-tip, drm-tip/HEAD) drm-tip: 2025y-03m-03d-15h-40m-53s UTC integration manifest
19:01 sima: so with default setup I think src/drm-tip should be a worktree checkout with drm-tip/drm-tip or something like that
19:01 alyssa: it seems to be checked out to the right place but it's not associated with the branch or something? I'm confused
19:01 sima: hu, that sounds like drm-rerere somehow ended up in drm-tip
19:01 alyssa: drm-rerere is at:
19:01 alyssa: commit d5034390328564a3b5371ae92262d71a89119034 (HEAD -> rerere-cache, drm-tip/rerere-cache)
19:01 sima: do you have src/drm-rerere ?
19:01 alyssa: ^
19:02 sima: yeah, that's all good, but your error message is about drm-tip
19:02 alyssa: i'm not sure i understand the question then
19:02 sima: hm no, I got myself confused, that looks like a proper drm-tip commit
19:02 sima: well the problem of understanding was on my end :-P
19:02 alyssa: ah :p
19:03 alyssa: as I said - it seems to be at the right sha, but not associated with any branch
19:03 alyssa: and dim checks git_is_current_branch and fails because the current branch is ""
19:03 sima: huh
19:03 sima: like detached head?
19:03 alyssa: seemingly
19:04 sima: so drm-tip should be a branch that tracks drm-tip in https://gitlab.freedesktop.org/drm/tip as remote
19:04 sima: but this should only go wrong if you've done this in some really old kernel repo with old remote url
19:04 alyssa: i have that remote
19:05 sima: a local branch that tracks it?
19:05 alyssa: and the top commit is indeed (HEAD, drm-tip/drm-tip, drm-tip/HEAD)
19:05 alyssa: but there's no tracking local branch
19:05 sima: huh
19:05 alyssa: i guess i should try setting up clean in case I forked something up in a creative way
19:05 sima: same issue with drm-rerere?
19:06 sima: alyssa, extremely old git that doesn't have worktree support?
19:06 alyssa: git is 2.48.1
19:07 alyssa: although i just upgraded f40->f41 this weekend so maybe there are fireworks from that
19:07 alyssa: sima: no, drm-rerere is correctly on rerere-cache
19:07 alyssa: not detached head
19:07 sima: huh
19:07 sima: they both use git worktree
19:07 alyssa: o.o
19:07 alyssa: maybe i botched something when trying to pick commits
19:08 sima: maybe go into the main kernel repo you're using for dim and setup some random worktree yourself
19:08 sima: like for drm-misc-next
19:08 sima: nah worktree are pretty robust, you need to cd to them and mess with them directly
19:08 alyssa: i may have done that while fixing up the patch for push?
19:08 alyssa: am I using git wrong
19:08 sima: like $ dim create-worktree drm-misc-fixes
19:09 sima: or some other branch you've not yet checked out anywhere
19:09 alyssa: seems to be associated right
19:09 sima: if dim create-worktree works, then just delete the current drm-tip and run $ dim create-worktree drm-tip
19:09 sima: should fix this
19:10 alyssa: alyssa@blossom ~/.s/src (drm-misc-next)> dim create-worktree drm-tip
19:10 alyssa: dim: /home/alyssa/.src/drm-tip is missing, please check your configuration and/or run dim setup
19:10 alyssa: hahah thanks
19:10 sima: this = whatever happened to that branch setup
19:10 sima: hm
19:10 sima: shit
19:10 alyssa: patched that out
19:10 sima: yeah it's just paranoia
19:10 sima: for this command at least
19:10 alyssa: ok wtf
19:11 alyssa: still not associated though
19:11 sima: wut
19:11 alyssa: why is drm-tip different from drm-misc-fixes?!
19:11 sima: but the drm-misc-fixes worktree worked?
19:11 alyssa: yes
19:11 sima: dazzled and confused here
19:11 alyssa: commit 413ae464b8021542ad90cb1fbb15f8efc5050a5d (HEAD, drm-tip/drm-tip, drm-tip/HEAD)
19:11 alyssa: commit 23e0832d6d7be2d3c713f9390c060b6f1c48bf36 (HEAD -> drm-misc-fixes, drm-misc/for-linux-next-fixes, drm-misc/drm-misc-fixes)
19:13 alyssa: i cd'd into drm-tip and did `git branch --track drm-tip drm-tip/drm-tip && git checkout drm-tip`
19:13 alyssa: and like.. that seems to work now but also
19:13 alyssa: wtf
19:16 alyssa: and the rebuild worked. so i guess i can fix my error now?
19:19 sima: yeah
19:19 sima: could be that dim setup broke, it's probably the least used part
19:20 sima: I currently don't see where/how it creates the drm-tip tracking branch, and without that dim create-worktree indeed doesn't work
19:20 sima: could be due to ee96f65ba846d but feels a bit too funny if this has been broken for almost a year
19:20 sima: demarchi, ^^ ideas?
19:24 sima: javierm, just realized that you've put dim cherry-pick into the getting started section of dim, maybe that's the reason people use it instead of maintainers?
19:40 alyssa: sima: oh i guess i already did update drm-tip
19:40 alyssa: umm.. I guess the dry run flag is broken >.<
19:40 sima: alyssa, ?
19:40 alyssa: I did `dim rebuild-tip -d`
19:40 sima: drm-tip is kinda throwaway
19:40 alyssa: apparently that pushed https://cgit.freedesktop.org/drm/drm-tip
19:40 sima: oh, position matters
19:40 sima: dim -d rebuild-tip
19:40 chaos_princess: if something lands in drm-misc-next rn, it will be merged in 6.15, right?
19:41 sima: dim flags after dim, since many subcmd forward the flags to the git cmd they wrap
19:41 sima: lead to fun like dim -f push-branch -f
19:41 sima: first -f to overrule dim, 2nd to overrule git :-P
19:41 alyssa: https://i.kym-cdn.com/photos/images/original/001/942/617/7eb.jpg
19:41 sima: yup
19:42 alyssa: sima: context for chaos_princess's question is whether our SoC maintainer can queue the dts updates since I pushed dt-bindings via drm
19:42 sima: hm, maybe the -d did confuse dim rebuild-tip somehow?
19:42 sima: should though
19:42 sima: chaos_princess, we close around -rc6 but drm-misc-next stays open
19:42 sima: and only drm-misc-next-fixes goes into the merge window
19:42 sima: but you're before, so yes
19:42 chaos_princess: tyvm
19:43 sima: also, geez that cross-tree armsoc nonsense, why isn't that fixed yet
19:51 sven: chaos_princess: there was a conflict (with your digitizer series which got applied before :)), does this look correct? https://github.com/AsahiLinux/linux/commit/7275e795e520c7064af52ba67c74d7bac27eea4f
19:53 chaos_princess: looks correct
20:01 javierm: sima: IIRC I did that because was asked to cherry-pick a commit that was in drm-misc-next to drm-misc-fixes and didn't use cherry-pick, so was asked to extend the docs
20:02 sima: javierm, yeah the other part of the patch look good, but this one was maybe a bit too enthusiastic
20:02 sima: I think I'll ping mripard
20:02 sima: but not around now
20:04 alyssa: sima: his kernel.org email bounced, is everything ok?
20:05 sima: I think so, would be news to me
20:07 javierm: alyssa: his == mripard? Yeah, I talked with him earlier today :)
20:08 javierm: sima: could be possible that since 2022 (when I posted that patch) it was decided that we should ask drm-misc maintainers to do cherry-picking ?
20:08 sima: javierm, yeah we've tried to clarify that
20:08 sima: was kinda always the rule though, I guess just missed that when landing your patch
20:08 sima: and now it's still there
20:09 sima: iirc I've chatted with mripard about improving the docs and we concluded it's all good, but missed that one
20:09 javierm: sima: got it, sorry for the misleading doc change then :/
20:09 sima: for the starting guide maybe just a general rule that you have to use the dim tool if it exists, not raw git, is better
20:09 sima: and then a note that you shouldn't use the ones in the maintainer section but ping maintainers instead
20:09 sima: javierm, nah not on you, just noticed and got confused
20:10 sima: good docs are hard
20:12 javierm: sima: right and I see that change was before the commiter / maintainer split
20:13 alyssa: javierm: ok, guess kernel.org acting up then
20:14 sima: alyssa, I've heard from other cases that kernel.org is struggling with forwarding because it ended up on a spam list or something
20:14 sima: so it's not k.o bouncing, but the next hop rejecting stuff from k.org
20:14 sima: email is big fun
20:15 jannau: possibly related: https://social.kernel.org/notice/ArgV83GaFEOU2ROvGC
20:16 alyssa: sima: but i thought email was the most robust system for patches out there and more reliable than any forge could ever be???
20:17 sven: 🤡
20:30 javierm: sima: https://gitlab.freedesktop.org/drm/maintainer-tools/-/merge_requests/73 maybe ?
20:43 sima: javierm, ah that explains why it ended up in there
20:43 sima: put an ack on it
20:45 javierm: sima: cool, thanks