00:06 HdkR: karolherbst: Are you saying that I can't use try-catch in mesa?
00:09 jekstrand: jenatali: I'd be happy to land that but I don't think it's strictly required on Intel.
00:09 jenatali: Cool, I'll put it together tomorrow probabl
00:10 jenatali: probably*
00:12 jekstrand: jenatali: We don't want code to sit in the tree forever without being in active use but as long as your CL runtime project isn't too far out, I'm happy to start landing stuff ahead of time as long as we think the quality is good.
00:13 jenatali: jekstrand: Yeah, makes sense. The CL side of things is pretty close to complete - we're getting ready to put together a full set of conformance logs for submission, so it'd make sense to start landing the pieces to common code sooner rather than later
00:15 jekstrand: Oh, wow, that's further along than I thought.
00:15 jenatali: Well, there's still a few math ops that need some fixes to get in line with CL's precision reqs
00:16 jenatali: But other than that I believe we're feature complete for CL1.2
00:34 airlied: jenatali: does it use my libclc spirv stuff?
00:34 airlied: this is me being lazy and not lookling :-P
00:34 jenatali: airlied: Yeah, with the exception of the mangler which I had to move away from LLVM to get the async copy routines working
00:35 jenatali: Er, "async" :P
00:35 airlied: oh yes good, probably need to figure out how to upstream the libclc bits
00:35 jenatali: Yeah, we've got some open MRs against libclc
00:37 jenatali: airlied: https://reviews.llvm.org/D77589, https://reviews.llvm.org/D82078, https://reviews.llvm.org/D83473/
03:04 airlied: karolherbst: DSA error codes changed for GL4.6 and CTS was only updated to test 4 out of 6 of them
03:06 airlied: should be fun for CI ppl to sort out :-P
03:40 airlied: karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5896
03:52 airlied: mattst88: btw I package vulkan for fedora/rhel, if you want to add me to that email I just saw via meeting minutes
03:53 mattst88: airlied: ah, sure thing
03:53 mattst88: I should probably just call into whatever meeting they're discussing it on
03:54 airlied: oh I think they kinda agreed to discuss it on the mail thread
03:54 airlied: I added a comment saying it was pita for fedora/rhel as well
03:54 airlied: I only package SDK releases, and git snapshot all the build deps but it is painful
03:54 mattst88: nice, that's good to hear
03:55 airlied: glslang is like the worst :-P
03:56 mattst88: no kidding
03:56 mattst88: the thing that causes us to finally email people was that shaderc was released while depending on an unreleased glslang
03:57 mattst88: funny enough, they still haven't made a new glslang release
03:58 airlied: and I've no idea what glslang version numbers mean
03:59 mattst88: absolutely nothing, afaict
03:59 mattst88: also, I love the 'master-tot' tag that constantly changes
04:00 mattst88: and how the fetch_sources.py script in VK-GL-CTS has to delete it after fetching glslang
04:00 mattst88: hacks on top of hacks
04:00 imirkin: consultants get paid more that way
05:04 airlied: imirkin: I think glslang could do with someon getting paid more :-P
05:05 imirkin: well, each contractor is paid less, but the contracting house is paid more
05:05 imirkin: so ... someone wins?
08:33 daniels: jenatali: I've added you as a reporter now, since we _probably_ trust you to be able to add labels :P
08:44 danvet: pinchartl, oops just realized I didn't send the reply for your dma-fence annotations questions
08:44 danvet: apologies for that being stuck in drafts folder forever
08:47 pinchartl: danvet: no worries :-)
09:41 danvet: sumits, I plan to start pulling in dma-fence annotations patches
09:41 danvet: any comments on them?
09:56 danvet: sravn, I'm confused by your atmel review ...
09:56 danvet: did you test it or some problem?
09:56 danvet: or should your reply say "did _not_ succeed getting my board operation"?
10:02 sumits: danvet, looking - strangely, I only see a couple of patches, not the whole series? looking at patchwork now
10:02 danvet: sumits, it should be all on dri-devel at least
10:02 danvet: I think I didn't cc you on the entire thing
10:03 danvet: sumits, I think really good would be if you can proof read all the kerneldoc
10:03 sumits: danvet, ok; even in patchworks, the series look a little weird. I'll look and let you know?
10:04 danvet: yeah I accidentally smashed two patches together and had to split them up
10:04 danvet: so patch 3 became 2 patches
10:04 danvet: if it's too confusing I can pick up the current set of acks for the first 3 and resend them
10:07 sumits: danvet, no, I think it should be ok :)
10:36 bbrezillon: karolherbst: sorry to ask you that, again, but would you mind pushing this branch to your intel-ci branch https://gitlab.freedesktop.org/bbrezillon/mesa/-/tree/lower-int64-i2f-f2i ?
10:37 karolherbst: bbrezillon: done
10:37 bbrezillon: karolherbst: thanks!
10:38 FireBurn: See the new feature to allow you to pick which graphics card is used in vulkan with DRI_PRIME, I think there was also another way of doing it, can anyone remember what that was?
10:39 FireBurn: The DRI_PRIME bit is working fine with the Schasa Willams demos but when I launch WC3 I'm only getting Intel graphics no matter what I select - it used to default to RADV up until recently
11:01 karolherbst: does anybody else have issues when "browsing" through MR commits? It seems like the async load sometimes keeps chunks from previous looked at commits etc...
11:44 karolherbst: MrCooper: is your r-by still fine for https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4580/diffs?commit_id=2c2e4139095c7b979c87d70c28d456b882254fe5 ?
11:44 karolherbst: had to resolve some conflicts
11:44 karolherbst: uhm.. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4580/commits?commit_id=2c2e4139095c7b979c87d70c28d456b882254fe5
11:44 karolherbst: ehh.. I should have slept more
11:44 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4580/diffs?commit_id=2c2e4139095c7b979c87d70c28d456b882254fe5
12:20 MrCooper: karolherbst: still fine, bonus points for bumping all tags to July at least :)
12:24 karolherbst: MrCooper: yeah.. I just didn't want to change them as they are already built
12:29 MrCooper: fair enough
14:49 karolherbst: bbrezillon: https://mesa-ci.01.org/karolherbst/builds/150/group/63a9f0ea7bb98050796b649e85481845
14:51 bbrezillon: karolherbst: yep, I had a look and the errors seem unrelated to my changes, but I'll double check
14:51 bbrezillon: thanks
14:52 sravn: danvet: my atmel borad is bogus so no display output. HW issue - unrelated to your patch. So r-b was solely based on code review and not the testing I had planned. Hope this clears it up
14:53 danvet: ah ok, I hope that's good enough :-)
14:54 danvet: sravn, so I guess also no test booting of the entire series to see whether there's any lockdep splat?
14:55 jekstrand: jenatali, karolherbst: Heads up: I think I'm going to add a patch to my branch (which will hit master eventually) to add a scratch_base_ptr system value. The primary change will be that nir_lower_explicit_io will turn deref_type_var into iadd(load_scratch_base_ptr, location) rather than just location.
14:55 MrCooper: karolherbst: argh, that was the wrong call :( https://gitlab.freedesktop.org/mesa/mesa/-/jobs/3604314 https://gitlab.freedesktop.org/mesa/mesa/-/jobs/3604315
14:55 MrCooper: karolherbst: please revert for now, to allow other MRs to be merged
14:55 karolherbst: ehhh
14:56 karolherbst: annoying
14:56 jekstrand: jenatali, karolherbst: It's 100% fine for someone to lower that intrinsic to 0 in their back-end to get the current scratch behavior.
14:58 jenatali: jekstrand: Thanks for the heads up, seems reasonable. I'm curious why not just run a pass to add the offset into the variable locations?
14:59 jekstrand: Call stacks
14:59 jekstrand: :)
14:59 karolherbst: MrCooper: heh, how can I revert a full MR again? :/
15:00 MrCooper: I don't know another way than reverting each commit
15:00 imirkin: git revert takes a range, iirc
15:00 imirkin: if it's a lot
15:00 jekstrand: jenatali: Also, it provides the option to implement scratch as 64-bit global access where load_scratch_base_ptr computes the address of the per-invocation scratch area.
15:01 karolherbst: MrCooper: okay.. will create a MR shortly then
15:01 MrCooper: or just create single commit with the reverse diff
15:01 karolherbst: on a call right now
15:01 jekstrand: jenatali: I don't know that I want that option but I've considered it for some things.
15:01 jenatali: jekstrand: Ah, yeah ok that makes sense. Wasn't thinking that it'd be a runtime-variable offset
15:02 jekstrand: jenatali: Hrm... One could make a case for separate local/global base pointers.
15:02 jekstrand: I don't think I need that for my case but I could see it being useful...
15:04 MrCooper: PSA: the CI pipeline is broken on master, do not try to merge MRs for now
15:07 jenatali: jekstrand: One of the benefits of targeting a different GPU abstraction is I get to pretend a lot of these things don't exist :P
15:08 jekstrand: jenatali: hehe :)
15:08 kisak: MrCooper / karolherbst: hmm? what's going on there? looks like wget is missing here https://gitlab.freedesktop.org/mesa/mesa/-/blob/6f4a6ed0e0b7f5b4746792ec622b5891657163f5/.gitlab-ci/container/cross_build.sh#L23
15:08 jekstrand: jenatali: But you also have some very useful things like 64-bit pointers that don't exist. :-P
15:08 MrCooper: kisak: you're ~13 minutes late ;)
15:09 jenatali: jekstrand: Yeah, no other good way to encode a buffer index/offset in something that will make OpenCL work
15:10 kisak: MrCooper: ah well, sorry for the extra noise then.
15:10 MrCooper: no worries
15:11 jekstrand: A couple years ago, I tried to convince a bunch of people that they didn't need a pointers extension for Vulkan and could just do index+offset and call it a day. They didn't believe me.
15:11 jekstrand: In the end, I think the pointers extension has been a good thing. The changes they forced in NIR have been really good.
15:12 MrCooper: karolherbst kisak: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5905
15:12 kisak: MrCooper: just seems like nonsense to do a revert for that since it looks like wget is being equally used before and after https://gitlab.freedesktop.org/mesa/mesa/-/commit/6f4a6ed0e0b7f5b4746792ec622b5891657163f5
15:12 karolherbst: MrCooper: ack.. and r-by later when I get off the call and have time :D
15:12 jenatali: jekstrand: Yeah we're probably pretty close to doing something similar in D3D/DXIL, though the impact on debugging tools is a little terrifying tbh
15:13 MrCooper: kisak: right, but obviously something else changed in the docker images since they were last built for the MR
15:13 jenatali: But we managed to fake them well enough to be able to support CL in the meantime
15:21 karolherbst: MrCooper: soo.. got off the call now.. annoying issue
15:21 karolherbst: wondering why the MR pipeline didn't catch that...
15:21 karolherbst: ohh..
15:22 karolherbst: I see now
15:22 karolherbst: uff
15:22 MrCooper: yep, too bad I didn't remember this as a major reason for bumping image tags again before merging
15:22 karolherbst: that's not the issue though
15:22 karolherbst: I think
15:22 karolherbst: soo... here is the deal... i386 eg wasn't build on the MR, correct?
15:22 karolherbst: but on master it was
15:22 MrCooper: if the tags were bumped again, it would have been caught pre-merge
15:22 karolherbst: how?
15:23 MrCooper: same as post-merge
15:23 karolherbst: ohh wait..
15:23 karolherbst: ahh yeah, my mistake I looked at the wrong thing
15:24 sravn: danvet: will try to find time tonigh, but focus right now is to find out why my sparc64 qemu hangs when using cfb_ variants
15:29 MrCooper: karolherbst: I created https://gitlab.freedesktop.org/freedesktop/ci-templates/-/issues/14 to gather ideas for preventing this kind of breakage
15:30 karolherbst: I'd rather see the need of updating the tags gone :p
15:31 karolherbst: here is a stupid idea: set the tag to the top commit changing the CI files
15:31 karolherbst: and just rebuilt everything
15:31 karolherbst: and do this automated
15:34 daniels: we could do it in an automated fashion by having a job which wipes out the container image tag, triggered by when marge starts a run in a non-mesa namespace
15:40 MrCooper: karolherbst: that would be very wasteful
15:40 danvet: sravn, yeah no worries, my patches can wait
15:40 danvet: I don't expect to merge them anytime soon
15:40 karolherbst: MrCooper: hence the "stupid" in the sentence
15:41 danvet: at least not the ones with wide impact across drivers, needs lots more testing first to make sure I don't regress anything
15:41 MrCooper: daniels: I thought about something around Marge as well, but the thing is at least in theory the pre-merge pipeline can be triggered by someone else
15:41 daniels: but it really shouldn't be!
15:42 MrCooper: daniels: currently leaning towards ci-templates forcing a rebuild if the target branch is newer than the existing image (and the tag doesn't exist in the upstream registry)
15:43 karolherbst: MrCooper: maybe something like this would help: in some way we tag which contains a MR would change and some bot changes the tags accordingly on the pre merge run?
15:43 karolherbst: would solve problems
15:43 karolherbst: *two problems
15:44 MrCooper: sounds rather like adding another layer of meta-tags where something can go wrong instead :)
15:45 karolherbst: uhhh
15:45 karolherbst: btw.. those fails are not because of my CI change :p
15:45 karolherbst: it's already broken
15:46 karolherbst: ehh.. wget is not installed
15:47 Sachiel: use curl to get wget
15:47 MrCooper: ah, probably due to tomeu's https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5515
15:47 karolherbst: yeah
15:48 MrCooper: which changed cross_build.sh but didn't bump the i386/ppc64el tags
15:48 karolherbst: adding wget as ephermal dep?
15:49 MrCooper: yeah
15:49 karolherbst: ohhh
15:49 karolherbst: it even used to be there
15:52 karolherbst: let's see if it works now: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5906
15:53 MrCooper: actually, I'm afraid as is adding it as ephemeral breaks jobs using the arm_build image (the build of which now uses cross_build.sh)
15:53 MrCooper: tomeu: probably better not to call one image build script from another one like that
15:54 MrCooper: it's too subtle / surprising
15:55 karolherbst: ufff
15:59 jenatali: daniels: I don't think "reporter" status allows me to add labels
15:59 daniels: oh damn, maybe you need developer status to add labels to MRs
16:00 MrCooper: yeah, reporter is only enough for issues I think
16:00 Sachiel: isn't it possible to allow someone to add labels to their own MRs regardless of their role?
16:02 jenatali: jekstrand: I also can't reassign MRs, so feel free to send 5889 to Marge if you think it's ready
16:03 karolherbst: MrCooper: given that we use wget all over.. maybe we should just remove it explicitly in .gitlab-ci/container/container_post_build.sh and install it for the whole stage?
16:03 jekstrand: jenatali: Yup, will do.
16:03 karolherbst: but we also don't clean up other deps...
16:03 jekstrand: daniels, jenatali: No, reporters can add lables
16:03 jekstrand: they should be able to, anyway
16:04 jenatali: Nope: https://i.imgur.com/gU0VHf0.png
16:04 MrCooper: jekstrand: they can on issues, but not on MRs
16:04 jenatali: No edit buttons :(
16:05 MrCooper: karolherbst: not sure what you mean by that
16:05 karolherbst: MrCooper: nvm.. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5906/diffs?commit_id=3a1b352042b1dc921ae27778bf9e174b6438a8d5
16:08 MrCooper: can be purged again after cross_build.sh
16:08 karolherbst: sure?
16:08 MrCooper: reasonably :)
16:08 karolherbst: .gitlab-ci/container/arm_build.sh calls into .gitlab-ci/container/cross_build.sh
16:08 karolherbst: uses wget later :p
16:09 MrCooper: right, that's why it can only be purged after cross_build.sh, not in it
16:09 karolherbst: right..
16:09 karolherbst: but we also don't purge ccmake and other goodies, oh well...
16:09 karolherbst: maybe we should just remove some bits inside .gitlab-ci/container/container_post_build.sh ?
16:10 karolherbst: not sure what "apt-get autoremove -y --purge" removes though
16:10 karolherbst: everything?
16:10 MrCooper: everything without reverse dependencies
16:10 karolherbst: k
16:11 MrCooper: and which wasn't explicitly installed
16:11 MrCooper: not sure what you mean about cmake, that shouldn't be installed for the i386 image?
16:12 karolherbst: I meant arm
16:12 karolherbst: it installs a bunch of things and never removes them
16:12 karolherbst: but maybe that's fine?
16:12 karolherbst: dunno
16:12 MrCooper: sounds like some potential for improvement there
16:12 karolherbst: it does
16:38 karolherbst: MrCooper: anyway, fine by merging it like this for now? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5906 or do you rather see the cleanups as well
16:40 MrCooper: just realized that "apt-get update" is redundant, already done by the templates before these scripts run
16:42 MrCooper: could add the wget purge while removing that :) but OK if you don't want to
16:47 karolherbst: like this? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5906/diffs?commit_id=08710062af5428c403a2c62abc599b5ba1ee9c42
16:54 MrCooper: I'd say either do "apt-get autoremove -y --purge" as well, or just leave wget installed (e.g. by explicitly adding it to the end of the first "apt-get install" in cross_build.sh)
17:03 karolherbst: then I'd go with the second option.. less chances to mess things up
17:04 MrCooper: sounds good
17:04 MrCooper:→ dinner, back tomorrow
17:04 xD_: hi guys
17:05 xD_: i got issues with a new kernel driver
17:05 xD_: Description: Realtek RTL8125 2.5Gigabit Ethernet driver
17:05 xD_: RX_Error frames so speed drops to 200mbits
17:05 karolherbst: xD_: uhh, sorry to hear, but we deal with GPUs, not network devices
17:06 eric_engestrom: xexaxo1`: I'm on a system with glvnd and eglQueryDevicesEXT() doesn't seem to ever call into the ICD, it just returns an empty list
17:07 eric_engestrom: have you tested that setup?
17:07 xD_: oh :)
17:07 xD_: where can i find channel for ethernet drivers?
17:43 jenatali: jekstrand: Didn't realize I had a dependency on a different not-upstreamed change, and was doing the cherry-picks in a separate clone which didn't have a build environment set up... Would appreciate you taking a look at that MR again, had to add a new patch
17:43 jekstrand: ok
17:44 jekstrand: jenatali: done
17:44 jenatali: Thanks, will add r-b
18:13 jenatali: jekstrand: Ready for marge for real this time, if you'd be so kind
18:13 jenatali: oh, you already did, nvm, thanks
19:04 Venemo: Kayden: can I trust NIR to eliminate useless vertex emits from a GS, or do I need to handle the case when a GS emits some vertices that don't actually make up a primitive?
19:08 imirkin: Venemo: i don't think NIR can do that ... that's like solving a turing machine, no?
19:08 imirkin: could be uniform value dependent, for example
19:08 imirkin: for (i = 0; i < uniform; i++) { EmitVertex(); }
19:08 imirkin: what's nir going to do?
19:13 Venemo: imirkin: it could delete them if they are not followed by an end_primitive
19:14 imirkin: they don't need to be
19:14 imirkin: end primitive just cuts a primitive
19:14 Venemo: of course, I guess sometimes the end_primitive might also ve conditional
19:14 imirkin: you can just have 3x EmitVertex and emit a triangle
19:14 imirkin: you don't need an EndPrimitive in there to make it go
19:14 Venemo: oh, I see
19:15 imirkin: all the GS output primitives are strips (except points, obviously)
19:15 imirkin: so if you want to cut the strip and start over at some point, you use EndPrimitive
19:15 Venemo: but there can still be cases when you emit too few vertices to make up a triangle
19:15 imirkin: of course
19:16 Venemo: those should be ignored right?
19:16 imirkin: by the primitive assembly, sure
19:16 Venemo: I think I need to actually check and ignore them
19:17 imirkin: what are you doing again?
19:19 Venemo: I'm implementing NGG GS support in ACO
19:19 Venemo: there is a mismatch between what the hw needs and what the API allows you to do
19:19 #dr19:24 imirkin: but that's not traditinoally how emit vertex works
19:25 Venemo: yeah
19:25 Venemo: with NGG you gotta tell the HW about each primitive individuall@
19:25 Venemo: individually*
19:26 Venemo: basically, each thread can export one primitive
19:26 imirkin: i see
19:27 imirkin: and one primitive = triangle, or one primitive = triangle strip?
19:28 Venemo: each thread can export a triangle
19:28 Venemo: and then a vertex
19:29 Venemo: this also means that we have a bunch of threads that don't really do anything, just export a vertex at the end
19:29 Venemo: or not, depending on how many
19:30 imirkin: i see
19:30 imirkin: so you have to do stuff with EndPrimitive anyways
19:30 imirkin: actually, even without it
19:30 imirkin: what if the GS output type is tristrip
19:30 imirkin: and i emit 4 vertices
19:31 imirkin: you need to emit 2 triangles
19:31 imirkin: so you have to keep track of all this stuff anyways
19:32 Venemo: exactly
19:32 Venemo: some of this I take care of in NIR
19:32 imirkin: so the degenerate vertices are something you should be able to detect easily yourself
19:34 Venemo: possibly, yes
19:35 Venemo: I think I will add some code to my NIR lowering, to account for them
19:41 Venemo: imirkin: so, if the number of emitted vertices since the last end_primitive (or beginning of the shader) is less than N (where N=3 for triangle strips, 2 for line strips and 1 for points), then the primitive is considered a degenerate?
19:42 imirkin: yes
19:42 imirkin: obviously for points it's less of a thing :)
19:43 Venemo: imirkin: is this also the case if there are too few vertices emitted between two end_primitives?
19:43 imirkin: of course
19:43 Venemo: cool
19:45 Venemo: so basically I have to check the number of vertices per primitive and exclude the primitives that don't have enough vertices
19:45 imirkin: yes.
19:46 bnieuwenhuizen: Venemo: the LLVM code already does this though?
19:46 Venemo: bnieuwenhuizen: yes, it does
19:47 Venemo: bnieuwenhuizen: however, it'd be very unwieldy to do some of this in ACO, so we decided to put some parts of it into nir_lower_gs_intrinsics
19:48 Venemo: this issue about the degenerate primitives is something I'm looking into now
19:48 imirkin: i think that makes a ton of sense ... you're adding a lot of fancy logic
19:49 bnieuwenhuizen: yup, agreed on doing it in nir
19:49 bnieuwenhuizen: just got the sense that there was a lot of "how does this work", and I thought the LLVM code would be a good basis there
19:50 Kayden: huh, I never thought to try and just pitch degenerate primitives
19:51 imirkin: Kayden: well, when hw does it for you ... seems easiest, esp since it's for conformance
20:05 Venemo: bnieuwenhuizen: yes, I obviously read that but it's not the most the starightforward to read code in the world
20:06 imirkin: so ... straightforward, just not *the most* straightforward...
20:09 Venemo: imirkin: I'll be honest with you, if I were more experienced, it would probably make a lot more sense
20:09 imirkin: i was being sarcastic
20:09 imirkin: llvm code is basically unreadable
20:10 Venemo: nah
20:10 imirkin: at least if you're not already intimately familiar with the llvm codebase
20:10 imirkin: (which i am not)
20:10 Venemo: we're talking about the llvm backend code in mesa, not the actual llvm codebase
20:10 imirkin: as for the graphics stuff, yeah, if you're not familiar with the graphics pipeline then some of these things aren't obvious
20:10 imirkin: but gotta learn somehow
20:10 Venemo: yeah.
20:10 imirkin: i learned how GS worked by adding support for it in nouveau
20:11 imirkin: some short 7 years ago
20:11 imirkin: looks like i still remember something about it :)
20:11 Venemo: now that you explained the degenerate prims, I believe I understand why the llvm backend does what it does.
20:11 qyliss: /go
20:12 imirkin: cool
20:25 zmike: can someone please marge https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5551
21:52 robclark: anyone know offhand what spec says about interaction between atomic counters and depth/stencil test? I assume we are supposed to maintain the illusion that z/s test is after FS, but it looks a lot like dEQP-GLES31.functional.image_load_store.early_fragment_tests.early_fragment_tests_stencil_fbo is expecting the opposite behavior..
21:53 robclark: ie. expecting the # of times the counter is incremented matches the # of fragments that pass stencil test
21:54 jekstrand: robclark: Depends on early fragment tests
21:54 jekstrand: robclark: There's a shader bit that lets the client request early tests
21:55 jekstrand: If early tests are requested, atomics shouldn't happened if the test fails.
21:55 robclark: oh, and in fact it is enabling that
21:55 jekstrand: If early tests are not requested, we have to maintain the illusion
21:55 robclark: interesting, I assumed that bit was more an optimization hint than requirement..
21:55 jekstrand: On Intel, we do so by setting the "this shader might discard" bit
21:56 jekstrand: Well, actually, for early fragment tests I think we might have something more specific than that
21:56 robclark: discard is a bit diff.. since if there is discard I can still do early-lrz test but late-z test..
21:56 robclark: but ok, that explains why shifting to late-z breaks it
21:57 jekstrand: robclark: shader_info::fs::early_fragment_tests
21:58 robclark: yeah, looking at that
21:58 robclark: thx
21:58 jekstrand: Hrm... Yeah, we actually have special bits for it
21:58 jekstrand: There's something else we use discard to hack
22:19 jekstrand: jenatali: I'm using your patches now. :) https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5909
22:19 jekstrand: airlied: That should be most of what's needed to get function/local pointers to work in iris+clover ^^
22:32 airlied: imirkin: are the generated tests in piglit all there is to test framebuffer eftch?
22:33 imirkin: i wasn't involved with that ext ... i did the FBFETCH thing but only for advanced blend
22:33 airlied: imirkin: ah cool
22:33 imirkin: (so i have no additional info about any potential tests)
22:34 airlied: imirkin: I suppose I could just debug the adv blend tests then :-P
22:35 imirkin: i didn't implement that ext either, just the gallium plumbing :)
22:35 airlied: ah deqp has some fetch bits
22:36 airlied: but only for coherent it looks like
22:36 imirkin: there's no non-coherent variant in EXT
22:36 imirkin: i think curro made a MESA variant?
22:38 jekstrand: I don't think it ever shipped as an extension
22:39 jenatali: jekstrand: Awesome :)
22:40 airlied: I suppose I can expose coherent actually
22:40 jekstrand: airlied: on LLVMpipe? yeah, you probably can
22:41 airlied:attempts go get on the gles 3.2 train
22:42 jekstrand: gles 3.2 is overrated
22:43 airlied: jekstrand: I just want to avoid having to build a cts submission again :P
22:43 imirkin: but if you have GL 4.5 and astc, you don't need much more
22:43 HdkR: GL 4.6 is where the hype is
22:43 jekstrand: Oh, I'm not saying it's hard :)
22:43 jekstrand: HdkR: FP64 all the way!
22:43 airlied: building a CTS package is harder :-P
22:43 jekstrand: airlied: Only having to do one CTS submission is a 100% valid excuse IMO
22:44 airlied: I wonder is anisotropic texture filtering in sw is a good gsoc
22:45 jekstrand: I don't know
22:45 HdkR: Deprecate FP64, all we need is FP80
22:46 curro: airlied, imirkin, jekstrand: The initial MESA framebuffer fetch extension I proposed never shipped as an extension because I submitted as an EXT extension to Khronos in the end
22:47 curro: so yes there is a non-coherent variant of the EXT extension now, we expose it on most intel parts
22:49 jekstrand: Oh, I hadn't realized that went through.
22:49 jekstrand: Last I'd heard you were dealing with and endless stream of review nits.
22:49 jekstrand: Glad to be reminded that it shipped. :)
22:50 curro: yeah it took quite some effort but it made it into the registry in the end
22:53 imirkin: HdkR: just do FP128. that way everyone suffers.
22:55 HdkR: imirkin: POWER laughing all the way? :D