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