07:21tarceri: airlied: Does virgl use nir to tgsi?
07:23airlied: tarceri: yes, virgl, softpipe, maybe svga
07:25tarceri: I found a bug where indirect array access in a loop is indexed via a i value after its is already incremented
07:25tarceri: so it seem to always be off by 1
07:26tarceri: I think the "addr" var that is created is just inserted into the wrong spot right above the array access
07:34airlied: my ntt knowledge is pretty sparse, I think anholt was the main dev
07:35airlied: does softpipe show the same problem?
07:38tarceri: softpipe seems to work
07:40airlied: there is a comment that starts with /* virglrenderer requires that indirect UBO references have the UBO
07:41airlied: often for virgl we have to workaround things the renderer side doesn't understand
07:43tarceri: https://paste.centos.org/view/934c8d6a
07:43tarceri: its is that simple loop in the vs
07:45tarceri: Ends up like this: https://paste.centos.org/view/fc43cd11
07:45tarceri: "addr0" is in the wrong spot
07:47tarceri: Anyway thanks. Will look again tomorrow
07:47tarceri: I thought it was a bug with the new pass I was writing for the past 2 days lol
07:57airlied: tarceri: yeah that's likely going to be a virglrenderer bug
07:58airlied: would need to see the TGSI
08:31airlied: sima: fyi backmerge in drm-next
08:32airlied: robclark: please check the msm merge is okay, had some conflicts
11:51tintou: tarceri: If you can open an issue on GitLab (once back on track) with the virglrenderer tag so that no information is lost, that would be nice :)
13:07gfxstrand: dcbaker: Ping me whenever you get online today. I'd like to chat about merging NAK.
13:46robclark: airlied: well, it compiles, so that seems like a good sign.. I'll have a closer look in a bit when I get to the office
13:50yann-kaelig: Hello
13:51yann-kaelig: Don't know where to report this issue but when I'm trying to reset my password I get a " 500 We're sorry. Something went wrong on our end."
13:56kisak: yann-kaelig: sounds like #freedesktop would be closer
14:00gfxstrand: There's some general GitLab problems right now due to a failed migration. It may be related to that and will probably "just work" tomorrow.
14:00daniels: ^ that
14:01yann-kaelig: ok, well, issue reported on the channel.
14:47emersion: daniels: would be nice if someone could review this at some point :) https://patchwork.freedesktop.org/patch/563722/
14:47emersion: sima: does that look ok to you? https://patchwork.freedesktop.org/patch/553625/
14:48emersion: also https://patchwork.freedesktop.org/patch/546971/
14:49sima: emersion, "KMS dumb buffers are not suitable to be displayed without KMS."
14:49sima: a bit confused what you mean with that?
14:49daniels: emersion: such terrible tooling we have; it completely failed to translate between the Rb I gave in my head to anything visible
14:49daniels: sima: 'don't use it to allocate buffers to share between GPU and codec without ever hitting KMS'
14:50emersion: sima, hm now that i read that sentence it seems weird to me as well
14:50emersion: https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#dumb-buffer-objects
14:50emersion: > Note that dumb objects may not be used for gpu acceleration, as has been attempted on some ARM embedded platforms. Such drivers really must have a hardware-specific ioctl to allocate suitable buffer objects.
14:50sima: daniels, emersion maybe "KMS dumb buffers are not suitable to be displayed on any other device than the KMS device where they were allocated from"?
14:51sima: emersion, I think the previous sentence covers that well
14:51sima: emersion, do you want to document the lols of converting a legacy depth/bpp pair into a modern drm_fourcc?
14:51sima: but maybe that's better for the addfb1/2 docs ...
14:52emersion: daniels, lol
14:52sima: emersion, with or without my suggestion for reworded "use this for kms display only": a-b: me
14:52emersion: sima, oh that…
14:53daniels: sima: yeah that sounds like better wording
14:53sima: emersion, for the 2nd one, I thought you can nowadays just use kerneldoc syntax in .rst to get the autohighlighting stuff, so no need to sprinkle :c:$type: annotations all over
14:54sima: but also, I don't mind if there's a reason the kerneldoc automarkup fails for these somehow ...
14:54sima: so a-b: me on 2nd patch too
14:54emersion: sima, doesn't work for macros
14:54sima: ugh
14:54sima: yeah then this is fine I think
14:54emersion: "struct foo" works, but not "&FOO"
14:54sima: isn't it %FOO?
14:54sima: &foo is for struct foo
14:54sima: or &FOO for struct FOO really
14:54emersion: i've used &FOO for macros in comments
14:54sima: but also it's rather brittle lool
14:55sima: &thing is definitely meant for struct thing
14:56sima: ah disappointingly %FOO and $FOO do not cross-reference :-(
14:56emersion: "The below are only recognized within kernel-doc comments, not within normal reStructuredText documents."
14:56sima: https://dri.freedesktop.org/docs/drm/doc-guide/kernel-doc.html#highlights-and-cross-references
14:56sima: emersion, https://dri.freedesktop.org/docs/drm/doc-guide/kernel-doc.html#cross-referencing-from-restructuredtext <- there is a subset which is recognized in .rst
14:57emersion: right
14:57emersion: nothing for #define there sadly
14:57sima: emersion, and that intro para is outdated and wasn't updated when the kerneldoc-in-rst support landed :-/
14:57sima: yeah :-(
14:57sima: oh well ... not that you can ask someone to work on the kernel-doc perl without committing a serious crime
14:57emersion: lol
14:57sima: emersion, so definitely a-b: me on that :c:macro: thing
14:57emersion: ty ty
14:58sima: emersion, and I guess for the first patch the vote is on my reworded sentence for the displayable constraint
14:58emersion: ack
15:20zmike: can someone who is logged in assign https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25844 to marge
15:22pendingchaos: assigned to marge
15:22zmike: ty
16:14gfxstrand: cwabbott: We really need to be able to CSE ballot within a block...
16:15cwabbott: gfxstrand: it should be easy to special-case that
16:16cwabbott: I had a (truely ancient, pre-gitlab) series to add a bunch of intrinsic properties to properly describe subgroup ops
16:17cwabbott: one was "derivative-like" where you communicate a fixed set of other invocations that are assumed to be active, and the other was more "ballot-like" where you need the active set to be the exact same
16:18cwabbott: with that we could make CSE and so on better in a much less hacky way
16:38anholt: cwabbott: oh, that sounds nice
16:52karolherbst: gallium question: what is `pipe_image_view::access` supposed to specify? How the frontend might use or has used the image?
16:55karolherbst: like.. if the API creates an API image object with READ|WRITE, but the shader it gets bound to only WRITES to it, then access = READ|WRITE and shader_access = WRITE?
17:06zmike: iirc they're usually the same?
17:07zmike: generated from the shader
17:22robclark: karolherbst: one is from the shader, the other is from the api
17:22robclark: actually, I even left a comment explaining precisely that :-P
17:22karolherbst: right.. so e.g. if the application through the API says "host access is READ_ONLY" then access is READ, but if a shader only writes to the image, shader_Access is WRITE
17:23robclark: in particular, it exists so the backend knows coherent/volatile
17:23karolherbst: right
17:23robclark: there are some cases where backend needs to convert format if image is coherent/volatile
17:23robclark: so it is a slow path
17:23karolherbst: right...
18:16panera: can anyone else sign in on gitlab.freedesktop.org at the moment? I'm getting the following error when trying to log in through GitLab: Could not authenticate you from GitLab because "Ssl connect returned=1 errno=0 peeraddr= state=error: sslv3 alert handshake failure".
18:17panera: when I try to register an account on gitlab.freedesktop.org itself, I get a "500" error. ("We're sorry. Something went wrong on our end.")
18:22anholt: panera: temporary server issue, known and being worked on.
18:24panera: okay, thanks.
19:15colemickens: 3 weeks and no commits to mesa-23.2... hm...
19:27alyssa: colemickens: congrats on your new role as release maintainer O:)
19:28colemickens: Hah, I wouldn't wish that on anyone ;). Though I'd also be honored. Or is it terrified? Hm.
19:28colemickens: On a more serious note, itMore just that nixos waits for a +1 point release and I'm trying to figure out if no commits on the branch means its stable, or if there just hasn't been time/capacity for (whatever work might happen).
19:29colemickens: s/itMore/it's More/
19:30colemickens: (definitely a playful curiosity and not meant as a demand of anyone's time)
19:32alyssa: last week was xdc, and we have a shortage of rel maintainers
19:33alyssa: https://youtu.be/qK2Emqp9t0g?t=29129
19:34colemickens: does that imply there's fixes to master that haven't been backported? I assume there's also an element of triaging what's important enough to backport? I guess, aka, a release maintainer.
19:34colemickens: I'm increasingly regretting saying anything
19:34colemickens: haha
19:35alyssa: colemickens: https://docs.mesa3d.org/releasing.html has everything you need to know
19:35colemickens: also, I've been waiting for talks from the conf, it can't possibly be late enough for the conf to have occurred and been uploaded.
21:12anholt: deqp-vk has so many tests now I almost want compressed storage for test names inside of deqp-runner.
21:13sima: colemickens, the talks have been lifestreamed, so it's all there, just needs a bit of educated searching with the program to find the starting point for a talk
21:14sima: unless this is about another conference than xdc
21:16airlied: the videos mostly have links
21:16airlied: to the chapters
21:49mareko: why doesn't Gitlab show any commits here? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25836/commits
21:51mareko: there are multiple MRs where this started happening
21:52dj-death: mareko: probably lost?
21:52dj-death: mareko: it was recommended to repush if that happens
21:52ngcortes: it's happening on mine as well
21:55alyssa: mareko: not sure where the banner went, but the past ~2 days of data were lost due to migration badness
21:55alyssa: authors need to repush
22:01mareko: thanks