00:05 bnieuwenhuizen: airlied: I believe so (on rem vs. mod)
00:42 anholt_: ooh, grayscale gears. that's a new failure for me.
00:43 imirkin: single color gets splatted across all channels?
00:43 anholt_: yeah
00:43 Kayden: hah, haven't seen that one
00:43 anholt_: surely a bad nir_op_vec4, having just typed that
00:45 imirkin: you know you've been staring at glxgears too long when you notice rgb vs bgr confusion :)
00:46 Kayden: 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. :)
00:51 imirkin: hehe
05:05 Kayden: I don't understand src/mesa/state_tracker/tests/st_format.c
05:05 Kayden: it just does: assert(!st_compressed_format_fallback(st, i));
05:05 Kayden: so if you are trying to fake ETC or ASTC or something, the test just dies, making MR pipelines die
05:06 Kayden: it seems like the only way that isn't causing gitlab CI to fail is because radeonsi isn't in gitlab CI
05:39 imirkin: Kayden: i saw a lot of rework in that area, perhaps something got broken
05:39 imirkin: i can say with some certainty that etc2/astc fallbacks did work in the past
05:50 Kayden: oh, they work fine as far as I can tell
05:50 Kayden: just the test flat out asserts that you aren't using them
05:51 imirkin: well, iirc we may have made sure that you had the fallback enabled if you didn't support it?
05:52 imirkin: the gallium driver shouldn't expose support for a format that st is trying to do fallbacks on
05:52 imirkin: that'd just confuse everything
05:52 imirkin: perhaps it's asserting that
05:52 imirkin: (or trying to)
15:16 sravn: j4ni: ack or any feedback on "[PATCH v2 0/2] drm: document logging functions"?
15:33 MrCooper: Kayden: st_format_test doesn't use or even load any Gallium drivers AFAICT
15:39 sravn: 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:41 MrCooper: kusma: are you aware that zink renders glxgears incorrectly (with RADV on Kaveri)?
15:43 MrCooper: I guess flat shading might be tricky to handle
15:43 ccr: I think Zink renders it incorrectly on other platforms too, at least the gear tooth shading is wrong on i965
16:08 kusma: MrCooper: Yeah, it's always wrong, due to mismatching provoking vertex.
16:09 kusma: MrCooper: I need to implement a dummy-geometry shader, and a pass that reorders the vertices
16:11 MrCooper: ugh :)
16:11 kusma: Yeah :/
16:35 robclark:finds needing a GS to render glxgears kinda funny
17:10 ccr: kusma, oh hai :) are you "interested" in any zink issues where it works on OpenGL but looks rather wrong with Zink?
17:10 kusma: ccr: absolutely :)
17:12 ccr: kusma, something like this: https://tnsp.org/~ccr/bunny-gl.png vs https://tnsp.org/~ccr/bunny-zink.png (pardon the large screenshots)
17:14 kusma: Oooh, that's... very wrong :P
17:14 anholt_: kusma: have you done any looking into CI for zink? would love to offer pointers if it would help get it tested.
17:14 ccr: kusma, indeed, the poor bunny. do you prefer that I write a ticket in Mesa gitlab or .. ?
17:15 kusma: 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:16 kusma: ccr: do you have a way I can run that application?
17:16 anholt_: kusma: cool, that was what I was thinking for CI.
17:16 anholt_: 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:17 ccr: 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:17 anholt_:wishes Intel would sponsor some machines for gitlab CI.
17:17 kusma: 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:17 anholt_: huh
17:17 kusma: ccr: cool, thanks.
17:18 kusma: gotta go now, back later
17:31 bnieuwenhuizen: kusma: weird in what way wrt tiled and linear features?
20:20 kusma: 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:20 kusma: ccr: thanks for the link, I'll take a look.
20:21 kusma: 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:22 kusma: 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:28 airlied: kusma: my llvmpipe vulkan layer is approaching basic conformance
20:28 airlied: llvmpipe vulkan gallium state tracker rather
20:30 kusma: airlied: awesome :)
20:37 ccr: 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:00 kusma: ccr: Sure, I'll test on my system :)
21:02 kusma: 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:03 jekstrand: kusma: How many more?
21:04 jekstrand: I think we advertise 28
21:04 kusma: jekstrand: as soon as I cross 16
21:04 jekstrand: That seems wrong
21:04 kusma: jekstrand: iris advertise 32, didn't check the exact number for i965
21:04 jekstrand: It's believable though
21:05 kusma: jekstrand: I might be doing something bad, this is going through zink...
21:05 jekstrand: 16 varyings is a magic number for fragment shaders for us
21:05 jekstrand: so I can totally believe you'd hit a problem there
21:06 kusma: Right
21:06 jekstrand: kusma: Can you break in GDB? What is source_attr?
21:06 kusma: jekstrand: yeah, I can
21:07 kusma: (https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/drivers/iris/iris_screen.c#L305 <- iris reporting 32)
21:07 jekstrand: Actually, "bt full" if you can
21:07 jekstrand: Yeah, I know iris and i965 report 32. We have to burn a couple for magic stuff
21:07 jekstrand: And Vulkan has some really mean tests that use EVERYTHING
21:07 jekstrand: And they hit the limits hard
21:07 bnieuwenhuizen: well, those tests are good then :)
21:08 kusma: source_attr is 32
21:09 kusma: slot is 34, attr 61
21:11 jekstrand: Yeah, 61 is VARYING_SLOT_VAR<N> where <N> is fairly large. Larger than 16
21:11 jekstrand: Double-check your SPIR-V locations?
21:12 kusma: Oh, sorry. I changed things a bit again since I lowered it again.
21:12 kusma: I report max varyings as maxFragmentInputComponents / 4 atm. I'll change it back below 16 and see.
21:14 jekstrand: 24 should be fine
21:14 jekstrand: just not 32
21:15 kusma: here's my locations (still using 32): https://pastebin.com/N27gkSM5
21:15 kusma: let's try again with fewer :)
21:17 kusma: breaks if I report 18 or more
21:17 kusma: Right. I still generate high numbers, because they're not packed...
21:18 kusma: 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:19 kusma: jekstrand: So I guess the question is if the locations needs to be tight or not.
21:19 kusma: *read spec*
21:20 jekstrand: kusma: Looks like we may be advertising one too many components
21:20 bnieuwenhuizen: "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:22 kusma: 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:22 jekstrand: kusma: That's because you're using high numbers
21:23 jekstrand: I think the problem is a combination of using point size or pos together with location 30
21:23 kusma: jekstrand: Right, but is that disallowed? I haven't seen that in the spec yet...
21:23 bnieuwenhuizen: kusma: see my quote above
21:23 kusma: ah, thanks. silly me.
21:24 kusma: OK, then I need to start assigning locations a bit smarter than now :/
21:24 bnieuwenhuizen: jekstrand: if you only use a few fragment inputs is tight more efficient than sparse on intel HW?
21:27 jekstrand: kusma: Yeah, I think we're wrong in the number of components we advertise. :(
21:27 kusma: ccr: looks garbled here also :-P
21:27 kusma: jekstrand: Wohoo, room for improvements! ;)
21:27 jekstrand: bnieuwenhuizen: It shouldn't make much of a difference. We compact
21:28 kusma: also, room for improvement in the validator here :-P
21:28 kusma: (that, or the os-package I have is out of date)
21:29 ccr: kusma, good .. uh, I mean: bad :P
21:34 kusma: ccr: it looks quite different here, though.. :-P
21:34 kusma: but same "kind" of problem (vertices not where they're supposed to)
21:34 ccr: kusma, if you mean the dragon instead of bunny, yes :)
21:35 kusma: ccr: oh, there's more?
21:35 kusma: right, it renders a dragon here, not a bunny :-P
21:35 ccr: well, the repo only has two models, try: "./gldragon cube.scene" for example
21:36 kusma: ccr: oh, that's interesting... the cube looks even more... crazy :-P
21:36 ccr: yep
21:37 kusma: kinda looks like triangle-strips with the wrong starting-point or something
21:37 ccr: kusma, https://tnsp.org/~ccr/scenes.tar.xz more scene/ply files in that, including the bunny. probably not very helpful tho :)
21:38 kusma: yeah, I don't think the model itself makes a difference
21:40 ccr: 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:40 kusma: OK, so there's no strps or anything in there...
21:40 ccr: but that commit seems to have been reverted later
21:42 ccr: personally I am clueless to why that patch could've affected things, but it did.
21:44 bnieuwenhuizen: ccr: just for reference, it works with another gallium driver right?
21:45 ccr: bnieuwenhuizen, I have no idea unfortunately, I've only got my own hardware to test :/
21:45 ccr: bnieuwenhuizen, and Haswell is i965-only, so can't test Iris
21:46 kusma: bnieuwenhuizen: yeah, works fine on iris
21:46 bnieuwenhuizen: okay
21:47 jekstrand: kusma: No, your driver is advertising the wrong number. :-(
21:47 kusma: 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:48 ccr: kusma, ah. though it did not make all cases better tho, but several.
21:50 kusma: jekstrand: :-/
21:51 jekstrand: kusma: Maybe we aren't compacting.....
21:52 kusma: jekstrand: well, as bnieuwenhuizen pointed out, I'm violating the spec anyway, so yeah... Oh, but yeah, I guess 30 should have worked?
21:53 kusma: no, it shouldn't have worked, it's reporting 29 as the max
21:53 jekstrand: Right
21:53 kusma: So yeah, I'm the bad boi here.
21:54 kusma: (maxFragmentInputComponents / 4 = 29)