00:05bnieuwenhuizen: airlied: I believe so (on rem vs. mod)
00:42anholt_: ooh, grayscale gears. that's a new failure for me.
00:43imirkin: single color gets splatted across all channels?
00:43Kayden: hah, haven't seen that one
00:43anholt_: surely a bad nir_op_vec4, having just typed that
00:45imirkin: you know you've been staring at glxgears too long when you notice rgb vs bgr confusion :)
00:46Kayden: one time we had an android bug creep in where we did RGB vs. BGR swap. But nobody had noticed because it got tested by playing a game...that happened to be greyscale intentionally. :)
05:05Kayden: I don't understand src/mesa/state_tracker/tests/st_format.c
05:05Kayden: it just does: assert(!st_compressed_format_fallback(st, i));
05:05Kayden: so if you are trying to fake ETC or ASTC or something, the test just dies, making MR pipelines die
05:06Kayden: it seems like the only way that isn't causing gitlab CI to fail is because radeonsi isn't in gitlab CI
05:39imirkin: Kayden: i saw a lot of rework in that area, perhaps something got broken
05:39imirkin: i can say with some certainty that etc2/astc fallbacks did work in the past
05:50Kayden: oh, they work fine as far as I can tell
05:50Kayden: just the test flat out asserts that you aren't using them
05:51imirkin: well, iirc we may have made sure that you had the fallback enabled if you didn't support it?
05:52imirkin: the gallium driver shouldn't expose support for a format that st is trying to do fallbacks on
05:52imirkin: that'd just confuse everything
05:52imirkin: perhaps it's asserting that
05:52imirkin: (or trying to)
15:16sravn: j4ni: ack or any feedback on "[PATCH v2 0/2] drm: document logging functions"?
15:33MrCooper: Kayden: st_format_test doesn't use or even load any Gallium drivers AFAICT
15:39sravn: tagr: Any chance you can have a look at "[PATCH v2 0/2] combine bindings for simple panels in a few files". We need your feedback to proceed here. TIA
15:41MrCooper: kusma: are you aware that zink renders glxgears incorrectly (with RADV on Kaveri)?
15:43MrCooper: I guess flat shading might be tricky to handle
15:43ccr: I think Zink renders it incorrectly on other platforms too, at least the gear tooth shading is wrong on i965
16:08kusma: MrCooper: Yeah, it's always wrong, due to mismatching provoking vertex.
16:09kusma: MrCooper: I need to implement a dummy-geometry shader, and a pass that reorders the vertices
16:11MrCooper: ugh :)
16:11kusma: Yeah :/
16:35robclark:finds needing a GS to render glxgears kinda funny
17:10ccr: kusma, oh hai :) are you "interested" in any zink issues where it works on OpenGL but looks rather wrong with Zink?
17:10kusma: ccr: absolutely :)
17:12ccr: kusma, something like this: https://tnsp.org/~ccr/bunny-gl.png vs https://tnsp.org/~ccr/bunny-zink.png (pardon the large screenshots)
17:14kusma: Oooh, that's... very wrong :P
17:14anholt_: kusma: have you done any looking into CI for zink? would love to offer pointers if it would help get it tested.
17:14ccr: kusma, indeed, the poor bunny. do you prefer that I write a ticket in Mesa gitlab or .. ?
17:15kusma: anholt_: I have started looking a bit into it, but not gotten very far yet. My problem so far was to get SwiftShader working first, which, uh... has different requirements that most actual GPUs ;)
17:16kusma: ccr: do you have a way I can run that application?
17:16anholt_: kusma: cool, that was what I was thinking for CI.
17:16anholt_: kusma: hopefully soon we get cheza on LAVA, and then you could just run it on hardware if you were willing to tolerate an incomplete vulkan :)
17:17ccr: kusma, sure, it's a "fork" of glxdragon I extended. a Mercurial repo is at https://tnsp.org/hg/forks/gldragon/ , can also provide tarball if that is preferred.
17:17anholt_:wishes Intel would sponsor some machines for gitlab CI.
17:17kusma: anholt_: Yeah, I think the biggest problem is that pretty much everything fails when I run on switfshader, because swiftwhsader is strange (but within spec) when it comes to linear vs tiled features for formats.
17:17kusma: ccr: cool, thanks.
17:18kusma: gotta go now, back later
17:31bnieuwenhuizen: kusma: weird in what way wrt tiled and linear features?
20:20kusma: bnieuwenhuizen: don't really remember the details from last I looked, but it was hard to get the format-features supported to work well..
20:20kusma: ccr: thanks for the link, I'll take a look.
20:21kusma: bnieuwenhuizen: I think it's mostly my fault, as I try to pick optimal tiling for a format first, and then "fall back" to linear.
20:22kusma: bnieuwenhuizen: If I remember correctly, part of the problem is that gallium asks if a certain feature is supported by the format, not if it's supported for a given layout.
20:28airlied: kusma: my llvmpipe vulkan layer is approaching basic conformance
20:28airlied: llvmpipe vulkan gallium state tracker rather
20:30kusma: airlied: awesome :)
20:37ccr: kusma, great. I should perhaps note that I've only tested the issue on intel HD graphics 4600 aka Haswell, for which the Mesa Vulkan implementation is warned to be incomplete. so I suppose it might not be a problem in Zink, but I can't confirm.
21:00kusma: ccr: Sure, I'll test on my system :)
21:02kusma: jekstrand: I'm hitting an assert in the ANV driver "src/intel/vulkan/genX_pipeline.c:406: emit_3dstate_sbe: Assertion `source_attr >= 0 && source_attr < 32' failed.", when using more than 16 varyings. With i965 and Iris, I can use 32 varyings... am I going crazy, or am I doing something wrong? :)
21:03jekstrand: kusma: How many more?
21:04jekstrand: I think we advertise 28
21:04kusma: jekstrand: as soon as I cross 16
21:04jekstrand: That seems wrong
21:04kusma: jekstrand: iris advertise 32, didn't check the exact number for i965
21:04jekstrand: It's believable though
21:05kusma: jekstrand: I might be doing something bad, this is going through zink...
21:05jekstrand: 16 varyings is a magic number for fragment shaders for us
21:05jekstrand: so I can totally believe you'd hit a problem there
21:06jekstrand: kusma: Can you break in GDB? What is source_attr?
21:06kusma: jekstrand: yeah, I can
21:07kusma: (https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/drivers/iris/iris_screen.c#L305 <- iris reporting 32)
21:07jekstrand: Actually, "bt full" if you can
21:07jekstrand: Yeah, I know iris and i965 report 32. We have to burn a couple for magic stuff
21:07jekstrand: And Vulkan has some really mean tests that use EVERYTHING
21:07jekstrand: And they hit the limits hard
21:07bnieuwenhuizen: well, those tests are good then :)
21:08kusma: source_attr is 32
21:09kusma: slot is 34, attr 61
21:11jekstrand: Yeah, 61 is VARYING_SLOT_VAR<N> where <N> is fairly large. Larger than 16
21:11jekstrand: Double-check your SPIR-V locations?
21:12kusma: Oh, sorry. I changed things a bit again since I lowered it again.
21:12kusma: I report max varyings as maxFragmentInputComponents / 4 atm. I'll change it back below 16 and see.
21:14jekstrand: 24 should be fine
21:14jekstrand: just not 32
21:15kusma: here's my locations (still using 32): https://pastebin.com/N27gkSM5
21:15kusma: let's try again with fewer :)
21:17kusma: breaks if I report 18 or more
21:17kusma: Right. I still generate high numbers, because they're not packed...
21:18kusma: So yeah, same bindings as posted above, because the test tries to add one until it fails, so it fails at the lowest possible..
21:19kusma: jekstrand: So I guess the question is if the locations needs to be tight or not.
21:19kusma: *read spec*
21:20jekstrand: kusma: Looks like we may be advertising one too many components
21:20bnieuwenhuizen: "Each effective Location must have a value less than the number of locations available for the given interface, as specified in the "Locations Available" column in Shader Input and Output Locations."
21:22kusma: jekstrand: Right. That's not the end of it, though, because it fails for me even with 18, which is quite a bit fewer...
21:22jekstrand: kusma: That's because you're using high numbers
21:23jekstrand: I think the problem is a combination of using point size or pos together with location 30
21:23kusma: jekstrand: Right, but is that disallowed? I haven't seen that in the spec yet...
21:23bnieuwenhuizen: kusma: see my quote above
21:23kusma: ah, thanks. silly me.
21:24kusma: OK, then I need to start assigning locations a bit smarter than now :/
21:24bnieuwenhuizen: jekstrand: if you only use a few fragment inputs is tight more efficient than sparse on intel HW?
21:27jekstrand: kusma: Yeah, I think we're wrong in the number of components we advertise. :(
21:27kusma: ccr: looks garbled here also :-P
21:27kusma: jekstrand: Wohoo, room for improvements! ;)
21:27jekstrand: bnieuwenhuizen: It shouldn't make much of a difference. We compact
21:28kusma: also, room for improvement in the validator here :-P
21:28kusma: (that, or the os-package I have is out of date)
21:29ccr: kusma, good .. uh, I mean: bad :P
21:34kusma: ccr: it looks quite different here, though.. :-P
21:34kusma: but same "kind" of problem (vertices not where they're supposed to)
21:34ccr: kusma, if you mean the dragon instead of bunny, yes :)
21:35kusma: ccr: oh, there's more?
21:35kusma: right, it renders a dragon here, not a bunny :-P
21:35ccr: well, the repo only has two models, try: "./gldragon cube.scene" for example
21:36kusma: ccr: oh, that's interesting... the cube looks even more... crazy :-P
21:37kusma: kinda looks like triangle-strips with the wrong starting-point or something
21:37ccr: kusma, https://tnsp.org/~ccr/scenes.tar.xz more scene/ply files in that, including the bunny. probably not very helpful tho :)
21:38kusma: yeah, I don't think the model itself makes a difference
21:40ccr: well .. actually there seems to be something about that, too. an interesting tidbit is that this commit in Mesa https://gitlab.freedesktop.org/mesa/mesa/commit/c6ef79c488bb5fffde31e7065fd3e575f3c25fb5 made some of the models look okay, but not all of them (dragon being one of the NOT okay ones.)
21:40kusma: OK, so there's no strps or anything in there...
21:40ccr: but that commit seems to have been reverted later
21:42ccr: personally I am clueless to why that patch could've affected things, but it did.
21:44bnieuwenhuizen: ccr: just for reference, it works with another gallium driver right?
21:45ccr: bnieuwenhuizen, I have no idea unfortunately, I've only got my own hardware to test :/
21:45ccr: bnieuwenhuizen, and Haswell is i965-only, so can't test Iris
21:46kusma: bnieuwenhuizen: yeah, works fine on iris
21:47jekstrand: kusma: No, your driver is advertising the wrong number. :-(
21:47kusma: ccr: that code is used for uploading user vertex-buffers to VBOs, and I guess I'm just not advertising the right caps somehow to it.
21:48ccr: kusma, ah. though it did not make all cases better tho, but several.
21:50kusma: jekstrand: :-/
21:51jekstrand: kusma: Maybe we aren't compacting.....
21:52kusma: jekstrand: well, as bnieuwenhuizen pointed out, I'm violating the spec anyway, so yeah... Oh, but yeah, I guess 30 should have worked?
21:53kusma: no, it shouldn't have worked, it's reporting 29 as the max
21:53kusma: So yeah, I'm the bad boi here.
21:54kusma: (maxFragmentInputComponents / 4 = 29)