omegatron has quit [Quit: What happened? You quit!]
<zmike>
kusma: have you tested your llvmpipe changes with any of my lavapipe MRs yet?
<kusma>
zmike: No... I'm not doing this in the scope of Zink, it's some work I'm doing to help out the VirGL people getting rid of needless CI failures.
<zmike>
sure, but I think it's probable that you've coincidentally fixed all the issues I had
<zmike>
and those aren't zink MRs
<zmike>
they're lavapipe MRs
<kusma>
zmike: I can give it a spin, sure.
<kusma>
zmike: Is there more than !11066 that I should test on top of this?
<zmike>
ah, I think I probably need to update it to remove some of the multisample hacks with your changes?
<zmike>
I don't remember if those are in the actual MR or just comments
<zmike>
the widelines one is probably a better test case
<kusma>
Might be, I haven't really looked too closely to yours.
<kusma>
I might be hardcoding some OpenGL specific semantics in my MR, though.
<kusma>
TBH, it would be best if gallium fully specified the line rasterization mode...
<zmike>
my understanding is that GL line spec is just bresenham/non-strict VK line spec
<kusma>
Well, kinda-ish. There's two toggles that changes the rules, smooth and multisampling
<zmike>
right
<zmike>
but I think they're consistent across the specs
<kusma>
It's really "paralellogram / bresenham" vs orthogonal rectangles.
<kusma>
Yeah, there's some details I'm not really understanding though.
<kusma>
For instance what vulkan's difference between default / bresenham really is.
<zmike>
default can be bresenham if it's non-strict
<kusma>
Can be, sure. But I actually think bresenham does the right thing for strict lines as well, maybe apart from the end-points.
<zmike>
it seems improbable to me that the vk spec would include a blurb explicitly allowing non-strict line implementations to use bresenham if strict was also bresenham
<kusma>
I agree, but that's how I read the spec 🤷♂️
<zmike>
the line spec is very confusing.
<kusma>
For sure.
<kusma>
The GL spec is much better here if you ask me :P
<zmike>
the only difference I can imagine is that jekstrand didn't write the GL spec
<kusma>
I think maybe the spec is the way it is because of Intel, who can't really do correct lines...
<kusma>
So there's the "we're not conformant, so we have the strictLines thing". But then they also can do bresenham lines, if you loosen the definition for that a bit.
<kusma>
I dunno.
<zmike>
well nothing says we gotta be line-ologists to pass tests
<kusma>
Sure.
<kusma>
But I kinda am ;)
<jekstrand>
zmike: what?
<zmike>
just shitposting
<kusma>
Line rasterizing is something I've spent quite a lot of time on in the past :P
<kusma>
(and maybe designed some hw for and filed some patents etc)
<kusma>
jekstrand: how does strictLines and bresenham differ in Vulkan? Is it just about the end-points, or is there something else I'm missing?
<jekstrand>
I don't remember
<jekstrand>
strictLines is weird and !strictLines aparently also has strict rules.
<zmike>
kusma: were you intending to rb !11189 at some point?
<kusma>
Oh, I just forgot to say the magic words, sorry! RB!
<zmike>
👍
adjtm has left #zink [Leaving]
<zmike>
this glx thing is a huge wtf
<hch12907>
on a scale of zero to "how did this even manage to run", how wtf is it?
<zmike>
on that scale it's a zero
<zmike>
the wtf is how this isn't an issue for other drivers
<kusma>
zmike: we fail dEQP-VK.rasterization.primitives_multisample_4_bit.static_stipple.bresenham_line_strip on top of my series... I'm testing a patch that disables msaa in the case, might be enough to pass the cts :P
<zmike>
I think that one was failing before your fixups too?
<kusma>
zmike: sure... was there any other failures?
<zmike>
uhhhh
<zmike>
check the pipelines?
<zmike>
I think there was 1 or 2
<kusma>
🤷♂️
<kusma>
Can't be bothered right now ;)
<kusma>
I'll see what happens here
<kusma>
I think that was the only failure, and I think it's kinda-sorta the right thing to do, even if the code is nasty.
<zmike>
wfm
<zmike>
rb shipit let's goooo
<kusma>
:D
<zmike>
hnnnnggg this queue rewrite is getting really good