01:01 airlied: hmm getting a diagonal seam with one fbfetch test, wierd
01:05 bnieuwenhuizen: airlied: sounds like you pick up something from the render results of the neighbouring pixels?
01:06 airlied: I'm thinking it might be if the first lanes of the mask are off
01:08 airlied: so I'm getting some data in active lanes and wrong data in the active ones
02:03 airlied: doh, forgot it runs 2 fs per 4x4 area, need to add more stride
07:14 MrCooper: anujp: we are merging all Mesa changes via MRs, do not push directly to the main repository
07:18 MrCooper: daniels eric_engestrom tomeu: can I get an R-b / A-b for https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5898 ?
09:31 karolherbst: since when did we remove the git string from the driver version?
09:32 HdkR: karolherbst: Isn't it only removed when building a released version?
09:32 karolherbst: I don't think so
09:32 HdkR: I just built git HEAD yesterday and it was still there
09:32 karolherbst: oohhh.. mhh
09:32 karolherbst: okay, maybe
09:33 HdkR: GL_VERSION: OpenGL ES 3.1 Mesa 20.2.0-devel (git-55776a0ae0)
09:33 HdkR: From built version
09:33 HdkR: GL_VERSION: OpenGL ES 3.1 Mesa 20.0.4
09:33 HdkR: from a release
09:33 eric_engestrom: yay, if you're in a git checkout you get the git version
09:33 karolherbst: okay
09:33 karolherbst: mhh
09:34 eric_engestrom: s/yay/yeah/ (phone autoincorrect)
09:34 HdkR: out of tree build dropping the git version?
09:35 eric_engestrom: hmm good point, I'm not sure if the build dir or the source dir is the one that needs to be in git
09:35 HdkR: I built in-tree for that one
09:36 HdkR: Too late to try an out of tree build tonight :)
09:36 MrCooper: meson doesn't support in-tree builds, do you mean your build directory is inside the source one?
09:36 HdkR: yes
09:37 eric_engestrom: it's the source dir that needs to be in git to get the git sha in the driver version
09:37 eric_engestrom: https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/bin/git_sha1_gen.py#L14
09:37 MrCooper: karolherbst: FWIW, the Git hash can only be appended if the git command is actually installed :)
09:38 eric_engestrom: yup, that too
09:38 karolherbst: right...
10:53 Venemo: imirkin: should degenerate vertices and primitives be filtered out from streamout as well?
10:54 pendingchaos: it looks like streamout writes primitive lists (not primitive strips), so I think they would have to be filtered out
10:54 Venemo: okay
10:56 Venemo: the more I think about it the more I believe that I should add this to nir_lower_gs_intrinsics too. this would also spare us from the vertex liveness check in the NGG GS epilogue
10:56 Venemo: it would also mean that we don't need the exclusive WG scan, only the reduction
10:57 Venemo: if all vertices that the emit threads get are live
11:49 Venemo: pendingchaos: what do you think, will this do? https://gitlab.freedesktop.org/Venemo/mesa/-/commit/c9a0e8a720269edce94cbd0e10005fae9e19e2e2
12:06 pendingchaos: I think that would simplify the vertlive code
12:07 pendingchaos: we still need the exclusive WG scan in case the GS doesn't emit the maximum number of vertices though
12:09 Venemo: why?
12:09 Venemo: we know the exact number that it emits
12:13 pendingchaos: there could be holes in the vertex array if the GS doesn't emit the maximum
12:13 pendingchaos: so you need the exclusive scan to compact and avoid emitting useless vertices
12:14 Venemo: if it doesn't emit the maximum, then the hole will be at the end, won't it?
12:14 Venemo: at least that's what I was aiming for with emit_filter_degenerates
12:15 pendingchaos: there will be unused vertices at the end of the potion of the vertex array reserved for the GS invocation
12:15 pendingchaos: the entire vertex array will have holes in the middle though
12:17 Venemo: oh, I see what you mean
13:49 Venemo: pendingchaos: is shader->info.gs.vertices_out the number of vertices reserved for each GS invocation?
13:52 pendingchaos: yes, it's the maximum number of vertices a GS invocation can emit
14:27 danvet: tzimmermann, another mgag200 series in my inbox but seemingly not on dri-devel?
14:57 tzimmermann: danvet, sorry
14:57 tzimmermann: it's not intentional, i just tent to forget it
14:59 tzimmermann: thanks for pinging me about it
15:17 andrii82: Hello
15:17 andrii82: I have question on userspace drm API. I found a problem in drm_hwcomposer during EDID reading, it uses GetConnectorProperty to get EDID blob ID, and further drmModeGetPropertyBlob to read exact EDID blob. But these two operations not sequenced in drm_hwcomposer. I see that driver/framework changes EDID blob after GetConnectorProperty, which leads to new blob_id and userspace will fetch blob by using old blob_id. I've tried to use these two calls in
15:17 andrii82: sequence(like it was done in modetest) and get the correct result. So I wonder how correctly get EDID using drm? Is there any possibility that even with a sequent call of GetConnectorProperty and drmModeGetPropertyBlob we can potentially get wrong result(race condition with driver?)?
15:26 danvet: andrii82, yeah it's just fundamentally racy
15:26 danvet: but in practice hotplug is slow enough and rare enough it just doesn't matter really
15:27 danvet: there's ideas floating around to do a sequence number for connector state
15:27 danvet: so we could plug the race
15:27 danvet: just no one cares enough to make it happen
15:27 danvet: andrii82, as-is you can't fix it, e.g. redoing the GetConnector and comparing blob id isn't enough
15:28 danvet: since a hotplug might have resulted in the old blob getting deleted, and the new blob getting the same blob id again
15:28 danvet: but with different contents
15:28 danvet: so just do GetConnector, then get all the blobs, call it good enough
15:29 andrii82: danvet, Thanks !
15:32 danvet: andrii82, import bit is just that you listen to hotplug events and do a full reprobe every time you get an event
15:32 danvet: with no clever tricks
15:32 danvet: then worst case you get some bogus intermediate state
15:32 bbrezillon: mattst88, jekstrand: could we consider merging https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5588 ? AFAICT, the 2 intel regressions are not related to those changes
15:36 jekstrand: bbrezillon: Did you do a softfp64 run on Intel?
15:37 jekstrand: It sounds like you were trying to
15:39 bbrezillon: I did it locally, and then pushed to CI hoping that there would be platforms needed this lowering there :)
15:40 jekstrand: ICL needs lowering so you should have seen something
15:40 jekstrand: Though I think we've disabled most fp64 tests there
15:40 jekstrand: But, wait, it's not just fp64; it's just int64
15:40 jekstrand: most of those should be still enabled.
15:40 bbrezillon: it's int64, but the lowering was done in lower_doubles()
15:40 jekstrand: That said, given the work mattst88 put into reviewing it, I'd feel better if he gave you an actual r-b
15:41 jekstrand: bbrezillon: Yeah...
15:41 jekstrand: bbrezillon: Thanks for fixing all that, BTW!
15:41 bbrezillon: oh, sure
15:42 bbrezillon: I was not planning to merge it without his r-b
15:42 bbrezillon: jekstrand: fix? I don't think I fixed anything there
15:44 dviola: hi folks, I was wondering wether this patch will make it for 5.8: https://lore.kernel.org/patchwork/patch/1255315/
15:45 dviola: it fixes a virtio-gpu bug I experienced with QEMU
15:45 dviola: my bug report: https://bugs.launchpad.net/qemu/+bug/1882851
15:45 jekstrand: bbrezillon: You fixed it so that NIR now contains all the needed lowering for int64 :)
15:45 jekstrand: Rather than requiring the GLSL stuff for casts
15:46 dviola: whether*
15:54 imirkin: zmike: can i assume you're the same mike who did https://cgit.freedesktop.org/mesa/mesa/commit/?id=5e9cd64f70af7a8ec9a34590f9b6f6fb3066fae1 ?
15:55 zmike: imirkin: if you think it's a good patch then yes, that's definitely me
15:55 imirkin: hehe
15:55 imirkin: i have no opinion on the patch
15:55 imirkin: however i just wanted to mention something about texcoord's
15:56 imirkin: the reason that texcoord's exist is for point sprite stuff
15:56 imirkin: in GL, point sprites can only be enabled on texcoords, and some hw is sensitive to which outputs are able to get point sprite replacement
15:56 imirkin: i didn't see anything about changing the point sprite stuff in your commit, hence my concern
15:56 zmike: uhhhh
15:57 imirkin: (since you also talk about remapping the outputs, etc)
15:57 imirkin: but i didn't go looking too deep
15:57 imirkin: so perhaps it all works out
15:57 imirkin: just an FYI :)
15:57 zmike: this is purely for translating the glsl location values to spirv
15:58 zmike: and there's no builtins for it on the spirv side
15:58 zmike: so I'm not sure what I could really do with that knowledge considering it's going to come out to the vulkan driver as a (much) higher location than it would if it were going to a gl driver
15:58 zmike: but it's good to add to my limited knowledge of texcoord stuff anyway :)
16:00 zmike: actually, I was just reading a patch of yours imirkin, assuming you're the author of https://cgit.freedesktop.org/mesa/mesa/commit/?id=720ba6ca9745f7b7dc0b5120f3a57d66e2bbe18b
16:00 imirkin: seems like it
16:01 imirkin: although there's a small chance that i don't remember all the details of a patch from 5y ago ;)
16:01 zmike: yeah, I wasn't assuming you would haha
16:02 imirkin: that packing stuff is so confusing.
16:02 imirkin: but it works! and should never be looked at again.
16:02 zmike: well
16:02 zmike: I'm in a good mood, so yes, it definitely works 100% of the time and we don't ever need to think about it again
16:03 imirkin: excellent!
16:03 imirkin: that way someone can go and rewrite it due to lack of maintenance, as determined by lack of changes.
16:04 zmike: right, of course
16:04 zmike: The Way It Must Be Done
16:12 ajax: hah, g200 desktop support, awesome
17:09 sravn: danvet: Is it just me or is kmb a tad too short name for the KeemBay DRM driver? keembay-drm?
17:12 danvet:shrugs
17:12 danvet: if the product doesn't die it's probably going to be another one
17:12 danvet: with a totally different codename, but similar architecture
17:12 danvet: so if this becomes a thing, it'll be meaningless no matter what
17:13 danvet: e.g. i915 is the name of one of the bazillion of chips i915.ko supports
17:13 danvet: I guess it's a bit an intel thing to do that :-)
19:57 airlied: karolherbst: ever get the feeling you are always 2 patches away from conformance :-P
19:58 karolherbst: airlied: yes :p
20:20 karolherbst: airlied: wait until you run the cts-runner :p
20:20 airlied: karolherbst: oh I fixed tha alreday
20:20 airlied: since it takes 3 days to run
20:21 karolherbst: you think :p
20:21 airlied: I even ran it with asan for 3 days
20:21 karolherbst: ohh
20:21 karolherbst: cool
20:21 austriancoder: are there some best practices for 'Call for Proposals' submissions?
20:22 karolherbst: austriancoder: uhm.. just write something? :p
20:24 austriancoder: karolherbst: I am not having too much experiences with cfp .. but yeah .. I really should just write something :)
20:24 karolherbst: austriancoder: you can always ask others to just look over it to see if it makes sense/ is understandable.. but usually those things get decided based on the topic rather than phrasing
20:26 karolherbst: which reminds me.. maybe I should submit something as well... :D
20:29 danvet: austriancoder, if you want can review or something like that
20:29 danvet: occasionally I do that
20:31 danvet: but if this is for xdc, just type and submit
20:31 danvet: bigger conference benefit a bit from marketing polishing on cfps
22:54 Lyude: airlied: have you pulled in drm-misc yet? me and skeggsb were wondering since they think it might be easier if we push the vblank bits in https://patchwork.freedesktop.org/series/78803/ to drm-misc first, then include the nouveau bits with skeggsb's pull
22:55 Lyude: ( cc mripard / mlankhorst )
22:57 airlied: Lyude: I can always pull it in again if it's not insane
22:58 airlied: dont' think I have an outstanding PR for it
22:58 Lyude: airlied: nah, it's pretty easy. should I just go ahead and push then?
22:59 airlied: Lyude: sounds good if all the acks are in place
23:00 Lyude: airlied: lemme try to get in contact with the misc folks then
23:07 Lyude: airlied: i'll let you know if I manage to get in contact with them, hopefully today