<kusma>
But that's what I believe is CTS bugs, as I said.
<kusma>
Still need to fix that, though :(
<kusma>
Hmm, no. There's some more issues than that... Missing alpha transparency for the VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_EXT-case...
<kusma>
airlied: Does Lavapipe even use the draw-module? If not, that would probably explain something ;)
<airlied>
kusma: nope lines are all done in llvmpipe afaik
<airlied>
but I'm not 100% confident in that statement
<kusma>
airlied: apart from line_smooth, I think?
<airlied>
yes I think smooth is the draw module stage
<kusma>
Ah, nevermind. I guess llvmpipe uses the draw module, so lavapipe doesn't have to.
<airlied>
yeah it's all hidden from lavapipe
<kusma>
Ah, maybe I finally have a test-case I can use to fix the needless trig in draw_pipe_aaline.c then!
<kusma>
I mean:
<kusma>
float a = atan2f(dy, dx);
<kusma>
float c_a = cosf(a), s_a = sinf(a);
<kusma>
That's a long way of writing a vector normalize ;)
<kusma>
Or at least a slow way.
<kusma>
(we're already calculating the length of the vector)
<kusma>
Doh, OK. Gallium semantics is "if we have multisampling, ignore line smoothing", it seems.
<kusma>
I'm not really sure why, though. The OpenGL spec literally says " If only points or lines are being rendered, the “smooth” antialiasing mechanism provided by the base GL may result in a higher quality image. This mechanism is designed to allow multisample and smooth antialiasing techniques to be alternated during the rendering of a single scene".
<kusma>
OK, no. Disabling that is the right thing to do, after reading the spec again.
<kusma>
We can solve this for Lavapipe with more disable_multisample tweaks.
omegatron has joined #zink
<kusma>
How are we feeling about emoji in comments? 😆
<zmike>
given that it's the only thing keeping zink from 3.2, I agree
<jekstrand>
That's the thing. You can totally do it in Zink.
<zmike>
?
<zmike>
if you're talking fbfetch, that's not legally portable
<jekstrand>
You just have to use an input attachment to implement framebuffer_fetch_non_coherent and core Mesa will give it to you for free.
<jekstrand>
You don't need full fbfetch, just the non-coherent version
<zmike>
huh
<zmike>
I thought I needed full fbfetch
<jekstrand>
Nope
<jekstrand>
blend advanced requires barriers between every draw
<jekstrand>
precisely because no one but nvidia and tilers can do that nonsense
<zmike>
well shit
<kusma>
There's two extensions, one for coherent and one without. I think sadly the wrong one is required for es 3.2?
<jekstrand>
I mean, we can do it without the barrier on SKL+ with a combination of "real" FB fetch and interlock, I think.
<jekstrand>
But not on older hardware and AMD can't do "real" FB fetch at all.
<jekstrand>
kusma: No, es 3.2 has the one that non-coherent version so it's fine.
<jekstrand>
kusma: We support ES 3.2 on hardware that can't do coherent FB fetch.
<zmike>
ughhh this is gonna suck to jam into the current architecture though
<zmike>
unless...
<zmike>
gonna need to hit the gym to get my brain swole enough to comprehend this idea
<kusma>
Just say we support it and start formatting the hard drive of the user if they try using it
<zmike>
jekstrand: which nir pass does the lowering for that?
<jekstrand>
zmike: nir_format_hdd()
<jekstrand>
Or are you referring to ARB_blend_stupid?
<zmike>
yes
<zmike>
not getting any matches for nir_format_hdd in the tree either though
<jekstrand>
It's not in NIR. It's a GLSL IR pass.
<zmike>
oh
<zmike>
🤔
<jekstrand>
Yet another reason why I refuse to implement it in Vulkan
<jekstrand>
It could be ported to NIR these days but, at the time, lots of drivers were still very non-NIR
<zmike>
so how does this work exactly? just advertise fbfetch and then magically adobe blend? trying to find the code that actually handles it to read through
<jekstrand>
Yup
<jekstrand>
And whether you advertise coherent or not determines whether you get coherent blend or not, IIRC
<zmike>
but then what do I do with the advanced blend functions? or do I not get them at all then?
<jekstrand>
You get them if you have non-coherent fb fetch
<jekstrand>
which should be implementable as an input attachment
* jekstrand
is confused
<zmike>
I meant like in gallium blend state, if you enable advanced blend, you get the advanced blend funcs in the state; but if I use fbfetch instead of vk advanced blend, I can't handle those
<zmike>
so my question was whether having only fbfetch means that I just get normal blend funcs
<jekstrand>
I don't know off-hand. You'd have to look at what happens when you throw a test at iris
<zmike>
I'm getting v deep into git log right now
<zmike>
jekstrand: ok, one last question then: which op does load_output translate to? SpvOpImageRead?
<jekstrand>
yes
<jekstrand>
because input attachments are storage images, according to SPIR-V. :-(
<zmike>
that's how I read it
<zmike>
this is some wild code
<jekstrand>
And, IIRC, you're supposed to use a coordinate of (0,0) because it's all relative to the current pixel
<zmike>
makes sense
caseif has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]