ChanServ changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs https://oftc.irclog.whitequark.org/panfrost - <macc24> i have been here before it was popular
Guest2061 has quit []
oftc- has joined #panfrost
oftc- has left #panfrost [#panfrost]
xdarklight has joined #panfrost
xdarklight has quit []
oftc- has joined #panfrost
oftc- has left #panfrost [#panfrost]
xdarklight has joined #panfrost
xdarklight has quit []
xdarklight has joined #panfrost
<icecream95>
alyssa: I like how one of the big features of tiling GPUs is that you can do vertex shading for one frame while fragment shading the next, but panfrost.ko makes that not really work at all
<alyssa>
Yeah... :(
<alyssa>
patches welcome on the mesa side....
<icecream95>
I would try using kbase, but because of all the mediatek hacks I couldn't get it to work properly on duet
<icecream95>
jekstrand: Want to rewrite the kernel driver?
<alyssa>
If unnormalizedCoordinates is VK_TRUE, addressModeU and addressModeV must each be either VK_SAMPLER_ADDRESS_MODE_CLAMP_TO_EDGE or VK_SAMPLER_ADDRESS_MODE_CLAMP_TO_BORDER
<alyssa>
together with
<alyssa>
When unnormalizedCoordinates is VK_TRUE, images the sampler is used with in the shader have the following requirements:
<alyssa>
The viewType must be either VK_IMAGE_VIEW_TYPE_1D or VK_IMAGE_VIEW_TYPE_2D.
<alyssa>
so the s/t wrap modes are clamp which we want
<alyssa>
and the r wrap mode doesn't matter, since it *can't* matter because non-normalized ==> !3D in vulkan
<alyssa>
(not in the hardware, but that's not your problem)
<alyssa>
mali has a lot of restrictions around unnormalized samplers but they're the same as the VK ones (...possibly because of Arm lobbying Khronos ;-p)
<jekstrand>
alyssa: Cool. I'll type the patch once I've convinced me too. :)
<jekstrand>
alyssa: Maybe I'll author it to you and RB it. :)
<alyssa>
jekstrand: Lol. Fair enough
<alyssa>
FWIW, if normalize_coordinates=0, then:
<alyssa>
- LODs are ignored, round(min_lod) is used
<alyssa>
- mipmap_mode is ignored, nearest is used
<alyssa>
- anistropy is disabled
<alyssa>
- wrap modes must be clamp_to_edge or clamp_to_border
<alyssa>
in vulkan, that's justified by
<icecream95>
Ah... good 'ol Mali, faulting whenever an unused field is set wrong :)
<alyssa>
i'm going to need that RA extension sooner than later aren't I.. grumble..
<icecream95>
But it does cause problems when you have a texture buffer you lowered to a 2^16-wide texture
<alyssa>
guess I'll do the obvious thing on my Valhall branch that realistically won't be merged for a while and we'll figure out something better .. later ..
<icecream95>
alyssa: You mean increase the shift for the constraints?
<alyssa>
Yeah
<jekstrand>
icecream95: So lower it to a 2^15-wide texture and throw &0x7fff on the coordinate?
<icecream95>
jekstrand: But that takes more ALU ops than just converting the coordinates to 32-bit
<icecream95>
(Probably)
<jekstrand>
Then convert. ALU is cheap relative to memory, especially on mobile.
<alyssa>
icecream95: The arguments to FETCH on Bifrost are u32 so I'm not sure I understand the issue
<icecream95>
alyssa: I guess this was Midgard then?
<alyssa>
on the other hand, editing the control flow graph to support MRT sounds suss
<alyssa>
then again it's a lot less likely to break violently
<alyssa>
might not be such a bad idea, actually..
<alyssa>
jekstrand: So how do we feel about blend shaders :-V
<jekstrand>
alyssa: Uh... they're annoying?
<alyssa>
what if i just
<icecream95>
alyssa: If we get rid of blend shaders, then at least you won't be able to break dual-source blending again
<alyssa>
don't support them on bifrost+
<alyssa>
icecream95: rude
<alyssa>
accurate, but rude :-p
<alyssa>
we're really not supposed to key shaders to blend state or framebuffer formats.
<alyssa>
admittedly it's not as "bad" as e.g. on AGX
<alyssa>
since the fast path will still be fast / no keys
<icecream95>
But make sure that the tilebuffer wait is not put too far up in the shader, or it will make things slower when there is a lot of overdraw
<alyssa>
(blendable format + fixed function blend mode .. if you ever are doing not that, perf will fall off a cliff anyway and maybe the compiler perf is not the problem here)
<alyssa>
and it means blend constants can be handled in a way that's not stupid
<alyssa>
faster execution by a few instructions, and maybe better i-cache utilization
<alyssa>
icecream95: shouldn't make a difference? I'm just talking about inlining blend shaders into the fragment shaders that use them, like we do in panvk
<icecream95>
"i-cache". Because now prefetching is only done for one shader, not two?
<alyssa>
"maybe"
<alyssa>
Not sure what the rules are for the i-cache
<alyssa>
but I wouldn't be surprised if blend shaders (that are far away in memory) hit a bad case
<alyssa>
easier RA because now we don't need bifrost blend shader ABI
<alyssa>
only GL is affected and if we're thinking VK long term, I mean..
<alyssa>
We have to support blend shaders on Midgard due to a hw limitation, but that's a different compiler backend so who cares
<icecream95>
alyssa: So can we now give the +BLEND any set of source registers, not only R0-R3?
<icecream95>
About tilebuffer wait.. if the LD_TILE is near the start of the shader, then other shaders writing to the same pixel have to finish blending first