07:21Lynne: I'm just about sure that mesa is miscompiling my shader
07:21Lynne: could someone look into it?
07:22Lynne: affects all mesa drivers, anv, radv, and lavapipe, so I think the issue is with NIR
07:26airlied: does it work on nvidia?
07:40mareko: what is VUE on Intel?
08:52frankbinns: DemiMarie: the conformance submission I linked is for the open source driver (the proprietary driver passes 1.3 conformance across a large range of GPUs)
08:53frankbinns: we're currently in the process of upstreaming everything for Vulkan 1.0 & GLES 3.1 (via Zink)
08:54frankbinns: with all the extensions, etc we had to implement for Zink the driver can almost expose Vulkan 1.1
08:55Lynne: airlied: yes
08:56Lynne: also I found out that I've fixed llvm in one of my latest rebases
08:56Lynne: err, lavapipe
09:16jani: airlied: sima: so I'm not going to reply to this: https://lore.kernel.org/all/2024110521-mummify-unloved-4f5d@gregkh/
09:19jani: airlied: sima: if *you* say we should look into the process again, we will
09:28sima: jani, airlied yeah I think we'll just keep silently shrugging
09:28sima: with amd and intel doing this regularly and also misc sometimes there's really no point trying to change it, the people (on dri-devel) have spoken
09:28sima: agd5f, ^^ fyi
09:29sima: also my irc fails at rejoining somehow since a few weeks :-/
09:31jani: sima: there just isn't a good answer to having a fix to backport a fix from a non-rebasing -next branch
09:31jani: -"a fix"
09:31jani: the 2nd one
09:32sima: jani, imo it's more fundamental
09:32sima: for gregkh linus' tree is the center of the world
09:32sima: for a driver developer, it's the driver tree, which often is just $driver-next
09:32jani: agreed
09:32sima: and gregkh doesn't understand the different perspective somehow, and not for lack of us trying to explain it
09:51airlied: jani, sima : yeah I think there's almost a deliberate not getting it going on, maybe I should write a blog post to just point at
09:58jani: drm-misc is trying to apply fixes to -fixes and -next-fixes directly instead of cherry-picking, but a) I think it's hard for the large pool of developers to consistently get right, and you end up with cherry-picks anyway, and b) if you have a series with fixes first, you won't be able to merge the entire thing but have to wait for fixes to get applied to -fixes and backmerged to -next, slowing people down
10:01jani: iiuc the only way to make git really understand what's going on is via merges, but I'm also under the impression that Linus doesn't want a ton of backmerges and crossmerges either
10:04sima: jani, yeah we'd need topic branches for every fix that is needed for a feature patch set in -next
10:04sima: I think that's even harder to get committers to consistently do than the current approach
10:04sima: I'm wondering whether we should lean more towards "push to -next and cherry-pick if you need some as fixes" even for drm-misc
10:04sima: to avoid some of the confusion
10:04sima: because it's really the simplest model for committers
10:04sima: airlied, blog sounds good
10:05jani: yes, that's the thing. do what's easiest for developers/committers, don't add more hurdles
10:05sima: yeah
10:06jani: "develop on top of drm-tip or -next, preferrably put fixes first in the series, push to -next"
10:07jani: instead of, "well, you see, apply patches depending on what they do to a branch that depends on where we are in the development of the current linus' upstream, and maybe sometimes you'll get it right"
10:08sima: yeah the 2nd one I screw up too since I don't do it daily anymore like way back in the committer-less model
10:08jani: "yes it's a fix, but it's not small enough or important enough to be applied to -fixes at this stage"
10:09sima: yeah or people just dumping their fixes in at -rc6 because "oops forgot there's a kernel release"
10:09sima: into -fixes I mean, not -next
10:10sima: airlied, yeah a blog that just explains how everyone has a different kernel branch that's they're center of the world is probably all that's needed ...
10:10jani: since phb crystal ball went down, I wrote this https://jnikula.github.io/linux-kernel-tea-leaves/ so I don't have to answer the questions *and* it's got the feature deadline too ;)
10:36Lynne: is there a way to define a binding for an already defined BDA type?
10:36Lynne: in glsl, I mean
10:37Lynne: I just want to use BDA in a standard descriptor rather than in push data
11:52alyssa: mareko: iirc, VUE is the varying remapping thing for VS->FS i/o (etc)
11:52alyssa: but i'm not an intel dev, just read too much iris&anv code :P
12:59alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31964
12:59alyssa: anyone up to trade NIR reviews or something?
14:21karolherbst: oh right.. I wanted to review that 🙃
14:35soreau: emersion: gentle ping on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31725
15:17DemiMarie: frankbinns: are there plans for Vulkan 1.3 and OpenGL 4.6 with the open driver?